I noticed some weird behavior when directly connecting a qwerk to a computer using an ethernet cable. In the end, the workaround appears to be to always leave the wireless dongle plugged in. Here're a few messages between Illah, Ivan, and me...

------------------------------------------------------------
Chris wrote:

I'm adding docs for Qwerk networking and such, and was trying out the direct connect thing where you hook up a computer directly to a Qwerk with an ethernet cable. I'm seeing really weird behavior, and wanted to bounce it off you two to see if I'm doing something wrong or if there's a bug somewhere.

Here's what I did:

* Configured a Windows laptop to use IP 192.168.1.150 and subnet mask 255.255.255.0.
* With Qwerk powered off, connected the laptop to the Qwerk with an ethernet cable. BTW, the Qwerk has the Pre-Release firmware on it.
* Powered on the Qwerk and waited a bit for it to boot up.
* Opened a browser on the laptop and went to http://192.168.1.144/.

And here's what I saw:

The browser was able to load only part of the Qwerk config web site--the right frame loaded, but the left frame didn't (HTTP 404). And it was all really slow. Meanwhile, Windows kept popping up an alert that said "ethernet cable unplugged" and then it would go away, and then it would come back again, etc. Reloading the Qwerk config site caused the left frame to load, but not the right. Clicking on "Logs" sometimes would eventually load the logs frame. It seems like the Qwerk is alternating between having a connection and not having one. Weird.

Thinking it might be a problem with that Qwerk, I tried one of the one's that Tom used for CS4HS (without the wireless dongle plugged in). Same exact behavior. Thinking it might just be the laptop, I tried my Linux machine (configured with 192.168.1.150, etc). Again, same behavior.

But! For kicks, I plugged in the Zonet dongle and, amazingly, everything worked fine. That is, loading 192.168.1.144 in the browser worked flawlessly. The Qwerk even registered with the relay.

So, what's the deal? It seems like the ethernet cable trick only works if the wireless dongle is plugged in. Is that right? That seems weird. Even more, I thought the policy was to totally ignore wireless if there's an ethernet cable plugged in. It either isn't, or doesn't realize that ethernet is plugged in (indeed, look at the attached logs--both have "Connecting on eth0 using static IP 192.168.1.144. Pinging... fail We don't have a wired connection.")

Any ideas? I've attached copies of the connect logs. The EthernetOnly.txt is the one where I kept getting 404s and slow behavior. The EthernetAndWireless.txt is the one that worked.
------------------------------------------------------------
Illlah wrote:

Very odd, and very interesting. Temporary workaround may be to note to people to have the dongle plugged
in, even when using just ethernet (sigh). Ivan, any ideas where in the script this may be going bad? It could
be some command is executing only if the 802.11 is discovered-- and if not, that command doesn't get executed.
------------------------------------------------------------
Chris wrote:

I guess to be really thorough I should check whether it still works if the dongle is in but it can't connect to a wireless network.

There are at two least scenarios, though: 1) Qwerk is using factory defaults (autoconnect) but there are no open wireless networks in range; 2) Qwerk is set to use a particular (non-existent) wireless network.

The only way I can think of trying these options are to try #1 at home and #2 here.

Anyway, I'll try and letcha know what happens.
------------------------------------------------------------
Chris wrote:

I tried it with both the ethernet and dongle connected and the Qwerk configured to use some bogus SSID (and to never switch to autoconnect) and it worked fine connecting to it from a browser using 192.168.1.144.

I'll try to test the other scenario tonight (though, my setup is slightly different in that the Qwerk can't connect to my router even if it *were* open since the Zonet drive and my Belkin apparently hate each other).

Anyway, I'll add a note to the docs about making sure the dongle is plugged in.
------------------------------------------------------------
Chris wrote:

Ok, I did a lot more testing at home. Here's what I found:

* When set to wireless autoconnect mode and having both the ethernet cable and wireless dongle plugged in, it's possible to access the qwerk at 192.168.1.144 via the browser and telnet, but it briefly hangs every few seconds and Windows keeps repeatedly giving "ethernet connected" and "ethernet disconnected" messages. So, I still get the repeating messages, but at least it's usable--the difference appears to be that the dongle is plugged in.

* The situation improves when the qwerk is set to manual mode (and so that it'll never switch to autoconnect) and, again, both ethernet and the dongle are plugged in. Interestingly, it doesn't make any difference whether the network SSID is a valid one or not. Remove the dongle, though (and power-cycle), and it's back to the unusable connecting and reconnecting every second or so.

So, looks like the advice is: always keep the dongle in and, if Windows' messages about the ethernet cable being plugged and unplugged bug you, switch to manual mode.
------------------------------------------------------------
Ivan wrote:

Chris, what you noticed looks both explainable and fixable. Here's the breakdown:

1) Connect.pl turns the ethernet adapter off and then back on every time it runs. This causes what you see when Windows is constantly saying "ethernet cable plugged in" and "ethernet cable disconnected". This happens every time connect.pl runs and re-runs, ie, on every unsuccesful connection attempt.

2) If there is no wireless USB card plugged in, connect.pl exits pretty fast, thus, it restarts itself very often. Similarly, if there is a wireless card, connect.pl will try a wireless connection, which might take 1, 2 or even more minutes. This will give you a wider window in which to view the on-board web-page

3) A workaround would be to remove the statements in connect.pl that restart the ethernet adapter. Simply commenting them out will work fine. They look like this and are somewhere in the beginning of connect.pl:

ifconfig eth0 down
ifconfig eth0 up

4) A possible bad effect of the workaround (which is why those statements are there in the first place) is that the script might confuse the type of connection that it has if it is restarted - that's why, before attempting a wireless or wired connection, i switch off/on the corresponding adapters. The effects of NOT restarting the ethernet adater will probably not be noticable, unless in more complicated situations where we were first using DHCP ethernet (thus having a wired connection), then maybe restart the connection, with the intent to use wireless - in this case, it might confuse our already existent wired connection for a wireless one...

5) Another thing: as mentioned by Illah, connect.pl uses a -1 exit code for any type of unsuccessful attempt - it might be useful to utilize more than just one exit code. The exit code is handled by terkServer.

6) Lastly, when going to http://192.168.1.144, make sure you use IE, other browsers sometimes have a weird cache (it seems firefox is fine though). If in doubt, always force-refresh (I think it's Shift+F5 or Ctrl+Shift+F5). Sometimes this corrects incorrectly displayed pages.


My overall recommendation: for an easy fix, remove the lines that restart the ethernet adapter, but do some testing with different scenarios (especially involving DHCP), just to be sure. Fox a further improving the overall architecture of the connection mechanism, consider using different exit codes in connect.pl.