Devialet Chat

Full Version: Dialog native ip and admin login
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
dialog is a network element on my network, and the only one I cannot login to check, configure, manage performance etc. So does any one have the native IP address and admin login and password info. If not I will try to discover this thru the Ethernet port via my net tools PC.
The "native IP address" is the reference IP address that wifi access points, routers etc are shipped with by the manufacturer, and used to set up or join your network. Typically 192.168.x.x and accessed by your PC through a login and password window. This enables you to fine tune and administer these network elements by accessing the elements internal software management system... This way you can set up security, access and flow-bandwidth etc. If you already have routers and switches and multiple devices like NAS, AV switchers, Apple TV, Amazon Fire and laptops, desk tops, cameras etc already in your network, you can  add the new wifi element in the way you wish it to work as part of an integrated system.



The Dialog is a similar network element as described in their literature. It is a 2.4&5GHZ wifi access point with routing and intelligent hub capability. It will have a reasonably sophisticated software based control system inside. The rate of intermittent failures to link with the Phantoms is symptomatic of poor link and radio frequency ability. The dialog does not appear to be anything close to 802.11ac Wave 2 capability.

I would like to "see" inside the dialog and look at how they have the control set up, so perhaps I and others could offer some suggestions to the developers as to how the can ruggedize the performance equal to a hard wired solution.

By the way the Phantoms are also wifi and Bluetooth elements, but the wifi is slaved to the dialog.

Spark is another issue.
You are making an assumption that is not necessarily true. You have to consider the Ethernet and the PLC/wifi differently.

On the Ethernet port it does not need to have any reference IP address. It can rely on DHCP or mDHCP to get an IP address. In that case login on your router/DHCP server shall be able to tell you what IP address has been allocated to the dialog.

On the PLC/Wifi, one can assume that the dialog plays the role of the DHCP server, router and gateway and probably has an IP address of either 192.168.1.1 or 10.0.1.1. But it is not for granted that the dialog can be administered from those ports.

If I were Devialet, given that only phantoms are supposed to be connected on those networks or guests on the guest network, I would have closed down all ports on those and program the ipfw tables to filter out anything than their protocol.

I would tend to think that your best chance would be on the Ethernet port, but once again, if I were Devialet I would have locked down every single standard ports to minimize the attack surface from a security perspective.

Best of luck for your investigations.

Jean-Marie
There is no port or log in access on the router assigned ip address ---already tried that approach, (not unlike a modem access point in bridge mode). I will try the ethernet port on the D later today, and post the results if any.

In the likely event that you are right and Devialet has robust port lockout protocols (typical of closed proprietary architectures), then they exclude the diagnostic capabilities of  a large technical  "open" community. This suggests that we should be advocating for a Devialet sponsored technical advisory group, for beta testing and other observational and analytical inputs which would help them case harden the flaky Dialog/Phantom/Spark system performance.
will follow this one Smile would also like to see what's inside that *NIX-box.
(08-Oct-2015, 20:27)karebe Wrote: [ -> ][...]
You are right Devialet misses the advantage of the open software world and of the community. Like many other companies Devialet protects its software.
[...]
Dialog and Spark are embedded systems. Maybe there is a maintenance back door somewhere.
[...]

You know, there is a kind of antinomy between being plug and play and being open source. The same kind of difference you can get between iOS and Linux. I don't think they serve the same targets, and I can understand why a company who wants to be able to guaranty a quality of experience as well as to minimize its support cost cannot really offer to keep its kimono opened and allow anyone to fiddle with the product.

I think we need to understand that Devialet has great ambitions in terms of number of phantoms sold, and any risk increase the number of support calls probably translates quite sharply from a financial perspective.

The real problem is never the really technical people who know what they do when they fiddle with the technology and also take their responsibility. The problem is that inevitably you end up have people trying without the required competencies and those people would end up knocking at the door of support.

Concerning the backdoor, I do hope that there is none because any backdoor is a security vulnerability. I hope there is a properly protected (with proper cryptography and key certificates) access allowing proper maintenance. I know that this is how I would architect such a product, which would mean that no-one could use that access without a valid certificate of the company delivering the product.

Best regards,

Jean-Marie