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.
