...making Linux just a little more fun!
Benjamin A. Okopnik [ben at linuxgazette.net]
Sat, 5 Aug 2006 22:25:47 -0400
Hi, Jeff -
I'm going to CC the LG Answer Gang on my response, since this is pretty much the purpose of TAG; also, chances are that someone else may be able to cover any areas that I miss.
On Sat, Aug 05, 2006 at 07:02:23PM -0600, jeff at jeffroot.us wrote:
> Ben Okipnik;
"Okopnik", please.
> In the LG#127 article "With Knoppix at a HotSpot", you made the > comment: > > [ I do a lot of travelling, and connect to a wide variety of > strange WLANs. In my experience, at least, connecting to a > wireless LAN with Linux is usually just as simple as Edgar > describes. -- Ben ] > > Well, I have a very different experience. I have no trouble at all > connecting to a managed wifi network; at home or work, I just set > the ESSID and WEP key in /etc/network/interfaces, and "netscheme > work" does the rest. But this same machine has never managed to > connect to an open wifi network. > > Today, I visited my municipal wifi and tried to connect. I ran > Kismet to see that the ESSID was "OldTownWifi" and that wep and > encryption were both off. So I used iwconfig to set the essid and > managed mode, then ran dhclient. Nothing. No response from their > server at all. > > So how about this: you help me understand why I can see an open > hotspot with Kismet but can't seem to give the right incantation to > connect, and I'll write up a "dummy's guide" for LG.
Well, that sounds like a fair sort of deal... but I don't know that I can answer the question as posed. In my mind, at least, it comes down to "why doesn't dhcpclient work as it should?" - and I can't really tell you, since I don't use it. I suppose you could always take a look at your '/var/log/{daemon,kern}.log' or '/var/log/messages' and figure out where it's failing.
To be a bit more specific, I've tried using 'dhcpclient' in the past - I don't recall why - but it simply didn't work no matter what I tried, on a "known good" Ethernet connection which worked fine with 'pump' on a different machine. I pounded on the config file for a while, tried everything in the manpage - then gave up and installed 'pump'... and everything instantly started working - and if I recall correctly, it required no configuration on my part.
I've been using 'pump' ever since.
These days, I usually use the 'ifup/ifdown' front ends instead of using it directly (although sometimes I forget and use it directly; it works fine either way.) I never have to set the ESSID unless I'm trying to get onto a private network; the one time that I ended up wrestling with it turned out to be a case of solving the wrong problem - the responsible bit was a broken kernel module for my ipw2200, and not the client at all. As I've said, It Just Works.
> It sure seems like it's needed. I've spent a great deal of time on > Google and found no end of info on setting up the hotspot itself, > but not a word about how to connect to the hotspot from Linux. When > a professional Sysadmin and programmer can't figure this out, there > must be something wrong somewhere. (And I'm willing to admit it if > that something turns out to be me...)
Well, let's assume that we're going to do this with 'pump', and let's take a look at the relevant info in my '/etc/network/interfaces':
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# The loopback interface
# automatically added when upgrading
auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
# [ Skipping several private network stanzas ]
# Default wlan0 DHCP setup
iface wlan0 inet dhcp
# Set mode to 802.11B/G
pre-up iwpriv wlan0 set_mode 6
pre-up ifconfig eth0 down
post-down ifconfig eth0 up
wireless_mode Managed
So, I set my 'eth0' to a static IP as soon as the machine comes up, but my 'wlan0' stays down until I invoke it with 'sudo ifup wlan0'. Note, by the way, that some of the verbiage in this last stanza is mostly unnecessary - I could probably take out the 'set_mode 6' line and it would work just fine. I'm also bringing down eth0 so that the primary gateway in the routing table will be the one that this latest negotiation returns - I had a problem with this some years ago and fixed it this way, so that's left over from back then (since it does me no harm, I've just left it in place.) Of course, since I bring it down when I start my wireless, it's only "fair" to bring it back when I'm done with wlan0 - hence, the 'eth0 up' line. In short, the whole thing could look like this and still work without a problem:
iface wlan0 inet dhcp
wireless_mode Managed
...although I'd run right back to my current config if a problem
appeared.
Just for reference, here's what the DHCP negotiation looks like in my '/var/log/daemon.log' when I do connect via my WiFi interface:
Jan 31 20:54:48 Fenrir pumpd[4711]: starting at (uptime 0 days, 2:43:09) Tue Jan 31 20:54:48 2006 Jan 31 20:54:48 Fenrir pumpd[4711]: PUMP: sending discover Jan 31 20:54:52 Fenrir pumpd[4711]: got dhcp offer Jan 31 20:54:52 Fenrir pumpd[4711]: PUMP: sending second discover Jan 31 20:54:55 Fenrir pumpd[4711]: PUMP: got an offer Jan 31 20:54:55 Fenrir pumpd[4711]: PUMP: got lease Jan 31 20:54:55 Fenrir pumpd[4711]: intf: device: wlan0 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: set: 416 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: bootServer: 10.0.0.1 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: reqLease: 43200 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: ip: 10.0.0.219 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: next server: 10.0.0.1 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: netmask: 255.255.255.0 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: gateways[0]: 10.0.0.1 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: numGateways: 1 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: dnsServers[0]: 10.0.0.1 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: numDns: 1 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: broadcast: 10.0.0.255 Jan 31 20:54:55 Fenrir pumpd[4711]: intf: network: 10.0.0.0 Jan 31 20:54:55 Fenrir pumpd[4711]: configured interface wlan0
So my advice is - uninstall 'dhcpclient', install 'pump', and give it a try. If it doesn't work, at least I'll have a little expertise with it and be able to help you - but I suspect that you'll find it as problem-free as I have.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *
Sat, 5 Aug 2006 23:58:29 -0600
Ben;
> "Okopnik", please.
Sorry; I'm usually pretty careful with names -- I guess my finger drifted over one key.
So this is exactly the sort of info I'm looking for: where do I look to see what's going on? I just checked /var/log/daemon.log and found a set of "No DHCPOFFERS recieved".
So, I guess the way to approach this is to walk up the stack. Let's go through what works, which should limit the parameters we need to vary.
First, the hardware. I'm using a Microsoft MN-520 pcmcia card on a Dell C600, running Debian Sarge with the 2.4.27 kernel. (I tried switching to the 2.6 kernel but that's still an ongoing debug for me.) I chose the MN-520 based on the hardware compatibility matrix.
I ended up using the HostAP driver; mostly because the 2.4 orinoco_cs driver didin't support wireless extentions, and because I like keeping a plain Sarge install if at all possible. Recompiling a Debian kernel with patches is pretty straightforward, but I prefer apt-get to make.
I know the driver is working, because I get reasonable output from iwconfig and ifconfig. I can set my work config and all is well. I've used this setup with other closed Wifi networks as well. As long as I can set the ESSID and WEP key, I don't seem to have problems. (And I was using the "netscheme" system for setting up multiple configs, but killed that to eliminate one layer.)
I stripped my /etc/network/interfaces pretty much down to your minimum version:
iface wlan0 inet dhcp
wireless-mode managed
From here, I can run Kismet and see the "OldTownWifi" network, but I'm not that sure I understand what Kismet is telling me. Some networks list an "IP range", but most don't.
So, I run "iwconfig wlan0 essid OldTownWifi", and I now have wlan0 in both iwconfig and ifconfig. But, understandably, the ifconfig stanza is not showing an IP address for the interface.
I made a few stabs at dhclient, and see nothing but the aforementioned "No DHCPOFFERS" messages.
Not having a working net connection meant that I could not google for more help; so I went back home to my PPP link.
I did see the 'pump' references and installed it, but since there are no (intentionally) open AP's within range I could not test it.
The best I could do was to use my Netgear MR814v2 router as a dummy network. I hooked it into my Dell's ethernet port and set it as an open AP. Setting the 'interfaces' stanza to:
iface wlan0 inet dhcp wireless-essid any wireless-mode managed
seems to work magic. Now when I push the card into its slot, the frelling thing just pops up with an IP and essid set!
> I never have to set the ESSID
Really? I assumed the essid was necessary before you could talk to the AP; does pump configure this for you? And since Kismet is showing me several apparently open AP's; how would you know which one you're on? (I seem to recall something about ghost AP's at coffee shops being a security risk; is this what happens? You connect to something without knowing what you're really connecting to?)
I saw the essid set with my dummy configuration, but I tried not to draw too many conclusions from that setup. BTW, both pump and dchpclient3 seem to work fine for this lashup.
So, where next? I figure on trying again with pump installed and using the above config. But what to check? tail -f /var/log/daemon.log? Anything else worth monitoring while I experiment?
(I'm not sure I'll get back downtown until Monday. This debug may proceed in burst mode. Unless it just works with pump...)
Thanks to all the Gang.
Jeff Root jeff at jeffroot.us
ps -- I'm really trying to get this working in time for the World Science Fiction Convention in Anaheim; if it's still not working, and if Denis and/or Heather is going to be there, perhaps they'd find a half-hour to look my problem over in person?
Benjamin A. Okopnik [ben at linuxgazette.net]
Sun, 6 Aug 2006 23:08:21 -0400
On Sat, Aug 05, 2006 at 11:58:29PM -0600, jeff at jeffroot.us wrote:
> > So this is exactly the sort of info I'm looking for: where do I look > to see what's going on? I just checked /var/log/daemon.log and > found a set of "No DHCPOFFERS recieved".
Just for future reference, Jeff - and a bit of knowledge that I hope will propagate into our readership as well - here is a cardinal rule of error reporting: never retype, always copy-and-paste. Given that this error is your interface with the problem, you need to report it as exactly as possible, and retyping introduces possible transmission errors.
> So, I guess the way to approach this is to walk up the stack.
Didn't you say that you were able to connect with other networks? That should eliminate the link, the network, and the transport layers... well, it may be worthwhile to take a look at the mode in which the card is "listening" versus the one that the AP is using - the AP could be using, say, mode B while your card is only set for A.
> I stripped my /etc/network/interfaces pretty much down to your > minimum version: > > iface wlan0 inet dhcp > wireless-mode managed
Out of curiosity, what does "iwpriv wlan0 get_mode" return for you? Mine, since I set it explicitly, says just what I'd expect:
ben at Fenrir:~$ iwpriv wlan0 get_mode wlan0 get_mode:802.11bg (6)
Check the AP mode as well.
> From here, I can run Kismet and see the "OldTownWifi" network, but > I'm not that sure I understand what Kismet is telling me.
So what is it telling you? Maybe one of us could interpret it.
> Some > networks list an "IP range", but most don't. > > So, I run "iwconfig wlan0 essid OldTownWifi", and I now have wlan0 > in both iwconfig and ifconfig. But, understandably, the ifconfig > stanza is not showing an IP address for the interface.
Right - no negotiation has happened yet.
> I made a few stabs at dhclient, and see nothing but the > aforementioned "No DHCPOFFERS" messages.
Is there a way to make its reporting more verbose? 'pump', by contrast, is very "talky" in the logs - I like it that way, actually.
> I did see the 'pump' references and installed it, but since there > are no (intentionally) open AP's within range I could not test it.
Do make sure to uninstall 'dhclient' so you can test properly - you don't want those two contending for top spot (in the case of 'ifup/ifdown', 'dhclient' has a higher precedence than 'pump' and will be used if both are installed.)
> The best I could do was to use my Netgear MR814v2 router as a dummy > network. I hooked it into my Dell's ethernet port and set it as an > open AP. Setting the 'interfaces' stanza to: > > iface wlan0 inet dhcp > wireless-essid any > wireless-mode managed > > seems to work magic. Now when I push the card into its slot, the > frelling thing just pops up with an IP and essid set!
Just as it should.
> > I never have to set the ESSID > > Really? I assumed the essid was necessary before you could talk to > the AP; does pump configure this for you?
Yes.
> And since Kismet is > showing me several apparently open AP's; how would you know which > one you're on?
I was curious about this in the past, and did a little experimenting; it seems that, by default, it latches onto the one with the lowest channel number - unless you preset the channel to something different.
In fact, now that I recall it, I have a somewhat amusing story related to this. I was in a hotel room in Atlanta with my then-girlfriend (now my wife) Kat; the hotel offered wireless access. I turned on my Linux laptop, typed 'ifup wlan0', and was off and running - but Kat simply couldn't get on the network with her Wind0ws machine. I poked it with a long stick, then examined the situation from my laptop - and saw that their AP was broadcasting on two channels. A little more investigation showed that you could connect to the first one, but it wouldn't do you any good: "there was no 'there' there." In other words, the radio link worked fine, but the network side was down. The second channel worked fine... but since it was a different channel on the same AP, Windows just blithely latched on to the first available channel - *and there was no way to change it.* I'd tried, using everything from searching the Net to twiddling nearly random registry keys; it was useless.
The hotel's network tech recommended - ready for this? - taking the laptop all the way to the end of the hall, where channel 1 might possibly be a little too weak to reach, and then try connecting. Believe it or not, it worked. Kat could then walk back to the room and happily browse away.
Not quite defenestration, but close...
'pump', as I'd mentioned before, just did The Right Thing. I don't recall what the log said, but it had tried channel 1, found that it couldn't connect, dropped it, and quietly jumped to channel two without bothering me about it. Which is, if you think about it, the Robustness Principle up close and in person - exactly how it should work.
> (I seem to recall something about ghost AP's at > coffee shops being a security risk; is this what happens? You > connect to something without knowing what you're really connecting > to?)
It could indeed happen, but it's not a question that's likely to matter for the way I use my computer on wireless networks. I'm certainly not going to send, e.g., my bank statement to some wireless printer at some random coffee shop...
> I saw the essid set with my dummy configuration, but I tried not to > draw too many conclusions from that setup. BTW, both pump and > dchpclient3 seem to work fine for this lashup. > > So, where next? I figure on trying again with pump installed and > using the above config. But what to check? tail -f > /var/log/daemon.log? Anything else worth monitoring while I > experiment?
I'd say that the first thing to do is actually test it. If it fails, the first place I'd go is '/var/log/daemon.log' and copy-and-paste the results into an email back to this list. If you're feeling energetic, then fire up some sort of a network traffic dumper - say, 'tcpdump -i all' - and grab everything relevant from the first DHCP request until the attempt fails. Send that as well.
But do hope for the best.
> (I'm not sure I'll get back downtown until Monday. This debug may > proceed in burst mode. Unless it just works with pump...)
That's the thing to hope for!
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *
Tue, 8 Aug 2006 22:33:13 -0600
Guten TAG;
OK, I've made two trips down to a local hotspot and there's still no joy. I'll try to give you as much detail as possible.
> Is there a way to make its reporting more verbose? 'pump', by > contrast, is very "talky" in the logs - I like it that way, > actually.
When I was using dhcp3-client (dhclient), this was always what I saw:
Aug 6 14:46:38 localhost cardmgr[934]: watching 1 socket Aug 6 14:46:38 localhost cardmgr[935]: starting, version is 3.2.5 Aug 6 14:49:08 localhost cardmgr[935]: socket 0: Microsoft Wireless Notebook Adapter MN-520 Aug 6 14:49:08 localhost cardmgr[935]: executing: 'modprobe hostap' Aug 6 14:49:09 localhost cardmgr[935]: executing: 'modprobe hostap_cs' Aug 6 14:49:10 localhost cardmgr[935]: executing: './network start wlan0' Aug 6 14:49:11 localhost dhclient: Internet Systems Consortium DHCP Client V3.0.3 Aug 6 14:49:11 localhost dhclient: Copyright 2004-2005 Internet Systems Consortium. Aug 6 14:49:11 localhost dhclient: All rights reserved. Aug 6 14:49:11 localhost dhclient: For info, please visit https://www.isc.org/products/DHCP Aug 6 14:49:11 localhost dhclient: Aug 6 14:49:11 localhost dhclient: wifi0: unknown hardware address type 801 Aug 6 14:49:12 localhost dhclient: wifi0: unknown hardware address type 801 Aug 6 14:49:12 localhost dhclient: Listening on LPF/wlan0/00:50:f2:c3:aa:07 Aug 6 14:49:12 localhost dhclient: Sending on LPF/wlan0/00:50:f2:c3:aa:07 Aug 6 14:49:12 localhost dhclient: Sending on Socket/fallback Aug 6 14:49:14 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 Aug 6 14:49:20 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 Aug 6 14:49:32 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11 Aug 6 14:49:43 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21 Aug 6 14:50:04 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 Aug 6 14:50:11 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 Aug 6 14:50:15 localhost dhclient: No DHCPOFFERS received. Aug 6 14:50:15 localhost dhclient: No working leases in persistent database - sleeping.
I removed all dhcp packages and installed pump, which gives:
Aug 6 15:32:16 localhost cardmgr[935]: socket 0: Microsoft Wireless Notebook Adapter MN-520 Aug 6 15:32:16 localhost cardmgr[935]: executing: 'modprobe hostap' Aug 6 15:32:16 localhost cardmgr[935]: executing: 'modprobe hostap_cs' Aug 6 15:32:17 localhost cardmgr[935]: executing: './network start wlan0' Aug 6 15:32:18 localhost pumpd[1159]: PUMP: sending discover Aug 6 15:32:48 localhost cardmgr[935]: + Operation failed. Aug 6 15:32:48 localhost cardmgr[935]: + Failed to bring up wlan0. Aug 6 15:35:05 localhost pumpd[1159]: PUMP: sending discover Aug 6 15:36:14 localhost pumpd[1159]: PUMP: sending discover Aug 6 15:36:56 localhost init: Switching to runlevel: 0 Aug 6 15:36:58 localhost kdm: :0[985]: initgroups for jroot failed: Operation not permitted Aug 6 15:37:00 localhost cardmgr[935]: executing: './network check wlan0' Aug 6 15:37:00 localhost cardmgr[935]: executing: './network stop wlan0' Aug 6 15:37:00 localhost cardmgr[935]: + /sbin/ifdown: interface wlan0 not configured Aug 6 15:37:00 localhost cardmgr[935]: executing: 'modprobe -r hostap_cs' Aug 6 15:37:01 localhost cardmgr[935]: executing: 'modprobe -r hostap' Aug 6 15:37:01 localhost cardmgr[935]: exiting
Switching from the HostAP drivers to the orinoco_cs driver:
Aug 8 12:08:52 localhost cardmgr[1215]: socket 1: Microsoft Wireless Notebook Adapter MN-520 1.0.3 Aug 8 12:08:52 localhost cardmgr[1215]: executing: 'modprobe orinoco_cs' Aug 8 12:08:53 localhost cardmgr[1215]: executing: './network start eth1' Aug 8 12:08:53 localhost pumpd[1570]: starting at (uptime 0 days, 0:18:09) Tue Aug 8 12:08:53 2006 Aug 8 12:08:53 localhost pumpd[1570]: PUMP: sending discover Aug 8 12:09:23 localhost cardmgr[1215]: + Operation failed. Aug 8 12:09:23 localhost cardmgr[1215]: + Failed to bring up eth1.
Just for fun, this is what happens when I use my work configuration. The only difference here is that I configure ESSID and WEP key in /etc/network/interfaces:
Aug 8 12:10:08 localhost pumpd[1570]: PUMP: sending discover Aug 8 12:10:19 localhost pumpd[1570]: got dhcp offer Aug 8 12:10:19 localhost pumpd[1570]: PUMP: sending second discover Aug 8 12:10:19 localhost pumpd[1570]: reject: xid: 0xc30dac27 <--> 0xc30dac26 Aug 8 12:10:19 localhost pumpd[1570]: PUMP: got an offer Aug 8 12:10:19 localhost pumpd[1570]: reject: xid: 0xc30dac28 <--> 0xc30dac27 Aug 8 12:10:19 localhost last message repeated 2 times Aug 8 12:10:20 localhost pumpd[1570]: PUMP: got lease Aug 8 12:10:20 localhost pumpd[1570]: intf: device: eth1 Aug 8 12:10:20 localhost pumpd[1570]: intf: set: 416 Aug 8 12:10:20 localhost pumpd[1570]: intf: bootServer: 172.16.241.1 Aug 8 12:10:20 localhost pumpd[1570]: intf: reqLease: 43200 Aug 8 12:10:20 localhost pumpd[1570]: intf: ip: 172.16.9.147 Aug 8 12:10:20 localhost pumpd[1570]: intf: next server: 172.16.241.1 Aug 8 12:10:20 localhost pumpd[1570]: intf: netmask: 255.255.252.0 Aug 8 12:10:20 localhost pumpd[1570]: intf: gateways[0]: 172.16.8.254 Aug 8 12:10:20 localhost pumpd[1570]: intf: numGateways: 1 Aug 8 12:10:20 localhost pumpd[1570]: intf: dnsServers[0]: 172.16.89.1 Aug 8 12:10:20 localhost pumpd[1570]: intf: dnsServers[1]: 172.16.32.10 Aug 8 12:10:20 localhost pumpd[1570]: intf: numDns: 2 Aug 8 12:10:20 localhost pumpd[1570]: intf: domain: <sanitized> Aug 8 12:10:20 localhost pumpd[1570]: intf: broadcast: 172.16.11.255 Aug 8 12:10:20 localhost pumpd[1570]: intf: network: 172.16.8.0 Aug 8 12:10:20 localhost pumpd[1570]: configured interface eth1
I had a friend loan me his PCMCIA card, and got this:
Aug 8 19:35:56 localhost cardmgr[1068]: socket 1: U.S. Robotics IEEE 802.11b PC-CARD Aug 8 19:35:56 localhost cardmgr[1068]: executing: 'modprobe hostap' Aug 8 19:35:56 localhost cardmgr[1068]: executing: 'modprobe hostap_cs' Aug 8 19:35:56 localhost cardmgr[1068]: executing: './network start wlan0' Aug 8 19:35:57 localhost pumpd[1275]: PUMP: sending discover Aug 8 19:36:27 localhost cardmgr[1068]: + Operation failed. Aug 8 19:36:27 localhost cardmgr[1068]: + Failed to bring up wlan0.
So I thought I'd use the interfaces config of:
iface eth1 inet dhcp wireless-essid any wireless-mode managed
And sat right in front of the coffee shop (they were closed), figuring that this would connect to anything that was open.
Aug 8 19:33:55 localhost cardmgr[1068]: socket 1: Microsoft Wireless Notebook Adapter MN-520 1.0.3 Aug 8 19:33:56 localhost cardmgr[1068]: executing: 'modprobe orinoco_cs' Aug 8 19:33:56 localhost cardmgr[1068]: executing: './network start eth1' Aug 8 19:33:56 localhost pumpd[1275]: PUMP: sending discover Aug 8 19:34:02 localhost pumpd[1275]: got dhcp offer Aug 8 19:34:02 localhost pumpd[1275]: PUMP: sending second discover Aug 8 19:34:32 localhost cardmgr[1068]: + Operation failed. Aug 8 19:34:32 localhost cardmgr[1068]: + Failed to bring up eth1.
This one seemed promising, since I got that "dhcp offer". And the logs don't show it, but iwconfig showed the proper ESSID during the time of the "second discover".
These logs are the same as I've been seeing all along.
So it appears that my card(s) can see the AP, but can't talk to the DHCP server. I suppose it's also possible that the server is not using DHCP, but it seems unlikely that this would be true for every AP I've tried.
So: I've tried multiple hotspots, multiple cards, multiple drivers. Neither dhcp3-client nor pump can get a response from the server.
Yesterday, I had my friend bring his laptop along. It's a D600 instead of my C600. But he connected first time out and had no troubles at all. That machine runs SuSE (9.3, I believe).
So I think tomorrow I'll take a couple hours off from work and just park myself down at the coffee shop until I have tried all the permutations (with logs). I haven't been very systematic about this so far, because I've been rushed on each trip.
(And I did have the cops cruise by to see why I was parked in front of a closed coffee shop...)
On my way home, I cruised through the college campus. They have a campus wifi, but it's a closed one. (I have the ESSID and WEP key, but that's not the problem I need to solve.) I figured I'd just see if my machine could detect their ESSID like it did at the coffee shop.
What happened is that I locked on to something with an ESSID of "computerguy", but despite tantalizing messages from pump about "AP Out of Range", "AP In Range" -- back and forth for 3 tries -- it finally gave up.
My theories at this point are: 1) these APs are not set up to talk 802.11b (and I only have "b" cards). 2) I'm not close enough to the AP to get the discover request through. 3) my card does not have the xmit power necessary to get the discover request through.
I'm not much inclined to theory 3), since I checked the power levels for my work AP and they were close to the power levels of the coffee shop AP.
Oh, I did try tcpdump -i eth1, but there didn't seem to be any traffic to capture (and I'm not sure what happened to my copy of its output, so I'll do this again.)
---------------
My comments on Kismet were aimed at the curses interface. Kismet has a column "helpfully" labelled "T". I have yet to find any documentation which tells me what "T" stands for. But I'm pretty sure it's different than "W", whcih is the column next to it. FWIW, the data under "T" seems to be "A". I have no idea what that means either. I have formed the opinion that Kismet could use some help with documentation.
Well, any ideas for finding out what's going on would be appreciated.
Jeff Root jeff at jeffroot.us
Benjamin A. Okopnik [ben at linuxgazette.net]
Fri, 11 Aug 2006 12:16:03 -0400
On Tue, Aug 08, 2006 at 10:33:13PM -0600, jeff at jeffroot.us wrote:
> Guten TAG;
Does that mean that this discussion should ABEND tonight?
> OK, I've made two trips down to a local hotspot and there's still no > joy. I'll try to give you as much detail as possible. > > > Is there a way to make its reporting more verbose? 'pump', by > > contrast, is very "talky" in the logs - I like it that way, > > actually. > > When I was using dhcp3-client (dhclient), this was always what I > saw: > > Aug 6 14:49:14 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 > Aug 6 14:49:20 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 > Aug 6 14:49:32 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11 > Aug 6 14:49:43 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21 > Aug 6 14:50:04 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 > Aug 6 14:50:11 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 > Aug 6 14:50:15 localhost dhclient: No DHCPOFFERS received. > Aug 6 14:50:15 localhost dhclient: No working leases in persistent database - sleeping.
This looks like 'dhclient' is doing all the right things - but your card isn't "hearing" any responses. This could be because 1) it's not actually sending anything out - but I doubt that, since you do connect in a secured-channel scenarion - or 2) because it's not "hearing" any DHCP "offers". I'm guessing that it's the latter. There are, in fact, two places where it can fail: the router may not get the broadcast DHCP requests that are being sent out by your card, or your card may not be picking up those offers.
> I removed all dhcp packages and installed pump, which gives: > > Aug 6 15:32:16 localhost cardmgr[935]: socket 0: Microsoft Wireless Notebook Adapter MN-520 > Aug 6 15:32:16 localhost cardmgr[935]: executing: 'modprobe hostap' > Aug 6 15:32:16 localhost cardmgr[935]: executing: 'modprobe hostap_cs' > Aug 6 15:32:17 localhost cardmgr[935]: executing: './network start wlan0' > Aug 6 15:32:18 localhost pumpd[1159]: PUMP: sending discover > Aug 6 15:32:48 localhost cardmgr[935]: + Operation failed. > Aug 6 15:32:48 localhost cardmgr[935]: + Failed to bring up wlan0.
Essentially "ditto". Note the 30-second delay between the discover and the failure message: that means that 'pump' actually kept trying to connect. This at least implies that everything on the stack up to that point is OK.
> Switching from the HostAP drivers to the orinoco_cs driver: > > Aug 8 12:08:52 localhost cardmgr[1215]: socket 1: Microsoft Wireless Notebook Adapter MN-520 1.0.3 > Aug 8 12:08:52 localhost cardmgr[1215]: executing: 'modprobe orinoco_cs' > Aug 8 12:08:53 localhost cardmgr[1215]: executing: './network start eth1' > Aug 8 12:08:53 localhost pumpd[1570]: starting at (uptime 0 days, 0:18:09) Tue Aug 8 12:08:53 2006 > Aug 8 12:08:53 localhost pumpd[1570]: PUMP: sending discover > Aug 8 12:09:23 localhost cardmgr[1215]: + Operation failed. > Aug 8 12:09:23 localhost cardmgr[1215]: + Failed to bring up eth1.
Interesting that HostAP maps it as 'eth1' rather than 'wlan0'. I got tired of the ipw2200 project changing their mind about the interface naming scheme and configured 'ifrename' so that mine's always 'wlan0' no matter how it comes up initially.
> Just for fun, this is what happens when I use my work > configuration. The only difference here is that I configure ESSID > and WEP key in /etc/network/interfaces: > > Aug 8 12:10:08 localhost pumpd[1570]: PUMP: sending discover > Aug 8 12:10:19 localhost pumpd[1570]: got dhcp offer > Aug 8 12:10:19 localhost pumpd[1570]: PUMP: sending second discover > Aug 8 12:10:19 localhost pumpd[1570]: reject: xid: 0xc30dac27 <--> 0xc30dac26 > Aug 8 12:10:19 localhost pumpd[1570]: PUMP: got an offer > Aug 8 12:10:19 localhost pumpd[1570]: reject: xid: 0xc30dac28 <--> 0xc30dac27 > Aug 8 12:10:19 localhost last message repeated 2 times > Aug 8 12:10:20 localhost pumpd[1570]: PUMP: got lease > Aug 8 12:10:20 localhost pumpd[1570]: intf: device: eth1 > Aug 8 12:10:20 localhost pumpd[1570]: intf: set: 416 > Aug 8 12:10:20 localhost pumpd[1570]: intf: bootServer: 172.16.241.1 > Aug 8 12:10:20 localhost pumpd[1570]: intf: reqLease: 43200 > Aug 8 12:10:20 localhost pumpd[1570]: intf: ip: 172.16.9.147 > Aug 8 12:10:20 localhost pumpd[1570]: intf: next server: 172.16.241.1 > Aug 8 12:10:20 localhost pumpd[1570]: intf: netmask: 255.255.252.0 > Aug 8 12:10:20 localhost pumpd[1570]: intf: gateways[0]: 172.16.8.254 > Aug 8 12:10:20 localhost pumpd[1570]: intf: numGateways: 1 > Aug 8 12:10:20 localhost pumpd[1570]: intf: dnsServers[0]: 172.16.89.1 > Aug 8 12:10:20 localhost pumpd[1570]: intf: dnsServers[1]: 172.16.32.10 > Aug 8 12:10:20 localhost pumpd[1570]: intf: numDns: 2 > Aug 8 12:10:20 localhost pumpd[1570]: intf: domain: <sanitized> > Aug 8 12:10:20 localhost pumpd[1570]: intf: broadcast: 172.16.11.255 > Aug 8 12:10:20 localhost pumpd[1570]: intf: network: 172.16.8.0 > Aug 8 12:10:20 localhost pumpd[1570]: configured interface eth1
Yep, looks normal.
> I had a friend loan me his PCMCIA card, and got this: > > Aug 8 19:35:56 localhost cardmgr[1068]: socket 1: U.S. Robotics IEEE 802.11b PC-CARD > Aug 8 19:35:56 localhost cardmgr[1068]: executing: 'modprobe hostap' > Aug 8 19:35:56 localhost cardmgr[1068]: executing: 'modprobe hostap_cs' > Aug 8 19:35:56 localhost cardmgr[1068]: executing: './network start wlan0' > Aug 8 19:35:57 localhost pumpd[1275]: PUMP: sending discover > Aug 8 19:36:27 localhost cardmgr[1068]: + Operation failed. > Aug 8 19:36:27 localhost cardmgr[1068]: + Failed to bring up wlan0.
It looks like his card is also an 802.11b.
> So I thought I'd use the interfaces config of: > > iface eth1 inet dhcp > wireless-essid any > wireless-mode managed > > And sat right in front of the coffee shop (they were closed), > figuring that this would connect to anything that was open. > > Aug 8 19:33:55 localhost cardmgr[1068]: socket 1: Microsoft Wireless Notebook Adapter MN-520 1.0.3 > Aug 8 19:33:56 localhost cardmgr[1068]: executing: 'modprobe orinoco_cs' > Aug 8 19:33:56 localhost cardmgr[1068]: executing: './network start eth1' > Aug 8 19:33:56 localhost pumpd[1275]: PUMP: sending discover > Aug 8 19:34:02 localhost pumpd[1275]: got dhcp offer > Aug 8 19:34:02 localhost pumpd[1275]: PUMP: sending second discover > Aug 8 19:34:32 localhost cardmgr[1068]: + Operation failed. > Aug 8 19:34:32 localhost cardmgr[1068]: + Failed to bring up eth1. > > This one seemed promising, since I got that "dhcp offer". And the > logs don't show it, but iwconfig showed the proper ESSID during the > time of the "second discover". > > These logs are the same as I've been seeing all along. > > So it appears that my card(s) can see the AP, but can't talk to the > DHCP server. I suppose it's also possible that the server is not > using DHCP, but it seems unlikely that this would be true for > every AP I've tried.
Well, I agree with your take on this, although there are a few gray areas in there. I.e., the possible failure points now look like this:
1) First DHCP offer (why is your system accepting the ESSID but not the IP/resolver info?) 2) What happened during the second discover? 3) Why didn't you get a second DHCP offer? Could it be that the AP couldn't 'hear' that one due to mode mismatch?
It certainly would be nice to see where that negotiation fails.
> So: I've tried multiple hotspots, multiple cards, multiple drivers. > Neither dhcp3-client nor pump can get a response from the server.
Well, again, it's not quite as clear as all that. The multiple cards/drivers are not fungible - that is, a specific card requires a specific driver, so they should be treated as a single unit (unless, of course, a specific combination of the two fails - in which case, you know what the problem is.) As to multiple cards with multiple hotspots - well, let me recap what we know:
a) 'dhcclient'/MN520: sends 'discover', no responses. b) 'pump'/MN520: ditto. c) 'pump'/MN520 in front of the coffee shop: partial negotiation.
We're missing a bunch of possibilities here; there's one in particular that I think would give us some useful info: your friend's card with 'pump' at the coffee shop (or maybe it was Col. Mustard in the library with an axe... I might be losing track.)
> Yesterday, I had my friend bring his laptop along. It's a D600 > instead of my C600. But he connected first time out and had no > troubles at all. That machine runs SuSE (9.3, I believe).
O-kay - more info. Is this at your house, or at the coffee shop? Does he have the same WiFi hardware in his machine as you?
> So I think tomorrow I'll take a couple hours off from work and just > park myself down at the coffee shop until I have tried all the > permutations (with logs). I haven't been very systematic about this > so far, because I've been rushed on each trip.
Excellent! That's what I'd like to see.
> (And I did have the cops cruise by to see why I was parked in front > of a closed coffee shop...)
Did you have them install Linux on their laptop and try to connect???
You missed a great opportunity, if not...
> My theories at this point are: 1) these APs are not set up to talk > 802.11b (and I only have "b" cards).
[Nod] That's where my thoughts are tending.
> 2) I'm not close enough to the > AP to get the discover request through. 3) my card does not have > the xmit power necessary to get the discover request through.
Hmmm. I say again, hmmmm.
Do check if your hardware supports 'get_power' (via 'iwpriv') - and even more importantly, 'set_power'. This might be worth playing with. Just for reference, here's my readout for all the 'get' variations:
ben at Fenrir:~$ iwpriv wlan0|awk '$1~/get/{system("iwpriv wlan0 "$1)}'
wlan0 get_power:Power save level: 6 (AC) OFF
wlan0 get_mode:802.11bg (6)
wlan0 get_preamble:auto (0)
> I'm not much inclined to theory 3), since I checked the power levels > for my work AP and they were close to the power levels of the coffee > shop AP. > > Oh, I did try tcpdump -i eth1, but there didn't seem to be any > traffic to capture (and I'm not sure what happened to my copy of > its output, so I'll do this again.)
Usually, you'll see the DHCP request going out, like so:
ben at Fenrir:~$ sudo tcpdump -vvv -i any tcpdump: WARNING: Promiscuous mode not supported on the "any" device tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 12:09:38.661135 IP (tos 0x0, ttl 64, id 17541, offset 0, flags [DF], proto: TCP (6), length: 60) localhost.38644 > localhost.bootpc: S, cksum 0x5313 (correct), 1044812096:1044812096(0) win 32767 <mss 16396,sackOK,timestamp 1299909 0,nop,wscale 2> 12:09:38.661607 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) localhost.bootpc > localhost.38644: R, cksum 0x4b0e (correct), 0:0(0) ack 1044812097 win 0
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *
Martin Hooper [martinjh at blueyonder.co.uk]
Fri, 11 Aug 2006 19:40:20 +0100
On 11/08/2006 Benjamin A. Okopnik wrote:
> > Aug 6 14:49:14 localhost dhclient: DHCPDISCOVER on wlan0 to > 255.255.255.255 port 67 interval 6 > > > Aug 6 14:49:20 localhost dhclient: DHCPDISCOVER on wlan0 to > 255.255.255.255 port 67 interval 12 > > > Aug 6 14:49:32 localhost dhclient: DHCPDISCOVER on wlan0 to > 255.255.255.255 port 67 interval 11 > > > Aug 6 14:49:43 localhost dhclient: DHCPDISCOVER on wlan0 to > 255.255.255.255 port 67 interval 21 > > > Aug 6 14:50:04 localhost dhclient: DHCPDISCOVER on wlan0 to > 255.255.255.255 port 67 interval 7 > > > Aug 6 14:50:11 localhost dhclient: DHCPDISCOVER on wlan0 to > 255.255.255.255 port 67 interval 4 > > > Aug 6 14:50:15 localhost dhclient: No DHCPOFFERS received. > > > Aug 6 14:50:15 localhost dhclient: No working leases in > persistent database - sleeping. > > This looks like 'dhclient' is doing all the right things - but your > card > isn't "hearing" any responses. This could be because 1) it's not > actually sending anything out - but I doubt that, since you do connect > in a secured-channel scenarion - or 2) because it's not "hearing" any > DHCP "offers". I'm guessing that it's the latter. There are, in fact, > two places where it can fail: the router may not get the broadcast > DHCP > requests that are being sent out by your card, or your card may not be > picking up those offers. > >
Port 67 firewalled?
Benjamin A. Okopnik [ben at linuxgazette.net]
Fri, 11 Aug 2006 23:06:26 -0400
On Fri, Aug 11, 2006 at 07:40:20PM +0100, Martin Hooper wrote:
> On 11/08/2006 Benjamin A. Okopnik wrote: > > > Aug 6 14:49:14 localhost dhclient: DHCPDISCOVER on wlan0 to > > 255.255.255.255 port 67 interval 6 > > > > Aug 6 14:49:20 localhost dhclient: DHCPDISCOVER on wlan0 to > > 255.255.255.255 port 67 interval 12 > > > > Aug 6 14:49:32 localhost dhclient: DHCPDISCOVER on wlan0 to > > 255.255.255.255 port 67 interval 11 > > > > Aug 6 14:49:43 localhost dhclient: DHCPDISCOVER on wlan0 to > > 255.255.255.255 port 67 interval 21 > > > > Aug 6 14:50:04 localhost dhclient: DHCPDISCOVER on wlan0 to > > 255.255.255.255 port 67 interval 7 > > > > Aug 6 14:50:11 localhost dhclient: DHCPDISCOVER on wlan0 to > > 255.255.255.255 port 67 interval 4 > > > > Aug 6 14:50:15 localhost dhclient: No DHCPOFFERS received. > > > > Aug 6 14:50:15 localhost dhclient: No working leases in > > persistent database - sleeping. > > > > This looks like 'dhclient' is doing all the right things - but your > > card > > isn't "hearing" any responses. This could be because 1) it's not > > actually sending anything out - but I doubt that, since you do connect > > in a secured-channel scenarion - or 2) because it's not "hearing" any > > DHCP "offers". I'm guessing that it's the latter. There are, in fact, > > two places where it can fail: the router may not get the broadcast > > DHCP > > requests that are being sent out by your card, or your card may not be > > picking up those offers. > > Port 67 firewalled?
[blink] It's a good thought - I'll admit that I missed considering that perspective - but I think not.
ben at Fenrir:~$ grep '\<67/' /etc/services bootps 67/tcp # BOOTP server bootps 67/udp
If the querent was trying to boot his machine via BOOTP (i.e., if it was a thin client or something like that), I'd agree that it would be a show stopper. As it is, it's worth checking out of curiosity, but I can't see it preventing DHCP negotiation.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *
Breen Mullins [bpm at idiom.com]
Sat, 12 Aug 2006 10:41:01 -0700
On Fri, Aug 11, 2006 at 11:06:26PM -0400, Benjamin A. Okopnik wrote:
> > Port 67 firewalled? > > [blink] It's a good thought - I'll admit that I missed considering that > perspective - but I think not. > > `` > ben at Fenrir:~$ grep '\<67/' /etc/services > bootps 67/tcp # BOOTP server > bootps 67/udp > '' > > If the querent was trying to boot his machine via BOOTP (i.e., if it was > a thin client or something like that), I'd agree that it would be a > show stopper. As it is, it's worth checking out of curiosity, but I > can't see it preventing DHCP negotiation.
DHCP is a superset of BOOTP and uses the same port...
Breen
-- Breen Mullins Menlo Park, California
Benjamin A. Okopnik [ben at linuxgazette.net]
Sat, 12 Aug 2006 14:54:49 -0400
On Sat, Aug 12, 2006 at 10:41:01AM -0700, Breen Mullins wrote:
> On Fri, Aug 11, 2006 at 11:06:26PM -0400, Benjamin A. Okopnik wrote: > > > Port 67 firewalled? > > > > [blink] It's a good thought - I'll admit that I missed considering that > > perspective - but I think not. > > > > `` > > ben at Fenrir:~$ grep '\<67/' /etc/services > > bootps 67/tcp # BOOTP server > > bootps 67/udp > > '' > > > > If the querent was trying to boot his machine via BOOTP (i.e., if it was > > a thin client or something like that), I'd agree that it would be a > > show stopper. As it is, it's worth checking out of curiosity, but I > > can't see it preventing DHCP negotiation. > > DHCP is a superset of BOOTP and uses the same port...
Ahh... I knew the first part of that, didn't know the second.
Lovely thing about TAG - there's always someone to backstop you!
"We should not be crippled by the knowledge that no one of us can know what all of us together know." -- The Shockwave Rider, John Brunner
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *
John Karns [jkarns at etb.net.co]
Wed, 9 Aug 2006 16:24:53 -0500 (COT)
On Sun, 6 Aug 2006, Benjamin A. Okopnik wrote:
> ben at Fenrir:~$ iwpriv wlan0 get_mode > wlan0 get_mode:802.11bg (6) > '' > > Check the AP mode as well.
I thought I'd try it here, but the configuration of this Ubuntu Breezy (5.10) laptop must be using a different version of the iwpriv utility than what you have:
root at jkInsp8100:/etc/network# iwpriv eth1 get_mode Invalid command : get_mode
-- John Karns
Benjamin A. Okopnik [ben at linuxgazette.net]
Wed, 9 Aug 2006 17:48:06 -0400
On Wed, Aug 09, 2006 at 04:24:53PM -0500, John Karns wrote:
> On Sun, 6 Aug 2006, Benjamin A. Okopnik wrote: > > > ben at Fenrir:~$ iwpriv wlan0 get_mode > > wlan0 get_mode:802.11bg (6) > > '' > > > > Check the AP mode as well. > > I thought I'd try it here, but the configuration of this Ubuntu Breezy > (5.10) laptop must be using a different version of the iwpriv utility > than what you have: > > root at jkInsp8100:/etc/network# iwpriv eth1 get_mode > Invalid command : get_mode
Some cards respond to 'get_mode' requests and others don't; 'iwpriv' without arguments will show which interfaces support which commands. I was hoping that Jeff's card would do 'get_mode', which would give us another bit of useful info.
On the other hand, he mentioned in his last post that his card only does mode B; this may well be the entire problem.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *
John Karns [jkarns at etb.net.co]
Sat, 12 Aug 2006 14:28:40 -0500 (COT)
On Wed, 9 Aug 2006, Benjamin A. Okopnik wrote:
> On Wed, Aug 09, 2006 at 04:24:53PM -0500, John Karns wrote: >> On Sun, 6 Aug 2006, Benjamin A. Okopnik wrote:
>> root at jkInsp8100:/etc/network# iwpriv eth1 get_mode >> Invalid command : get_mode > > Some cards respond to 'get_mode' requests and others don't; 'iwpriv' > without arguments will show which interfaces support which commands. I > was hoping that Jeff's card would do 'get_mode', which would give us > another bit of useful info. > > On the other hand, he mentioned in his last post that his card only does > mode B; this may well be the entire problem.
Perhaps you're right. Although he mentioned that his friend's mode B card did work, in a location where his own fails. Apart from that, too, I would be surprised if the various AP's he's been trying all reject mode B. I've yet to run into that problem myself.
And since mode G is backward compatible with B, virtually every 802.11g AP is compatible, It seems highly unlikely that all AP's he's tried would have been configured to override that. In a similar situation I would be inclined to boot from a Knoppix or other live Linux CD, explicitly trying a 2.6 kernel, in the interest of trying a different OS / driver environment. If he mentioned having done that, I guess I missed it.
The orinoco cards were in the past at least, one of the more ubiquitous wifi chips out there, and thus very commonly supported by the various distros. I have one myself, branded a Dell Truemobile 1150, which has always been the fall-back for me when the others fail to connect. It has always worked.
-- John Karns
Sat, 12 Aug 2006 23:34:18 -0600
John;
> In a similar situation I would be inclined to boot from a Knoppix > or other live Linux CD, explicitly trying a 2.6 kernel
Actually, this was next on my list. It's the easiest way to test out a different distro (although both Knoppix and Ubuntu are Debian derivations, so perhaps Slax?) One of my troubleshooting rules; if you can't seem to locate the trouble, change something. I didn't get the chance to make my 2-hour systematic test, but I've always been a believer in: change one variable, test, restore variable, repeat with all vars. At this point, I'm really anxious to try out something a bit more leading-edge than Sarge.
I have tried a 2.6 kernel, since the Orinoco drivers are supposed to be more current there. (In fact, the orinoco site seems to have dropped 2.4 support altogether.)
I am also looking into getting Wlan-ng drivers installed (there's not a Debian package that I can find); I'm encouraged by the fact that their config files for PCMCIA specifically include the MN-520 that I'm using.
Ben;
>> > > Port 67 firewalled?
I've tried it with (shudder) my firewall completely off. No change. (That one caught me when setting up my Zaurus...)
BTW, am I supposed to be seeing all this other message traffic? I couldn't find anything on the site about the TAG list. In any case, I did not see any of the discussion except what Ben forwarded.
> Does that mean that this discussion should ABEND tonight?
Ah hah! An old IBM mainframer in the mix... So does the bevel go on the left or right for a statement card?
Jeff Root
John Karns [jkarns at etb.net.co]
Sun, 13 Aug 2006 15:07:01 -0500 (COT)
On Sat, 12 Aug 2006, jeff at jeffroot.us wrote:
> John; > > > In a similar situation I would be inclined to boot from a Knoppix > > or other live Linux CD, explicitly trying a 2.6 kernel > > Actually, this was next on my list. It's the easiest way to test > out a different distro (although both Knoppix and Ubuntu are Debian > derivations,
You've tried it under Ubuntu? Regardless, since Knoppix is a live CD, there is little to lose by trying it. It has some of the best hardware detection out there, and is designed to configure itself on-the-fly each and every time it boots, whereas if you're testing with a pre-installed system, it may not adapt it's configuration as flexibly as a live CD. If you're comparing to Ubuntu's live CD, then it may be much the same. I would still consider it worth trying both.
> so perhaps Slax?) One of my troubleshooting rules; if > you can't seem to locate the trouble, change something. I didn't > get the chance to make my 2-hour systematic test, but I've always > been a believer in: change one variable, test, restore variable, > repeat with all vars. At this point, I'm really anxious to try out > something a bit more leading-edge than Sarge. > > I have tried a 2.6 kernel, since the Orinoco drivers are supposed to > be more current there. (In fact, the orinoco site seems to have > dropped 2.4 support altogether.)
AFAIK there are at least two distinct families of 802.11 cards referred to as Orinoco. (My understanding is that Orinoco was a brand name for a card which used a Prism chip.) I say distinct, because they implement different chips which do not share the same driver. We have to sort through names like Orinoco, Orinoco Gold, Prism, Prism2, Prism2.5, Prism3, etc. It all adds up to such a chaotic mess that even the mfr's can't seem to keep it straight. On top of that, the mfr's routinely change the internal designs of these products (i.e., chips used) without changing either the model number or the specifications on the packaging. [1]
We're left with doing some pre-purchase research, making the purchase, and hoping for the best. If the product isn't supported under Linux, then we rely on the seller to refund our money or allow us to exchange the merchandise for different product that we hope will prove to be functional under our OS of choice. [2]
> I am also looking into getting Wlan-ng drivers installed (there's > not a Debian package that I can find); I'm encouraged by the fact > that their config files for PCMCIA specifically include the MN-520 > that I'm using.
That family of drivers is for later versions of Prism (ver 2+) chips. Since the MN-520 is listed as Prism2/2.5/3, it should apply to your card. It doesn't support the earlier Orinoco chip such as the one in my Truemobile 1150 Orinoco card. The point I'm making here is that the Orinoco_cs driver is for the the earlier generation of Prism chips, I don't believe that it's the correct driver for the MN-520.
[1] Within the last year I purchased two Belkin USB 802.11g adaptors (model 5FD7050) with the same model number, in identical boxes, and having the same physical plastic casing. It turned out they had completely different electronic architectures. Furthermore, Belkin included the same CD with the same driver in each package, which lacked the driver for the older version of the product. The only way to sort it out was to disassemble them both and look at the chips used. Then I was able to search for the required (windoze) driver for the older version.
[2] Exchanging the product wasn't an option for me because I was then in a different country. It also turned out that, contrary to what I had read on the net about someone claiming to have gotten one of those devices to work with Linux, all I could find was some very preliminary driver code that was no where near functional under Linux, nor did the author claim it to be.
-- John Karns
Benjamin A. Okopnik [ben at linuxgazette.net]
Mon, 14 Aug 2006 23:49:36 -0400
On Sat, Aug 12, 2006 at 11:34:18PM -0600, jeff at jeffroot.us wrote:
> > Ben; > > >> > > Port 67 firewalled? > > I've tried it with (shudder) my firewall completely off. No > change. (That one caught me when setting up my Zaurus...)
I didn't think it would make any difference. If it had been a firewall issue, you should never have had even that one DHCP handshake. No way to tell until you try out some other options (i.e., your friend's card in several locations), but I'm suspicious of the hardware/driver combo. Again, too much conflicting data at the moment to have a definitive answer, but it kinda smells that way to me.
> BTW, am I supposed to be seeing all this other message traffic? I > couldn't find anything on the site about the TAG list. In any case, > I did not see any of the discussion except what Ben forwarded.
I'd noticed at some point that you accidentally got dropped from the CC list - whoops! - and that's why I forwarded that to you.
> > Does that mean that this discussion should ABEND tonight?
Not me; just a geek who's been around a few years, and appreciates the
overlap between the German and the GeekSpeak in this case.
> So does the bevel go > on the left or right for a statement card?
Isn't there a song about that?
Can't you see I'm going crazy? Won't somebody put me right? Does the spearmint lose its flavor on the bedpost over night?
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *
Pedro Fraile [pf at frailediaz.e.telefonica.net]
Sun, 06 Aug 2006 15:21:16 +0200
El 06/08/06 04:25:47, Benjamin A. Okopnik escribi?:
> Hi, Jeff - > > I'm going to CC the LG Answer Gang on my response, since this is > pretty > much the purpose of TAG; also, chances are that someone else may be > able > to cover any areas that I miss. > > On Sat, Aug 05, 2006 at 07:02:23PM -0600, jeff at jeffroot.us wrote: > > Ben Okipnik; > > "Okopnik", please.
Hi there,
My first experience with a public hotspot was just two weeks ago (Kubiwireless, at a Spanish airport), and it "just worked" too. I am using Ubuntu Dapper (based on Debian), and the DHCP client that is installed by default comes in the package dhcp3-client. I have not changed anything in its configuration. I also use ifup/ifdown to manage the connection, and the relevant part of my /etc/default/interfaces just contains:
iface eth1 inet dhcp wireless-key off
(I added the line "wireless-key off" because the output of "iwlist scan" showed something on the line of "no encryption". Not completely sure it is really needed, though)
After I issued the "ifup eth1", my /var/log/daemon.log included the following lines:
Jul 24 17:21:26 localhost dhclient: Internet Systems Consortium DHCP Client V3.0.3 Jul 24 17:21:26 localhost dhclient: Copyright 2004-2005 Internet Systems Consortium. Jul 24 17:21:26 localhost dhclient: All rights reserved. Jul 24 17:21:26 localhost dhclient: For info, please visit https://www.isc.org/products/DHCP Jul 24 17:21:26 localhost dhclient: Jul 24 17:21:27 localhost dhclient: Listening on LPF/eth1/0x:xx:xx:xx:xx:xx Jul 24 17:21:27 localhost dhclient: Sending on LPF/eth1/0x:xx:xx:xx:xx:xx Jul 24 17:21:27 localhost dhclient: Sending on Socket/fallback Jul 24 17:21:28 localhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7 Jul 24 17:21:28 localhost dhclient: DHCPOFFER from 10.185.0.1 Jul 24 17:21:28 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Jul 24 17:21:28 localhost dhclient: DHCPACK from 10.185.0.1 Jul 24 17:21:28 localhost dhclient: bound to 10.185.2.209 -- renewal in 751 seconds.
And that was it.
Best regards,
Pedro.
Thu, 17 Aug 2006 01:04:33 -0600
Ben;
OK, I've gotten some more time in on the troubleshoot. I'm still not connecting, but I now have some log files and tcpdumps.
I found my MN-520 stopped working at work, so I borrowed an Orinoco Gold (aka "old reliable"). This worked at work. I carefully cleaned all my /etc/network/interface and /etc/pcmcia/config.opts files, then visited my troublesome coffee shop.
I thought I was making some progress: when I inserted the card, I got a "New connection" message, followed by some "martian source" lines (I was running from a VT, so these were wall messages from, IIRC, the kernel). But it was traffic. I got a "failed to bring up eth1" message.
I rebooted with Knoppix (3.9 -- I tried the latest, but that turned my LCD into a lava lamp and locked the machine). Knoppix recognized and configured the card. I tried to bring up the interface with no success: same symptoms as my Sarge installation.
The one thing I've noticed, though, is that when I get "close enough" to the AP, I can see:
Aug 16 08:50:21 localhost pumpd[1278]: PUMP: sending discover Aug 16 08:50:27 localhost pumpd[1278]: got dhcp offer Aug 16 08:50:27 localhost pumpd[1278]: PUMP: sending second discover Aug 16 08:50:57 localhost cardmgr[1067]: + Operation failed. Aug 16 08:50:57 localhost cardmgr[1067]: + Failed to bring up eth1.
This seems consistent; I get an answer to the first discover but not the second. The RFC for DHCP doesn't seem to require 2 discovers, so I'm not sure what pump is doing here.
And I tried tcpdump. If eth1 was not up, tcpdump would exit. So I tried a machine-gun approach, starting "pump -i eth1" followed by a tcpdump. Here's the result:
15:08:58.385577 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 15:08:58.395954 arp who-has 169.254.1.51 tell 169.254.1.1 15:08:58.397085 arp who-has 169.254.1.51 tell 169.254.1.1 15:08:58.398200 arp who-has 169.254.1.51 tell 169.254.1.1 15:09:02.080455 IP 169.254.1.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 293 15:09:02.083702 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 15:09:06.083860 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 15:09:13.082798 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 15:09:19.895539 IP 169.254.1.31.53127 > 255.255.255.255.2222: UDP, length: 106 15:09:21.896457 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548
For comparison, here's a successful sequence from my work (closed) connection: (I replaced my employer's real domain with "example.com")
12:02:01.448556 IP localhost.localdomain.32791 > localhost.localdomain.bootpc: S 1462952572:1462952572(0) win 32767 <mss 16396,sackOK,timestamp 278840 0,nop,wscale 0> 12:02:01.448601 IP localhost.localdomain.bootpc > localhost.localdomain.32791: R 0:0(0) ack 1462952573 win 0 12:02:01.454701 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 12:02:01.675489 IP 172.16.8.234 > 224.0.0.1: igmp query v2 [max resp time 1] 12:02:01.679408 snap ui/C len=207 12:02:02.669519 snap ui/C len=33 12:02:04.146455 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:02:04.351467 IP 172.16.8.41.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:02:05.170266 IP 172.16.8.41.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:02:05.170637 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 12:02:07.218283 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:02:07.627667 arp who-has 172.16.8.176 tell 172.16.8.253 12:02:08.651576 arp who-has 172.16.8.58 tell 172.16.8.253 12:02:10.494677 IP 172.16.9.150.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:02:10.699380 arp who-has 172.16.8.58 tell 172.16.8.253 12:02:11.314061 arp who-has 172.16.8.254 tell 172.16.9.196 12:02:11.928130 IP 172.16.9.150.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:02:12.920623 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 12:02:13.361956 IP 172.16.8.104.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:02:13.567017 arp who-has 172.16.8.254 tell 172.16.9.119 12:02:19.095644 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:02:22.986615 arp who-has 172.16.8.254 tell 172.16.8.182 12:02:23.192098 arp who-has 172.16.9.107 tell 172.16.9.107 12:02:26.059446 arp who-has 172.16.8.129 tell 172.16.8.253 12:02:26.090627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 12:02:27.286858 arp who-has 172.16.8.254 tell 172.16.9.182 12:02:31.090638 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 12:02:31.091234 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 12:02:54.558355 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 12:02:54.730818 IP 172.16.8.235 > 224.0.0.1: igmp query v2 [max resp time 1] 12:02:54.731492 snap ui/C len=103 12:02:55.260117 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:02:55.727927 snap ui/C len=33 12:02:55.874608 IP 172.16.9.154.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:02:56.079146 arp who-has 172.16.8.254 tell 172.16.9.154 12:02:57.308356 IP 172.16.9.154.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:02:57.308711 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 12:02:57.514184 IP 172.16.8.253.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 362 12:02:57.514681 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 12:02:57.719136 IP 172.16.8.252.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 341 12:02:57.719804 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 12:03:01.710620 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 12:03:01.814242 IP 172.16.8.252.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 341 12:03:01.975074 IP 172.16.8.234 > 224.0.0.1: igmp query v2 [max resp time 1] 12:03:01.976026 snap ui/C len=207 12:03:02.101203 IP 172.16.9.30.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:02.101599 IP 172.16.9.180.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:02.101867 arp who-has 172.16.8.254 tell 172.16.8.112 12:03:02.105809 arp reply 172.16.8.254 is-at 00:00:0c:07:ac:08 12:03:02.105829 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36724+ PTR? 30.9.16.172.in-addr.arpa. (42) 12:03:02.120388 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36724 NXDomain* 0/1/0 (119) 12:03:02.120795 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36725+ PTR? 180.9.16.172.in-addr.arpa. (43) 12:03:02.123587 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36725 NXDomain* 0/1/0 (120) 12:03:02.123886 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36726+ PTR? 112.8.16.172.in-addr.arpa. (43) 12:03:02.127015 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36726 NXDomain 0/0/0 (43) 12:03:02.127329 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36727+ PTR? 1.89.16.172.in-addr.arpa. (42) 12:03:02.129944 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36727* 1/0/0 (75) 12:03:02.305496 IP 172.16.8.32.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:02.305733 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36728+ PTR? 32.8.16.172.in-addr.arpa. (42) 12:03:02.308838 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36728 NXDomain* 0/1/0 (100) 12:03:02.715501 IP 172.16.8.182.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:02.966491 snap ui/C len=33 12:03:03.124667 IP 172.16.9.180.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:04.148333 IP 172.16.9.180.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:04.148675 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:04.557888 IP 172.16.9.190.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:04.558348 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36729+ PTR? 190.9.16.172.in-addr.arpa. (43) 12:03:04.570752 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36729 NXDomain* 0/1/0 (120) 12:03:04.968184 arp who-has 172.16.8.254 tell 172.16.9.200 12:03:04.968505 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36730+ PTR? 200.9.16.172.in-addr.arpa. (43) 12:03:04.971970 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36730 NXDomain* 0/1/0 (120) 12:03:05.172841 IP 172.16.9.180.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:06.196174 IP 172.16.9.180.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:07.219906 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:09.267629 arp who-has cabletbacklap.wireless.example.com tell 172.16.8.253 12:03:09.267988 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36731+ PTR? 245.8.16.172.in-addr.arpa. (43) 12:03:09.273231 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36731 1/0/0 (88) 12:03:10.291684 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:11.520200 arp who-has 172.16.8.254 tell cblthall1200.wireless.example.com 12:03:11.520569 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36732+ PTR? 246.8.16.172.in-addr.arpa. (43) 12:03:11.524402 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36732 1/0/0 (87) 12:03:11.929977 IP 172.16.8.49.2081 > 172.16.11.255.2190: UDP, length: 133 12:03:11.930784 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36733+ PTR? 49.8.16.172.in-addr.arpa. (42) 12:03:11.933992 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36733 NXDomain* 0/1/0 (100) 12:03:12.953879 arp who-has 172.16.8.254 tell 172.16.8.170 12:03:12.954243 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36734+ PTR? 170.8.16.172.in-addr.arpa. (43) 12:03:12.958714 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36734 NXDomain* 0/1/0 (101) 12:03:14.387229 arp who-has cabletbacklap.wireless.example.com tell 172.16.8.253 12:03:16.230408 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:19.302156 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:19.506857 arp who-has 172.16.8.254 tell 172.16.9.89 12:03:19.507157 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36735+ PTR? 89.9.16.172.in-addr.arpa. (42) 12:03:19.515401 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36735 NXDomain* 0/1/0 (119) 12:03:20.124088 arp who-has 172.16.8.254 tell 172.16.9.200 12:03:21.349916 IP 172.16.9.198.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:03:21.350443 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36736+ PTR? 198.9.16.172.in-addr.arpa. (43) 12:03:21.353639 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36736 NXDomain* 0/1/0 (120) 12:03:21.964843 IP 172.16.9.198.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:03:22.169298 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:28.312962 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:30.361050 IP 172.16.9.198.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:03:30.974892 IP 172.16.9.198.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:03:31.180799 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:31.793884 IP 172.16.9.198.netbios-ns > 172.16.11.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:03:33.432570 arp who-has 172.16.8.254 tell 172.16.9.82 12:03:33.432933 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36737+ PTR? 82.9.16.172.in-addr.arpa. (42) 12:03:33.436183 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36737 NXDomain* 0/1/0 (119) 12:03:34.251786 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:34.252288 IP 172.16.9.180.netbios-dgm > 172.16.11.255.netbios-dgm: NBT UDP PACKET(138) 12:03:34.660804 arp who-has 172.16.8.254 tell 172.16.9.128 12:03:34.661117 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36738+ PTR? 128.9.16.172.in-addr.arpa. (43) 12:03:34.667384 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36738 NXDomain* 0/1/0 (120) 12:03:35.275197 arp who-has 172.16.8.254 tell 172.16.9.200 12:03:36.095414 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0b:7d:08:ae:f9, length: 315 12:03:36.299728 IP 172.16.8.252.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 374 12:03:36.300058 arp who-has 172.16.8.118 tell 172.16.8.118 12:03:36.300576 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36739+ PTR? 118.8.16.172.in-addr.arpa. (43) 12:03:36.306593 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36739 NXDomain* 0/1/0 (101) 12:03:36.708710 arp who-has 172.16.8.118 tell 172.16.8.118 12:03:37.323238 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:38.961383 arp who-has 172.16.8.254 tell 172.16.8.118 12:03:39.780405 arp who-has 172.16.8.254 tell 172.16.8.140 12:03:39.780771 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36740+ PTR? 140.8.16.172.in-addr.arpa. (43) 12:03:39.784928 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36740 NXDomain* 0/1/0 (101) 12:03:40.190776 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:44.490432 arp who-has 172.16.8.254 tell 172.16.9.101 12:03:44.491056 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36741+ PTR? 101.9.16.172.in-addr.arpa. (43) 12:03:44.501956 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36741 NXDomain* 0/1/0 (120) 12:03:49.200616 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:50.429154 arp who-has 172.16.8.254 tell 172.16.9.200 12:03:52.272422 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:55.344141 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:03:58.211513 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:04:01.282914 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:04:02.307689 arp who-has 172.16.8.254 tell 172.16.8.156 12:04:02.308055 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36742+ PTR? 156.8.16.172.in-addr.arpa. (43) 12:04:02.311307 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36742 NXDomain 0/1/0 (101) 12:04:04.354706 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:04:05.587814 arp who-has 172.16.8.254 tell 172.16.9.200 12:04:07.221974 IP 172.16.8.182.1718 > 255.255.255.255.192: UDP, length: 116 12:04:09.269663 arp who-has 172.16.8.254 tell 172.16.8.114 12:04:09.269963 arp who-has 172.16.8.254 tell 172.16.8.114 12:04:09.270150 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36743+ PTR? 114.8.16.172.in-addr.arpa. (43) 12:04:09.273267 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36743 NXDomain* 0/1/0 (101)
There's undoubtedly a lot of other traffic mixed in here. My card's MAC is: 00:02:2d:74:4a:fa, and I eventually got IP: 172.16.8.112.
I also tried KWifimanager under Knoppix: once I hit the "scan" button, it popped up a list of one AP (the name of the coffee shop), and when I hit OK, iwconfig showed this ESSID set, but I still got the "Failed to bring up eth1" message and no IP.
I'm convinced the first discover is what sets the ESSID (which I've seen happen several times), but somehow the second discover is not working.
But I have rudimentary knowledge of tcpdump (I've debugged some rarp stuff years ago under VMS, but we never had DHCP to contend with, and BOOTP just worked). So if anyone knows how to get more detail, and how to get it to capture only dhcp-related info, I'd appreciate it.
FWIW, I also tried some other live CD's. Gentoo won't even give me an "unsupported card in slot 1" error; it seems to notice insert and remove events, but doesn't do anything about them. Basilisk (FC3) didn't recognize the (MN-520) card. Kanotix (Debian sid based) recognized it and used the "hostap_cs" driver.
So, some progress, and I believe this is a DHCP negotiation problem. But I don't know how to see what is failing. Hopefully, someone can decode something from the tcpdump.
Cheers,
Jeff Root
Benjamin A. Okopnik [ben at linuxgazette.net]
Thu, 17 Aug 2006 23:37:23 -0400
Hi, Jeff -
On Thu, Aug 17, 2006 at 01:04:33AM -0600, jeff at jeffroot.us wrote:
> Ben; > > OK, I've gotten some more time in on the troubleshoot. I'm still > not connecting, but I now have some log files and tcpdumps. > > I found my MN-520 stopped working at work, so I borrowed an Orinoco > Gold (aka "old reliable"). This worked at work. I carefully > cleaned all my /etc/network/interface and /etc/pcmcia/config.opts > files, then visited my troublesome coffee shop.
I'm assuming that you're using the Orinoco for everything from here
forward - yes? If so, then my assumption of the problem being related to
your driver/card was wrong. 'K, we'll try another one then.
> I rebooted with Knoppix (3.9 -- I tried the latest, but that turned > my LCD into a lava lamp and locked the machine). Knoppix recognized > and configured the card. I tried to bring up the interface with no > success: same symptoms as my Sarge installation. > > The one thing I've noticed, though, is that when I get "close > enough" to the AP, I can see: > > Aug 16 08:50:21 localhost pumpd[1278]: PUMP: sending discover > Aug 16 08:50:27 localhost pumpd[1278]: got dhcp offer > Aug 16 08:50:27 localhost pumpd[1278]: PUMP: sending second discover > Aug 16 08:50:57 localhost cardmgr[1067]: + Operation failed. > Aug 16 08:50:57 localhost cardmgr[1067]: + Failed to bring up eth1. > > This seems consistent; I get an answer to the first discover but not > the second. The RFC for DHCP doesn't seem to require 2 discovers, > so I'm not sure what pump is doing here.
I've looked into it a bit, and it seems that this is indeed correct for how DHCP works.
1) Client broadcasts a DHCPDISCOVER to see if there's anyone within range (i.e., discover #1.) 2) All DHCP servers within range send a DHCPOFFER. 3) Client accepts the first responder's DHCPOFFER and puts out a DHCPREQUEST (i.e., discover #2) to that first server. 4) The server now sends back a DHCPACK to the client, which include the IP and the associated info (e.g., DNS servers.)
So the transaction between your machine and the server is failing somewhere toward the end of step 3 or in step 4. It clearly does accept a specific server (that's why you're getting that ESSID), but after that... well, let's see:
> And I tried tcpdump. If eth1 was not up, tcpdump would exit.
That's why I gave an example of 'tcpdump -i any'. It won't switch your interface into promiscuous mode, but it'll stay up even when the interface is down.
> So I > tried a machine-gun approach, starting "pump -i eth1" followed by a > tcpdump.
Not a bad idea - you'll miss a little bit, but since we know that the problem is happening a bit later, it should be fine.
> Here's the result: > > ---------------------------------------------------------------------- > > > 15:08:58.385577 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300
OK, there goes your "all stations" broadcast for DHCP.
> 15:08:58.395954 arp who-has 169.254.1.51 tell 169.254.1.1 > 15:08:58.397085 arp who-has 169.254.1.51 tell 169.254.1.1 > 15:08:58.398200 arp who-has 169.254.1.51 tell 169.254.1.1
Wait a minute - I've just smelled a rat. 169.254.X.X? That's an IP that's auto-assigned to an interface that requested a DHCP assignment but failed; note that it's not assigned by the server but by your kernel (google for 'APIPA' for more info; this is ridiculously common Wind0ws behavior, and I should have spotted it earlier.) The ARP request is the standard "before I assign this IP to this interface, is anyone else using it?" check.
In other words, it looks like your system never acknowledges any communication with the DHCP server other than the ESSID assignment. Even that's probably being assigned by your own system based on nothing more than beacon detection.
Or... OK, this is silly - but could it be that the coffee shop server's IP is actually set to be 169.254.1.1? In that case, your machine could just be rejecting that assignment, and properly so: that /16 is a reserved address range. Not 'reserved' as in '10.x.x.x' or '192.168.x.x', but as in 'do not use for anything but failed DHCP requests.'
It's a weird but possible explanation. Let's see if it holds up:
> 15:09:02.080455 IP 169.254.1.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 293
Well, something with an address of 169.254.1.1 actually does reply to you. /Tres/ weird...
> 15:09:02.083702 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 > 15:09:06.083860 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 > 15:09:13.082798 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 > 15:09:19.895539 IP 169.254.1.31.53127 > 255.255.255.255.2222: UDP, length: 106
...and something with another IP in the reserved range (169.254.1.31) answers. Yeah, it's beginning to look like a seriously misconfigured network.
> 15:09:21.896457 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548
These are all replies from your machine - possibly saying "nope, can't use that IP. How about something else?" - and that request never gets honored. I'm not certain of this, but it seems likely
> For comparison, here's a successful sequence from my work (closed) > connection: (I replaced my employer's real domain with "example.com") > > 12:02:01.448556 IP localhost.localdomain.32791 > localhost.localdomain.bootpc: S 1462952572:1462952572(0) win 32767 <mss 16396,sackOK,timestamp 278840 0,nop,wscale 0> > 12:02:01.448601 IP localhost.localdomain.bootpc > localhost.localdomain.32791: R 0:0(0) ack 1462952573 win 0
'K, that looks like the first offer/accept cycle.
> 12:02:01.454701 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300
That's your machine making the second request. Note that '0.0.0.0' - this means that you are on the network and have accepted the offer but have not yet received your IP.
> 12:02:26.090627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 > 12:02:31.090638 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 > 12:02:31.091234 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 > 12:02:54.558355 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 > 12:02:57.308711 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 300 > 12:02:57.514184 IP 172.16.8.253.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 362 > 12:02:57.514681 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 > 12:02:57.719136 IP 172.16.8.252.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 341 > 12:02:57.719804 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 > 12:03:01.710620 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:74:4a:fa, length: 548 > 12:03:01.814242 IP 172.16.8.252.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 341
This looks like the DHCP server rolling dice for the IP it can offer you from within its defined scope. "Anybody on this one? How about this one?"
> 12:03:02.101867 arp who-has 172.16.8.254 tell 172.16.8.112
Ta-daa! You've made it through negotiation, and have your IP.
> 12:03:02.105809 arp reply 172.16.8.254 is-at 00:00:0c:07:ac:08 > 12:03:02.105829 IP 172.16.8.112.32836 > pkyad01.pc.example.com.domain: 36724+ PTR? 30.9.16.172.in-addr.arpa. (42) > 12:03:02.120388 IP pkyad01.pc.example.com.domain > 172.16.8.112.32836: 36724 NXDomain* 0/1/0 (119)
Ummm... I know that this usually happens at the end of DHCP negotiation,
but I never figured out exactly what it did - even after trying to read
up on it. I seem to recall that the explanation of 'NXDomain' gave me a
hell of a headache.
> There's undoubtedly a lot of other traffic mixed in here. My card's > MAC is: 00:02:2d:74:4a:fa, and I eventually got IP: 172.16.8.112. > > I also tried KWifimanager under Knoppix: once I hit the "scan" > button, it popped up a list of one AP (the name of the coffee shop), > and when I hit OK, iwconfig showed this ESSID set, but I still got > the "Failed to bring up eth1" message and no IP.
I'm thinking that getting the beacon info is a separate (and much easier) sort of process from DHCP.
> I'm convinced the first discover is what sets the ESSID (which I've > seen happen several times), but somehow the second discover is not > working.
I don't know, Jeff. Perhaps the ESSID is just set as a 'flyer' - that is, "let's give this thing something, since we can always change it in the DHCPACK". In that case, it makes sense that it happens as soon as you initialize 'pump' - before any actual comms with the server happen.
> So, some progress, and I believe this is a DHCP negotiation problem. > But I don't know how to see what is failing. Hopefully, someone > can decode something from the tcpdump.
Just out of curiosity - what happens if you try to set the IP, gateway, etc. manually? I've done this on DHCP networks before, and it seems to work OK unless you set a conflicting IP.
iwconfig eth1 <wh.at.ev.er> route add default gw <gateway.ip.from.tcpdump> ping <gateway.ip>
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *
Kapil Hari Paranjape [kapil at imsc.res.in]
Fri, 18 Aug 2006 09:36:53 +0530
Hello,
On Thu, 17 Aug 2006, Benjamin A. Okopnik wrote:
> On Thu, Aug 17, 2006 at 01:04:33AM -0600, jeff at jeffroot.us wrote: > > I also tried KWifimanager under Knoppix: once I hit the "scan" > > button, it popped up a list of one AP (the name of the coffee shop), > > and when I hit OK, iwconfig showed this ESSID set, but I still got > > the "Failed to bring up eth1" message and no IP. > > I'm thinking that getting the beacon info is a separate (and much > easier) sort of process from DHCP.
I agree with Ben. Usually, DHCP comes after establishing the wireless link.
> > I'm convinced the first discover is what sets the ESSID (which I've > > seen happen several times), but somehow the second discover is not > > working. > > I don't know, Jeff. Perhaps the ESSID is just set as a 'flyer' - that > is, "let's give this thing something, since we can always change it in > the DHCPACK". In that case, it makes sense that it happens as soon as > you initialize 'pump' - before any actual comms with the server > happen.
In fact the ESSID is setup at the point when you select the wireless network which you want to join. Usually with a command that is equivalent to iwconfig wifi essid "Name"
I think that some form of "zeroconf" setup is what is happening here.
Under "zeroconf" (RFC 3927) two machines can network if they use addresses in the range 169.254.0.0/16. So what may be happening here:
1. The access point tries to communicate with you using zeroconf. 2. Provided you establish a zeroconf link it then requires authentication information. 3. Upon authentication it provides a "real" DHCP address.
So you should allow DHCP to fail and then establish a zeroconf address picked "at random" (the zeroconf package in Debian does this).
At this point if you try to connect (probably port 80) to any site you will be redirected to some authentication page. After authentication you will find that re-running DHCP will assign you an address.
This is all conjecture of course!
Hope it helps,
Kapil. --
Thu, 17 Aug 2006 23:59:59 -0600
Kapil & Ben;
I think we're closing in on it. What Kapil says about zeroconf using these reserved 169.254.x.x addresses seems to match what I'm seeing. (Although wouldn't that mean the shop patrons would need either a Mac or a WinXP box? Did Win2K do zeroconf?)
The zeroconf in Debian is only in Unstable. 'zcip' is in Stable; would that work? (The docs are sketchy, but it looks like I forget DHCP and just run "zcip -i wlan0". What the hell; I'll try it and report.)
An update on my hardware. I discovered that the MN-520 gave the "Network is unreachable" error only when using 'pump'. Keeping everything else the same, and swapping pump with dhcp3-client showed that the error only occurs when using pump. (I swapped them back and forth a few times to be sure.) A bit of Googling for "pump Prism2" seems to show this is a common problem. But I like dhcp3-client better anyway; it echoes the actual transactions to the log files. (And I had just picked out an FSF-approved B/G replacement card, too.)
Filed a bug report with Debian, and purged pump from the system.
But, being a belt-and-suspenders sort, I plan to keep the Orinoco on hand as well.
Also, a bit of reading seems to indicate that "tcpdump port 67 or 68" will capture just the BOOTP frames. I'll have to give "tcpdump -i any" another whirl -- I could have sworn it gave me a "syntax error" message.
I'm not sure I'll get a chance to do more testing until after Worldcon (the World Science Fiction Convention for you non-fans). I'm going to make a huge effort to retest tomorrow, but I'm leaving Saturday. I thought about going to the coffee shop now, but decided against it since the cops seem to be there all the time as well.
If there's an open WiFi anywhere near Worldcon, I'll be tcpdumping like a madman.
And if all else fails, I'll be back on the job when I return.
Thanks for the dump analysis: I'm really learning a lot about "why things work on a starship". Zeroconf: who knew?
Jeff Root
Rick Moen [rick at linuxmafia.com]
Fri, 18 Aug 2006 01:37:34 -0700
Quoting jeff at jeffroot.us (jeff at jeffroot.us):
> I'm not sure I'll get a chance to do more testing until after > Worldcon (the World Science Fiction Convention for you non-fans).
Jeff --
I'll be the moustachioed redhead with Xubuntu iBook bearing an "LNX" sticker. ;-> Staying with my wife Deirdre at the {sigh} Hilton.
(Eric Raymond's going to be there, too, but that's a moustache of a different colour.)
Benjamin A. Okopnik [ben at linuxgazette.net]
Fri, 18 Aug 2006 19:05:27 -0400
On Thu, Aug 17, 2006 at 11:59:59PM -0600, jeff at jeffroot.us wrote:
> Kapil & Ben; > > I think we're closing in on it. What Kapil says about zeroconf > using these reserved 169.254.x.x addresses seems to match what I'm > seeing. (Although wouldn't that mean the shop patrons would need > either a Mac or a WinXP box? Did Win2K do zeroconf?)
Truth to tell, once you start trying to figure out questions like "sure
we're operating from a broken premise, but if we use an axe here and a
pile of dead weasels *there", we could...", I get all confuzzled.
I might give it a tiny bit of time, just to see if it'll work with some
really simple tweaking, but otherwise, it's "later, gator". There's
rarely an imperative to adapt yourself to someone's broken crapola, and
little-to-no useful education in it. I'd look for another coffee shop.
> The zeroconf in Debian is only in Unstable.
That's not a big deal, usually; unless it depends on a pile of other unstable stuff, you could just download it and install it manually.
> 'zcip' is in Stable; > would that work? (The docs are sketchy, but it looks like I forget > DHCP and just run "zcip -i wlan0". What the hell; I'll try it and > report.)
Good way to go. I'm looking forward to hearing about it.
> Also, a bit of reading seems to indicate that "tcpdump port 67 or > 68" will capture just the BOOTP frames. I'll have to give "tcpdump > -i any" another whirl -- I could have sworn it gave me a "syntax > error" message.
Rick Moen [rick at linuxmafia.com]
Fri, 18 Aug 2006 16:14:41 -0700
Quoting Benjamin A. Okopnik (ben at linuxgazette.net):
> > The zeroconf in Debian is only in Unstable. > > That's not a big deal, usually; unless it depends on a pile of other > unstable stuff, you could just download it and install it manually.
I don't think I've ever pointed out, in this space, my modest compendium of information on ZeroConf implementations in Linux: "ZeroConf" on https://linuxmafia.com/kb/Network_Other/
I started putting that together when I notice applications like Gobby that use that sort of service.
Wed, 23 Aug 2006 10:52:28 -0600
Hello, again;
> There's rarely an imperative to adapt yourself to someone's broken > crapola
This appears to be exactly the problem. On my way to Worldcon, I tested the open wifi at the Salt Lake City airport: I get an IP address just fine. I was supposed to just "open the internet browser" (according to the announcement), and get the welcome page for their system. For some reason, this didn't work (I got "document contains no data" from Firefox). But I got the IP address just fine, so I'm calling this a different problem.
(It's probably related to what Kapil was talking about, but I didn't have time to experiment with my browser settings right then.)
I did a tcpdump -i any port 67 or 68 at slc, and here's the dump:
13:02:37.012699 IP 10.0.0.1.bootps > 10.0.0.89.bootpc: BOOTP/DHCP, Reply, length: 548 13:02:37.017162 IP 10.0.0.1.bootps > 10.0.0.89.bootpc: BOOTP/DHCP, Reply, length: 548 13:02:37.723137 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:9d:fb:b1, length: 300 13:02:37.723730 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:2d:9d:fb:b1, length: 312
This appears to be OK, although I'd rather have seen the DHPACK and IP acceptance info.
Now that I've arrived at the Hilton, I tested their wifi network. I appear to have no trouble getting an IP. I even got their "welcome" page up, listing the ridiculously high rates for network connectivity.
The tcpdump capture here was way to large to insert; I may recapture just the DHCP stuff later and send that along just for completion's sake.
One interesting thing; when I fired up the card with "any" essid, I did NOT get the Hilton's network. And I've been sniffing around with Kismet, and finding several other wifi networks. I'm going to have to think about this a bit; I don't think connecting to just anything is really what I want. I know security on wifi links is not really something I can expect, but there's no need to just give up everything if I don't have to.
> little-to-no useful education in it. I'd look for another coffee > shop.
I disagree. If I had never seen this coffee shop, I'd have never heard of Zeroconf. I'd have gone on thinking wifi under Linux "just works". I would never have been motivated to run tcpdump and watch DHCP do its thing.
But I think we can call this problem solved. I believe the sources of my problem were:
1) not knowing how to configure /etc/network/interfaces for an open
wifi
2) other machines that have worked with these hotspots are running
the latest KDE, which includes the zeroconf code
As I mentioned above, I think I've learned a few things about what's really going on, and more importantly, about how to troubleshoot the wifi system when it doesn't work. I made an offer to Ben that if the Gang would help me troubleshoot this, I'd write it up for the Gazette.
Once Worlddon is over, I'll see if Zeroconf will conquer the local hotspot. Regardless, I'll write up what I've learned, and hopefully someone else will benefit from this.
Jeff Root jeff at jeffroot.us
Benjamin A. Okopnik [ben at linuxgazette.net]
Thu, 24 Aug 2006 00:08:53 -0400
On Wed, Aug 23, 2006 at 10:52:28AM -0600, jeff at jeffroot.us wrote:
> Hello, again; > > > There's rarely an imperative to adapt yourself to someone's broken > > crapola > > This appears to be exactly the problem. On my way to Worldcon, I > tested the open wifi at the Salt Lake City airport: I get an IP > address just fine. I was supposed to just "open the internet > browser" (according to the announcement), and get the welcome page > for their system. For some reason, this didn't work (I got > "document contains no data" from Firefox). But I got the IP address > just fine, so I'm calling this a different problem.
Yep, it's an application-level problem now. If it was below that, Firefox would have reported something like "Unable to connect", instead.
> One interesting thing; when I fired up the card with "any" essid, I > did NOT get the Hilton's network. And I've been sniffing around > with Kismet, and finding several other wifi networks. I'm going to > have to think about this a bit; I don't think connecting to just > anything is really what I want.
You can specify the channel you want with 'iwconfig', if I recall corectly; that gives you the AP that you prefer.
> > little-to-no useful education in it. I'd look for another coffee > > shop. > > I disagree. If I had never seen this coffee shop, I'd have never > heard of Zeroconf. I'd have gone on thinking wifi under Linux "just > works". I would never have been motivated to run tcpdump and watch > DHCP do its thing.
Jeff, you clipped too much of what I'd said and lost the context as a result. I didn't say that you should have never tried to use that coffee shop; what I'm saying is that, once you discovered that their setup was broken, contorting yourself to fit their straitjacket (particularly when you're uncertain of how well your own system is working) makes no sense. If you want to do effective testing of your wireless, you need a simple, working, compliant wireless AP; trying to connect two unknowns is a recipe for lots of self-imposed pain.
> But I think we can call this problem solved.
Excellent!
> I believe the sources of my problem were: > > 1) not knowing how to configure /etc/network/interfaces for an open > wifi > > 2) finding several local hotspots that are poorly configured
Agreed.
> 2) other machines that have worked with these hotspots are running > the latest KDE, which includes the zeroconf code
I hadn't realized that; interesting.
> As I mentioned above, I think I've learned a few things about what's > really going on, and more importantly, about how to troubleshoot the > wifi system when it doesn't work. I made an offer to Ben that if > the Gang would help me troubleshoot this, I'd write it up for the > Gazette. > > Once Worlddon is over, I'll see if Zeroconf will conquer the local > hotspot. Regardless, I'll write up what I've learned, and hopefully > someone else will benefit from this.
That sounds really great, Jeff; I'm looking forward to seeing it!
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Benjamin A. Okopnik [ben at linuxgazette.net]
Fri, 18 Aug 2006 07:53:44 -0400
On Fri, Aug 18, 2006 at 09:36:53AM +0530, Kapil Hari Paranjape wrote:
> > In fact the ESSID is setup at the point when you select the wireless > network which you want to join. Usually with a command that is > equivalent to > iwconfig wifi essid "Name" > > I think that some form of "zeroconf" setup is what is happening here.
Ah, now we get a little more insight into the process!
> Under "zeroconf" (RFC 3927) two machines can network if they use > addresses in the range 169.254.0.0/16. So what may be happening here: > > 1. The access point tries to communicate with you using zeroconf. > 2. Provided you establish a zeroconf link it then requires > authentication information. > 3. Upon authentication it provides a "real" DHCP address. > > So you should allow DHCP to fail and then establish a zeroconf > address picked "at random" (the zeroconf package in Debian does > this).
Awesome. This is more or less the "manual" process that I was advocating; it's nice to know that there's an "official" route to doing it.
> At this point if you try to connect (probably port 80) to any site > you will be redirected to some authentication page. After > authentication you will find that re-running DHCP will assign you > an address. > > This is all conjecture of course!
Ah, but it's very tasty conjecture. At worst, it'll give us a
little more info about what's happening.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * https://linuxgazette.net *