[TAG] LG 127 Wifi
Benjamin A. Okopnik
ben at linuxgazette.net
Fri Aug 11 20:16:03 MSD 2006
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 * http://linuxgazette.net *
More information about the TAG
mailing list