Werner Almesberger wrote: > "Marco Trevisan (Trevi??o)" wrote: >> I wanted to understand better this by running a packet sniffer while my >> notebook was in monitor-mode to understand what's happening, but I had >> no time (and who knows when I'll have :(). > > Yes, this looks like the kind of problem that could benefit from a > little sniffing.
Ok, I had some time to perform this test, but my results are not so good. See below. > Oh, and in case you're considering tcpdump for this, please use > airodump-ng instead. tcpdump subtly mis-decodes the 802.11 packets > it captures, guaranteeing no end of fun when trying to make sense > of the resulting mess ... airodump-ng was what I had in mind and what I've used; thanks for the advice, anyway! ;) > Maybe check if wmiconfig -i eth0 --power maxperf does something. > After all, we know that it has some mysterious but apparently very > reproducible effect on this kind of oddities. I've tried with it too, but nothing changes. >> Werner, maybe have you done some research about this too? > > I have yet to encounter a scenario where one protocol would pass > but others don't, e.g., everything but DHCP in your case or John > Sullivan's black hole for ICMP echo. Ok, I've tried sniffing my packages. My first test was in normal condition, that is with my AP running with DHCP enabled and encrypting traffic with a "WPA2-Personal Mixed" key (WPA/WPA2 with TKIP/AES psk support). In this scenario, I can generally associate with wpa_supplicant but when I run udhcpc I get no answer from the AP (or the phone doesn't grab it). So, I've sniffed my packages that are obviously encrypted... However recent builds of Wireshark should allow me to decrypt also 802.11 wpa-encrypted packages. Unfortunately I've not been able too, since wireshark needs at least 4 eapol packages to decrypt the data and I had none (also if I started to dump before of associating the phone). Myabe this is due to the card I'm using for monitoring? I've an ipw2200 and it has always worked when it come to monitoring wireless traffic. However both using airodump-ng and kismet, I had no dump files with eapol data inside. Have you any advice to catch them (maybe associating/reassociating another PC to the AP could help)? So I have only encrypted logs, but from these I can see (looking at the MACs) that there are some data-transfers from the phone to the AP and vice-versa while I'm running udhcpc... However I can't see what they're "saying" each others, but it seems that there's a contact. However, as I was unable to decrypt my dumps, I decided to disable any wireless protection from my AP. This time, after the association I ran udhcpc but... r...@om-gta02:~# udhcpc eth0 udhcpc (v1.11.1) started Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... Sending select for 192.168.10.7... Lease of 192.168.10.7 obtained, lease time 345600 adding dns 192.168.10.1 adding dns 208.67.222.222 adding dns 208.67.220.220 As you can see, it worked. It took some time (also if I'm quite near to the AP), but it worked. I've retried it again with dhclient and I got a fast answer: Listening on LPF/eth0/00:12:cf:8e:ef:4b Sending on LPF/eth0/00:12:cf:8e:ef:4b Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 DHCPOFFER from 192.168.10.1 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 192.168.10.1 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from 192.168.10.1 bound to 192.168.10.7 -- renewal in 129953 seconds. Again, with udchpc and a new dhcp offer after the first discover attempt. So, I've looked at my dumps with wireshark, and there I can see that on the first attempt (which took longer) I get: pkg type 75 DHCP Discover 76 ARP request (who has 192.168.10.7? Tell 192.168.10.1) 80 DHCP Offer 81 DHCP Discover 83 DHCP Offer 84 DHCP Discover 85 DHCP Offer So the first offers are ignored by the phone, that finally grabs it (I figure). If you want I can send you my .pcap dump taken with airodump, but it basically says the same that you can figure from the dhcp tools logs. So, all this to say that: - My test doesn't seem to be valid, since here the DHCP works (also if not perfectly) if I'm not using a wpa protection (I've not tested wep, sorry). - There are issues with the DHCP and wpa that unfortunately I wasn't able to study. I should find an open AP that doesn't give me an IP (one is at my pub, but, you know... I can't go there to monitor wireless packages :P), and find a way to decrypt my wpa-encrypted dumps. -- Treviño's World - Life and Linux http://www.3v1n0.net/
