On 2 Nov 2009, at 19:14, Lennart Sorensen wrote:
On Mon, Nov 02, 2009 at 07:01:25PM +0100, Xan wrote:
First of all, I'm impressed. Wow!. Thanks for this great and
comprensive
answer. Now I understand the problem I have.
Although I thank you the patch I will not patch the kernel because
patching kernels are not supported and really unmantained (the
security
advisories do that I have to recompile the kernel). The ideal
situation
is that your patch will be included in debian repository as whole
kernel
and the more realistic situation is that it will be included only
as a
patch, and with apt-get we could have it ;-)
Unfortunately I have very little hope of that happening, simply
because
that isn't how unix systems have ever behavied. We use it in the
kernels
that we ship on our products. I could try to get it accepted
upstream,
but I unfortunately don't have much hope for it.
Sorry but I have no technical skills for doing that :-(. A more
simple
script were a script for switching the route table for nslu2 connects
_firstly_ via some device all the time:
for example:
# script eth0
produces a route table like:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use
Iface
localnet * 255.255.0.0 U 0
0 0 eth0
localnet * 255.255.0.0 U 0
0 0
wlan0
default 172.26.0.1 0.0.0.0 UG 0
0 0 eth0
default 172.26.0.1 0.0.0.0 UG 0
0 0
wlan0
and
# script wlan0
produces
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use
Iface
localnet * 255.255.0.0 U 0
0 0
wlan0
localnet * 255.255.0.0 U 0
0 0 eth0
default 172.26.0.1 0.0.0.0 UG 0
0 0
wlan0
default 172.26.0.1 0.0.0.0 UG 0
0 0 eth0
Controlling the order seems tricky.
But another way I have no tech skills for doing that. The route
command
is too much complicated for me. Would you like to help me in that?
Typically, I enter via ssh in my slug in 172.26.0.2 (the eth0 static
ip), I run "script wlan0" and it swicthes to wlan0. So I unplugged
the
eth0 and then I connected ssh via 172.26.0.3 (the wlan0 static ip)
(without the cable of eth0). What's the magical solution I want ;-)
Well preferably it would do it automatically of course without you
needing to do anything.
Simpler setup is to just use different IPs and subnets on eth and
wlan,
although if both come from the same network that doesn't work of
course.
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I think I have the same situation.
I can ssh using 192.168.1.6 for wlan0 interface, and 192.168.1.7 for
the eth0 interface.
So now I have 2 sessions going through the same interface, and if I
disconnect that interface both sessions freeze. However, if I issue
ifdown ethO the 192.168.1.7 screen freezes but I am left with the
wlan0 route.
From the wlan0 session
Initial route
Destination Gateway Genmask Flags Metric Ref
Use Iface
localnet * 255.255.255.0 U 0 0
0 eth0
localnet * 255.255.255.0 U 0 0
0 wlan0
default Fasteddy.local 0.0.0.0 UG 0 0
0 wlan0
default Fasteddy.local 0.0.0.0 UG 0 0
0 eth0
ifdown eth0
Destination Gateway Genmask Flags Metric Ref
Use Iface
localnet * 255.255.255.0 U 0 0
0 wlan0
default Fasteddy.local 0.0.0.0 UG 0 0
0 wlan0
ifup eth0
Destination Gateway Genmask Flags Metric Ref
Use Iface
localnet * 255.255.255.0 U 0 0
0 wlan0
localnet * 255.255.255.0 U 0 0
0 eth0
default Fasteddy.local 0.0.0.0 UG 0 0
0 eth0
default Fasteddy.local 0.0.0.0 UG 0 0
0 wlan0
ifdown wlan0; ifup wlan0
Destination Gateway Genmask Flags Metric Ref
Use Iface
localnet * 255.255.255.0 U 0 0
0 eth0
localnet * 255.255.255.0 U 0 0
0 wlan0
default Fasteddy.local 0.0.0.0 UG 0 0
0 wlan0
default Fasteddy.local 0.0.0.0 UG 0 0
0 eth0
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
