On Fri, May 17, 2002 at 02:59:45PM -0400, Brian Victor wrote: > On Fri, May 17, 2002 at 02:40:10PM -0400, K Clark wrote: > >onboard eth0 is working flawlessly. have used dhclient-2.2.x and pump, both > >without problems. > > > >airport worked ONCE last evening. so here's the dilemma, and how i got there. > > Someone more informed may be able to give you a better answer, but I've > only been able to get my airport to work when my onboard ethernet was > down. Whenever I want to connect via airport, I do ifdown eth0; ifup > eth1, and vice-versa. > > The reason for this seems to be that Linux can't figure out which device > to route packets to when both interfaces are up. If you ifup both > interfaces and look at the route command, you can see similar lines for > both interfaces. I presume this is the cause of the problems. There's > probably a way around it with some combination of the route and ifconfig > commands, but it hasn't been worth it for me to figure it out.
This will only be true if you have a bad routing config. Having two interfaces works just fine. In fact, I just doublechecked using my iBook2 w/ gmac and airport. (Mine had the airport as eth0, since both are modules and I only load the airport in normal use...) I'd check to make sure your network config didn't have an unexpected default route. When I went to test this I accidentally set up eth1 as 10.0.3.3/8 - which overrode the 10.0.1.64/24 config on the airport 10.0.3.3/24 fixed that. OTOH, I have a linksys WAP11 access point (no builtin switch) that plugs into a Linux router box, etc etc. And the WAP11 is not very reliable I have to power cycle it every couple days or throughput on my airport drops down to a few k per second. (this in both OS X and Linux) The eth1: timeout messages seem to be a bug in the airport driver. Mine spits them out all the time (and others when it resets the card) but still seems to work. I've been able to eliminate them almost completely by by adding a tbf queue to the interface that attaches to the wireless, and limitting throughput to 11000kbps - that's just slightly less than the 11mbit the 802.11 is trying for. The exact command I use is: tc qdisc add dev eth1 root tbf rate 11000kbit latency 50ms burst 1550 This seems to solve the problem, which I gather has something to do with the WAP11 drinking from a 100mbit firehose. Too bad I still have to powercycle the damn thing regularly :-( Erik -- Pretend that you are not limited by your programming -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
