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.
Regarding dhcp client problem
Started by ●September 26, 2005
Reply by ●September 26, 20052005-09-26
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
Reply by ●September 26, 20052005-09-26
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
Reply by ●September 26, 20052005-09-26
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 :).
Reply by ●October 4, 20052005-10-04
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
Reply by ●October 4, 20052005-10-04
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 >allTake 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.