Reach - can't connect to ReachView app (firmware 1.2) [solved - network address]

Reach Module / M+ / M2 Getting started
1

I just received my Reach modules few days ago, but I’m having a problem connecting to the module from my web browser.

Initial WiFi setup appeared to work. I was able to successfully connect to the local hotspot and enter my local WiFi parameters, the SSID, the security (WPA2-Personal), and password. The module accepted the settings, appeared to reset, then I think the LED was a magenta, then briefly green, then the LED moved to the sequence white-blue-blue-red.

I was able to see the unit on my LAN with find and by looking at my DHCP server leases.

However, I’m not able to connect to the module from my browser. I’ve tried 192.168.2.129 and optionally 192.168.2.129:5000. In both cases, the browser times out with no response.

I powered off the module, and then powered it back on, but still no luck.

My WiFi router firmware is current (it’s an Asus RT-AC5300…I overbought on that thing!).

I don’t know how to check my firmware version, so I followed instructions to load image version 1.2. Using the Phone Flash Tool was unsuccessful, but I saw a forum post to flash from the command line with flashall.bat. The batch file worked perfectly.

After the flash, I was able to connect to the local Reach module hotspot and enter the WiFi parameters again. Same behavior - white-blue-blue-red and no ability to connect to the module from a web browser.

This happened on both modules.

If it matters, in the initial WiFi setup page, I did leave the device name blank…

Beyond that, is there any advice on how to connect to the modules?

2

So you’ve already reflashed and that didn’t help. I’d try:

  • ping 192.168.2.129, and if you get a ping, then
  • ssh to 192.168.2.129, and have a look at the wlan interface

and failing that:

  • set up ethernet over USB
  • ping 192.168.2.15
  • ssh to 192.168.2.15

See the docs for info on connecting by ssh.

btw: that router is something else!

3

Thank you for the help! Some progress.

I couldn’t ping or ssh to the 192.168.2.129 address, but, after I configured the RNDIS LAN adapter, I was able to ping, ssh, and http to the module (thereby accessing ReachView). So, when I do that, I’m able to access the module normally from the laptop that the module is plugged into.

During this time, I go to another computer on the same network and it is not able to connect to either 192.168.2.15 or 192.168.2.129.

I’m going to want / need to be able to connect to the module from my network. So, I’m not sure where this leads me.

Does this mean it’s some type of WiFi connection problem?

[I would not recommend the AC5300 router. It’s nice and all, but it’s way too pricey. I was so angry at an old 802.11n D-Link access point that was causing iPads to stall when browsing, I never wanted to have a WiFi problem ever again, so I bought this thing. I should have gone for the better value, a model one or two down in the mainstream of the Asus lineup. I’m not a gamer, and have half of my equipment on actual Cat5e, so I don’t know that I get all the benefits of this router.]

4

No prob. If you can ssh in on 192.168.2.15, then run ifconfig and see what addresss is given to wlan0. If it the same IP as you found before, then maybe you do have router issues. I noticed it is 3 band, so I would hope they are all bridged together, and also I know most routers have a ‘guest’ essid and a normal essid and those networks are kept separate on purpose.

5

We have seen something like that happening, usually a router reboot helps.

6

Well… the problem still exists…

After connecting to the module using ssh over USB, here’s what the Reach ifconfig command told me:

wlan0     Link encap:Ethernet  HWaddr 90:b6:86:0c:44:85
          inet addr:192.168.2.128  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:503 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:86639 (84.6 KiB)  TX bytes:4512 (4.4 KiB)

So this looks good. I think.

I reflashed a second time using flashall.bat, and same behavior. After setting the local WiFi parameters (ssid, wpa2-personal, password), the module boots and connects, but I can’t access the Reachview app over WiFi. I rebooted the router, same behavior.

The router user interface does have some built-in network tools. So, from the router I can ping some devices on the WiFi network, but when I try to ping the Reach module, it doesn’t respond. If I use ping on the Reach module to ping the same device on the network, it gets no response.

The router does indicate that the Reach module is connected on the 2.4 GHz band. It is an 802.11ac router, so I don’t know if that makes a difference. I’m pretty sure it falls back to n, g, b.

I thought I ran across a forum post that had a modification to a wlan script?

Beyond that, I’m going to try another more generic router. (I think my neighbor’s guest network is open!)

7

Hmmm. Well Reach uses 192.168.2.x for itself with ethernet over USB, so maybe there is a routing problem with serving web pages over two interfaces that are both on the same subnet?

This is what I am thinking: Reach is set up with a static address of 192.168.2.15 on the 192.168.2.x subnet for the usb0 interface by default. Reach then connects by wifi to your router and gets another address in the same subnet (192.168.2.128 for wlan0). You might be requesting a ReachView page over the wlan0 interface, but Reach might be replying back to you over the usb0 interface. Both interfaces are on the same subnet after all, so why would Reach care which interface was used for the reply? Well in this case, the wireless router is only connected to one interface, and the other interface is a dead end.

I would suggest to try one of two things:

  • change Reach’s subnet for the usb0 interface, or
  • even better, change your wireless router to a different subnet (like 192.168.3.x)

I’m not really sure about this, it’s just my 2¢

8

I like your thinking. In fact, I think that might be it.

Is it easy to change the reach module (where would that setting be, it looks like the Edison files are a bit locked down)?

Changing my router may be a little tricky. I’ve got a few static assignments, set manually. So, it would be some work to switch to x.x.3.x.

I’ll test it out tomorrow.

Thank you!

9

on Reach:

sudo grep -r '192.168.2.15' /etc/*

gives:

/etc/systemd/network/usb0.network

which contains:

 [Match]
Name=usb0

[Network]
Address=192.168.2.15/24
10

bide,

You’re my new BEST FRIEND!

You were right - the fact that my subnet matched the subnet reserved on the Edison board must have misrouted the network routing on the Edison. After changing the IP address in usb0.network to 192.168.3.15, then rebooting, it worked!

I was able to successfully ping, ssh, and http to the ReachView app.

Sooooo. with this hurdle overcome, I now move on to much more interesting lessons using the module!

Again, big thanks. I bought you this. I hope it’s your size!

-Matt

fav-icon.jpg598×598 24.8 KB

2 Likes
11

Was that ever tasty. Thanks!

I’m glad it’s working for you!

(You can check the ‘solved’ button on the post that was most helpful.)

1 Like
12

@bide your Photoshop skills are incredible! :joy:

13

I see those tears of appreciation my dear @mikhail.avkhimenia. With hard work and dedication you too could rise to the level of Microsoft Paint Certified Professional, and one day have such a steady hand with the erase tool as I!

MS_Paint_Certificate.jpg1100×850 67.2 KB

:laughing:

6 Likes
14

This is a giant bug… had the same problem and spent 4 hours before I found this thread. Can @igor.vereninov assign it as a bug to the latest checkin ?

15

I’m glad this thread helped you solve your problem. I can understand the frustration as well.

Most network routers that I’ve seen hand out addresses in 192.168.0.xx and 192.168.1.xx so I think this conflict should be rare situation. Because it has more to do with network administration than with Reach, I don’t think this should be considered a bug.

Maybe it would be best to put a warning in the docs about connecting Reach to a Wi-Fi network with a 192.168.2.xx subnet.

16

Or just put reach on a non-common subnet for usb… anyone that has a wireless access point in their home will almost certainly be on the 192.168.2.X subnet.

17

bide, you’re the superman, greetings

18

A post was split to a new topic: Connecting to Reach