search

openbci-archive / OpenBCI_NodeJS_Wifi

NodeJS driver for the Wifi Shield
MIT License
16 stars 13 forks source link

Connection problems: mismatch between local ip address and shield's ip address using WiFi direct #30

Open rivasd opened 4 years ago

rivasd commented 4 years ago

Hi!

I was investigating connection issues related to our WiFi shield as can be seen on my forum post and finally narrowed it down to a very similar issue as #26.

We operate in a corporate setting where every machine has multiple network interfaces, the main one being an Ethernet connection that is heavily secured and through which any OpenBCI data transmission is hopeless. We thus opted for WiFi direct through a usb wifi antenna. When connecting the shield's network through this interface, we can see its ip address as 192.168.4.1, and our computer's is 192.168.4.2. However, the current nodejs implementation assumes that the local ip address must be the one assigned through Ethernet, which in our case is a completely different address assigned starting with different numbers. As i long suspected, this is the source of our connection problems, as sockets between ip addresses of the shield's interface and our coporate addresses simply do not work.

Hardcoding 192.168.4.2 inside Wifi.prototype.getLocalIPAddress solved the connection problem and I was able to see data streaming in the GUI for the first time, confirming this mismatch was definitely the issue.

As I can see, the current solution, implemented when solving #26, was based on @retiutut having the reverse problem, and thus Wifi.prototype.getLocalIPAddress was hardcoded to use the address from the Ethernet interface. A more robust solution could either:

I will try to submit a PR regarding this, I think it would help adoption of the shield in more complex networking environments.

Hub version: 2.1.0 GUI version: 4.1.6 Shield firmware: 2.0.5

retiutut commented 4 years ago

@rivasd Thanks for sharing and investigating! Also, thanks for sharing such detailed information. You are a model community member! When issues like this get resolved, everyone benefits.

rivasd commented 4 years ago

@retiutut Thank you :) happy to help. Looking quickly, I can see Wifi.prototype.getLocalIPAddress is getting called very early, before anything about the shield's address is communicated or found. Crucially, this happens when setting up the UDP server. I'm not sure of this decision of getting TCP and UDP "servers" rolling immediately when the hub is started, before knowing shield options. Fixing this issue would require reversing the order of operations (finding out about the shield's address, then starting servers on the right addresses,port accordingly ).

We are currently heading into a data collection phase and I do not have the time to re structure the node driver for WiFi in this way. I will stick to my hardcoded patch, but I hope my notes will help you implement the long term fix!

retiutut commented 4 years ago

I think the idea of a hardcoded fix is the best way to go right now. Just to clarify:

rivasd commented 4 years ago

I made changes inside the @openbci/wifi code (so this package) that was bundled in the hub's /app directory, directly in its node_modules. This somehow worked, but admittedly getting the hub to run at all to begin with was the bottleneck (node version mismatches for serialport, problems running electron-rebuild with very old electron versions, electron-prebuilt not actually existing anymore, etc).

But I am happy to say that once I got through all that npm run release worked and I have built my custom hub already! So far it works, I will continue testing with both GUI 4.1.5 and the 4.1.6 beta. But it's such a small change that i'm confident it'll work.

I simply switched the order of the if clauses on line https://github.com/OpenBCI/OpenBCI_NodeJS_Wifi/blob/d4583cd5b99dde9427f35da07b25523e47286e1e/openBCIWifi.js#L422

So that WiFi interfaces are selected by default. To be fair, this should be the default since WiFi direct is recommended in the official docs... ;)

Ah also, this all started with me trying to confirm the impedance checks still did not work even through the GUI. I can now confidently say that they don't, and that definitely points to firmware issues between the shield and the cyton. This low-level stuff, I reaaaaally cannot help you with!

retiutut commented 4 years ago

Ah also, this all started with me trying to confirm the impedance checks still did not work even through the GUI. I can now confidently say that they don't, and that definitely points to firmware issues between the shield and the cyton. This low-level stuff, I reaaaaally cannot help you with!

This info is enough for now, and Hub+WiFi is low priority. It's great to have a trail of breadcrumbs for everyone. There is enough info here in this thread to start working on a fix at another time. Thanks!