Wireless DHCP issues

["Marco Trevisan (Treviño)"]

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...

root at 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/