EmbeddedRelated.com
Forums

Regarding dhcp client problem

Started by jaekkay September 26, 2005
I am working on a handheld device which consits of ARM7+DSP dual
core[TI (TMS 470) board].

I am using modified version of Kiwiknet TCP/IP networking stack which
contains dhcp client. The device can be configured with static and dhcp
ip modes. In dhcp mode the device is not getting ip address through the
WLAN. I am using 2003 server as dhcp server.


I am able to detect the request from device by using protocol
analyzers-ethereal. But the there is no response from windows dhcp
server. But the other devices like pocket PCs[with wince] are able to
get ip address.  The same thing happens when i try with some 3rd party
dhcp server.

Plz give me some suggestions regarding this.

On 26 Sep 2005 05:12:49 -0700, "jaekkay" <jaekkay@gmail.com> wrote:

>But the there is no response from windows dhcp server.
Obviousely the server does not like the DHCP query. How about compareing two queries (one from a working device and one of yours)? There must be a difference. DHCP is not that difficult to understand so you may want to read the RFC. HTH Markus
jaekkay wrote:
> I am able to detect the request from device by using protocol > analyzers-ethereal. But the there is no response from windows dhcp > server.
Verify the checksums on the packets you're sending. Richard
jaekkay <jaekkay@gmail.com> wrote:
>I am working on a handheld device which consits of ARM7+DSP dual >core[TI (TMS 470) board].
>I am using modified version of Kiwiknet TCP/IP networking stack which >contains dhcp client. The device can be configured with static and dhcp >ip modes. In dhcp mode the device is not getting ip address through the >WLAN. I am using 2003 server as dhcp server.
>I am able to detect the request from device by using protocol >analyzers-ethereal. But the there is no response from windows dhcp >server. But the other devices like pocket PCs[with wince] are able to >get ip address. The same thing happens when i try with some 3rd party >dhcp server.
>Plz give me some suggestions regarding this.
Use "tcpdump -vvv" on a unix box. Or try etherreal. (I use www.freebsd.org) I think u might have to look trough your packet byte by byte (if unlucky :).
I have captured the packet information from the device. For the
discover request from the device, win2k dhcp server sends (broadcasts)
offer. But the dhcp client in the device is not receiving the offer at
all

Here is the packet information from ethereal (Sorry for such large
amount of text)

DISCOVER Request from device:

No.     Time        Source                Destination
Protocol Info
     22 73.141000   0.0.0.0               255.255.255.255       DHCP
 DHCP Discover - Transaction ID 0x22334455

Frame 22 (342 bytes on wire, 342 bytes captured)
    Arrival Time: Oct  4, 2005 12:30:58.165016000
    Time delta from previous packet: 1.193086000 seconds
    Time since reference or first frame: 73.141000000 seconds
    Frame Number: 22
    Packet Length: 342 bytes
    Capture Length: 342 bytes
    Protocols in frame: eth:ip:udp:bootp
Ethernet II, Src: 10.0.0.4 (00:b0:00:12:12:28), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: 10.0.0.4 (00:b0:00:12:12:28)
    Type: IP (0x0800)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 328
    Identification: 0xaa98 (43672)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 120
    Protocol: UDP (0x11)
    Header checksum: 0x970d [correct]
    Source: 0.0.0.0 (0.0.0.0)
    Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
    Source port: bootpc (68)
    Destination port: bootps (67)
    Length: 308
    Checksum: 0xf434 [correct]
Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x22334455
    Seconds elapsed: 0
    Bootp flags: 0x8000 (Broadcast)
        1... .... .... .... = Broadcast flag: Broadcast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: 10.0.0.4 (00:b0:00:12:12:28)
    Server host name not given
    Boot file name not given
    Magic cookie: (OK)
    Option 53: DHCP Message Type = DHCP Discover
    Option 51: IP Address Lease Time = infinity
    Option 55: Parameter Request List
        1 = Subnet Mask
        3 = Router
        6 = Domain Name Server
        15 = Domain Name
    End Option
    Padding



OFFER Response from win2k dhcp Server:

No.     Time        Source                Destination
Protocol Info
     23 73.141206   10.10.1.1             255.255.255.255       DHCP
 DHCP Offer    - Transaction ID 0x22334455

Frame 23 (346 bytes on wire, 346 bytes captured)
    Arrival Time: Oct  4, 2005 12:30:58.165222000
    Time delta from previous packet: 0.000206000 seconds
    Time since reference or first frame: 73.141206000 seconds
    Frame Number: 23
    Packet Length: 346 bytes
    Capture Length: 346 bytes
    Protocols in frame: eth:ip:udp:bootp
Ethernet II, Src: 10.10.1.1 (00:11:25:96:f1:91), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: 10.10.1.1 (00:11:25:96:f1:91)
    Type: IP (0x0800)
Internet Protocol, Src: 10.10.1.1 (10.10.1.1), Dst: 255.255.255.255
(255.255.255.255)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 332
    Identification: 0x19e0 (6624)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (0x11)
    Header checksum: 0x14b7 [correct]
    Source: 10.10.1.1 (10.10.1.1)
    Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
    Source port: bootps (67)
    Destination port: bootpc (68)
    Length: 312
    Checksum: 0xf95d [correct]
Bootstrap Protocol
    Message type: Boot Reply (2)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x22334455
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 10.0.0.4 (10.0.0.4)
    Next server IP address: 10.10.1.1 (10.10.1.1)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: 10.0.0.4 (00:b0:00:12:12:28)
    Server host name not given
    Boot file name not given
    Magic cookie: (OK)
    Option 53: DHCP Message Type = DHCP Offer
    Option 1: Subnet Mask = 255.0.0.0
    Option 58: Renewal Time Value = 5 days, 1 hour, 30 minutes
    Option 59: Rebinding Time Value = 8 days, 20 hours, 37 minutes, 30
seconds
    Option 51: IP Address Lease Time = 10 days, 3 hours
    Option 54: Server Identifier = 10.10.1.1
    Option 6: Domain Name Server = 10.10.1.1
    Option 15: Domain Name = "skimmerdev.skimmerdev"
    End Option

On 4 Oct 2005 03:14:04 -0700, "jaekkay" <jaekkay@gmail.com> wrote:

>I have captured the packet information from the device. For the >discover request from the device, win2k dhcp server sends (broadcasts) >offer. But the dhcp client in the device is not receiving the offer at >all
Take a debugger and follow the packet as it arrives in the device. If you can't do this, then your best bet is to contact the supplier of the TCP stack you are using. My bet is that the DHCP client code is not happy with the offer. I.e. it's missing optional things like i.e. the DNS servers etc. and hence considers the offer not being worthwile. HTH Markus PS: Btw, next time, put the ehteral dump on an FTP or webserver and post the linkt. It's a lot easier to download and look at the dump in ethereal than go through what you posted here.