[Voyage-linux] Basic Wifi problem

[Teco Boot]

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 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.

> <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.

Teco