[Voyage-linux] Basic Wifi problem

[Gustin Johnson]

On Tue, May 10, 2011 at 2:23 PM, Teco Boot <teco at inf-net.nl> wrote:
>
> Op 10 mei 2011, om 10:52 heeft Gustin Johnson het volgende geschreven:
>
>> On Tue, May 10, 2011 at 1:15 AM, Teco Boot <teco at inf-net.nl> wrote:
>> <snip>
>>>> As Punky suggested, having a console available over a serial port is
>>>> pretty much indispensable when configuring the ALIX boards since it
>>>> will work even when you horribly break the network config.  Make sure
>>>> that your computer has a serial port as well, or else you will need to
>>>> pick up a USB to serial (RS-232) adapter as well.
>>> Ack.
>>> But reliable IP connectivity to the box is more than nice to have, IMHO.
>>
>> I am not sure that such a thing exists.  Given the variety of hardware
>> and network topologies that exist, I am not sure how one would go
>> about achieving this.  Since we already have a reliable method of
>> configuring the ALIX over serial, I am also not sure that it is worth
>> the effort.
> For (initial) configuration: OK.
> I have similar problems with access to Voyage boxes, connected to Internet
> with multiple paths (UMTS & WLAN-OLSR). See below.
> Punky uses same config as Matt.

I did not say that such a config was not possible, only that it is
difficult to achieve a robust dual homed connection "out of the box".
 What works for you or Punky may not work in my lab.  Use the serial
connection to configure the box, test it repeatedly, then send it out.
 For remote locations it is always a good idea to think about
redundancy and OOB access.

> I use the dual uplink (eth & wlan) on my MacBook each day. I'll check ssh
> to eth & | wlan later this week. And compare with Voyage.
>
I have done this on my laptop as well (I have three active interfaces
on my laptop right now).  The devil is in the details.  You may want
to look at how you have configured your interfaces.  Try setting them
up manually (using "ip addr" and "ip route") as opposed to DHCP.
Don't forget to set your DNS servers in /etc/resolv.conf.

Having console access when things do not work is pretty much
indispensable, otherwise you are trying to trouble shoot blind and are
pretty much just guessing at what the problem is.

>> <snip>
>>>> for each
>>>> interface, and then some rules for which traffic gets put into which
>>>> queue (this is the short short description).  This is probably not the
>>>> best option for you right now.  If you get curious about this sort of
>>>> thing the Linux Advanced Routing and Traffic Control Howto is pretty
>>>> much the bible on this sort of thing:
>>>> http://lartc.org
>>> What about a handy script, creating rules for "strong host" behavior:
>>> return packets with source address that matches a configured address on
>>> an interface leave the box on that interface.
>>>
>> What you are really asking for is a script that is constantly running
>> and doing sanity checks on the network config.  This will only get in
>> the way of more complicated setups for little benefit, never mind the
>> overhead.  This idea also does not really help you right now, since
>> you don't know why the network drops and neither IP is reachable.  You
>> really want to get in there (via serial) and figure out what is going
>> wrong.
> It would take me two hours driving, maybe to unknown_places. I need remote
> access to an IP address that is connected to the Internet. But sometimes
> there is a better return path via WLAN, and a NAPT function. Problem is
> somewhat similar to the ath0 & eth0 dual homing problem.

This is exactly why you want to nail down your IP config before
deploying the device to some remote location.  Sometimes I have OOB
access to our ALIXs, sometimes not.  So in the cases where I only have
IP connectivity, we test, and test, and test again before deploying.

We have written scripts in the past that do such sanity checking of
routes and rules, but they were specific to that implementation.  To
try and build a script that would cover all varieties of possible
options *and* not interfere with complicated setups is simply time
consuming.  Not impossible but not trivial either.