[U-Boot-Users] dhcp problems with Windows Server
Hello,
I'm seeing problems with the DHCP mechanism in U-Boot and the DHCP server on Windows Server 2000/2003. We use U-Boot 1.2 on an at91rm9200 based platform with the DM9161 PHY.
Now I understand that this may not be a U-Boot problem, but for the sake of interoperability it may be a good idea to try and fix it as many people use Windows Server ...
Normally we use Un*x DHCP servers and I get 100% success rate but with the Microsoft version of DHCP I see about a 75% success rate. i.e. 1 in 4 requests will fail.
Looking at the packets with Ethereal, it looks like the DHCP server isn't sending the final "DHCP ACK" for the "DHCP Request" from the U-Boot. Something that U-Boot is sending in the "DHCP Request" to the Windows Server is causing it to fail occasionally.
As a comparison, I used udhcpc from Busybox to make the DHCP request and I get a 100% success rate.
There are some obvious differences between the requests from the two pieces of software. (my test Windows Server 2003 DHCP server is on 10.1.1.1 and is offering 10.1.1.2). As I am not a low level DHCP packet expert, perhaps someone else can make sense of this. I will also start studying the BOOTP options fields and try and understand if any of the U-Boot DHCP packet options are incorrect.
** U-Boot DHCP sequence **
DHCP Discover: Seconds Elapsed = 1 Your (client) IP address: 0.0.0.0 (0.0.0.0) Next server IP address: 0.0.0.0 (0.0.0.0) Option 53: DHCP Message Type = Discover Option 57: Maximum DHCP Message Size = 576 Option 55: Parameter Request List 1 = Subnet Mask 3 = Router 12 = Host name 17 = Root Path
DHCP Request: Seconds Elapsed = 1 Your (client) IP address: 10.1.1.2 (10.1.1.2) Next server IP address: 10.1.1.1 (10.1.1.1) Option 53: DHCP Message Type = DHCP Request Option 57: Maximum DHCP Message Size = 576 Option 54: Server Identifier = 10.1.1.1 Option 50: Requested IP Address = 10.1.1.2 Option 55: Parameter Request List 1 = Subnet Mask 3 = Router 12 = Host name 17 = Root Path
** udhcpc DHCP sequence **
DHCP Discover: Seconds Elapsed = 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) Option 53: DHCP Message Type = DHCP Discover Option 61: Client Identifier Hardware type: Ethernet Client MAC address: ... Option 60: Vendor class identifier = "udhcp 0.9.9-pre" Option 55: Parameter Request List 1 = Subnet Mask 3 = Router 6 = Domain Name Server 12 = Host Name 15 = Domain Name 28 = Broadcast Address 40 = Network Information Service Domain 41 = Network Information Service Servers 42 = Network Time Protocol Servers
DHCP Request: Seconds Elapsed = 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) Option 53: DHCP Message Type = DHCP Request Option 61: Client Identifier Hardware type: Ethernet Client MAC address: ... Option 60: Vendor class identifier = "udhcp 0.9.9-pre" Option 50: Requested IP Address = 10.1.1.2 Option 54: Server Identifier = 10.1.1.1 Option 55: Parameter Request List 1 = Subnet Mask 3 = Router 6 = Domain Name Server 12 = Host Name 15 = Domain Name 28 = Broadcast Address 40 = Network Information Service Domain 41 = Network Information Service Servers 42 = Network Time Protocol Servers
regards,
Aras Vaichas
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Aras Vaichas wrote:
Hello,
I'm seeing problems with the DHCP mechanism in U-Boot and the DHCP server on Windows Server 2000/2003. We use U-Boot 1.2 on an at91rm9200 based platform with the DM9161 PHY.
Now I understand that this may not be a U-Boot problem, but for the sake of interoperability it may be a good idea to try and fix it as many people use Windows Server ...
Normally we use Un*x DHCP servers and I get 100% success rate but with the Microsoft version of DHCP I see about a 75% success rate. i.e. 1 in 4 requests will fail.
Looking at the packets with Ethereal, it looks like the DHCP server isn't sending the final "DHCP ACK" for the "DHCP Request" from the U-Boot. Something that U-Boot is sending in the "DHCP Request" to the Windows Server is causing it to fail occasionally.
Sorry to answer my own question, but I've found the problem and a solution.
The problem appears to be that Windows Server is occasionally too slow to be able to process the DHCP request. If the time between Windows Server sending the "DHCP Offer" and U-Boot sending the "DHCP Request" is too short, the Microsoft DHCP server fails to send the DHCP ACK.
I discovered this when I compiled debugging in to net/bootp.c and I proved it when I delayed the "DHCP Request" by a small amount (using a printf).
e.g. a DHCP discovery request
U-Boot: DHCP Discover? Windows Server DHCP server: DHCP Offer = a.b.c.d ** insert small delay here ** U-Boot: DHCP Request = a.b.c.d? Windows Server DHCP server: DHCP ACK
I'm not sure what the actual delay should be and I'm not sure where it should go. Wolfgang, can you suggest a place to put a delay, and should it be wrapped in a CONFIG_ option?
regards,
Aras Vaichas
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
In message 452C8358.40009@magellan-technology.com you wrote:
I'm not sure what the actual delay should be and I'm not sure where it should go. Wolfgang, can you suggest a place to put a delay, and should it be wrapped in a CONFIG_ option?
I don't want to add such a delay. The RFC does not include any timing information, which means that packets can be sent immediately.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 452C8358.40009@magellan-technology.com you wrote:
I'm not sure what the actual delay should be and I'm not sure where it should go. Wolfgang, can you suggest a place to put a delay, and should it be wrapped in a CONFIG_ option?
I don't want to add such a delay. The RFC does not include any timing information, which means that packets can be sent immediately.
Wolfgang,
I fully understand that and no-one wants to have to include delays in their system but unfortunately Microsoft didn't write their DHCP server code to allow for a client which responds as quickly as U-Boot can.
No-one is ever going to be able to fix old copies of Windows Server, so I suggest an interoperability patch which allows U-Boot to work better with Windows Server DHCP service. A small delay at boot time is certainly a lot cheaper than spending hours on the telephone for customer support.
Our product has a customer base of over 1000 units and most of those will, unfortunately, use Windows Server 2000/2003 as their DHCP server. We've known for a long time that certain DHCP servers were causing problems and we were telling people that they should use a fixed IP address until they fixed their DHCP service. It wasn't until we sent an engineer from Australia to France that we knew the depth of this interoperability problem.
My testing shows that a delay of around 15ms before sending the "DHCP Request" will work 100% of the time with the VMware Windows Server 2003 that I set up on my PC so I am going to put a delay of 30ms in my U-Boot image for safety.
I will send a U-Boot upgrade package to several of our customer sites for testing before I roll it out to all of our customers.
regards,
Aras Vaichas
--- current/net/bootp.c 2005-11-18 12:18:48.000000000 +1100 +++ u-boot-1.1.3-MAGARMv3/net/bootp.c 2006-10-11 16:35:51.000000000 +1000 @@ -844,6 +844,10 @@ NetSetIP(iphdr, 0xFFFFFFFFL, PORT_BOOTPS, PORT_BOOTPC, iplen);
debug ("Transmitting DHCPREQUEST packet: len = %d\n", pktlen); + // delay a small amount because Windows Server 2003 has problems if you reply too quickly + // 15ms was proven to be OK on my at91rm9200 system, so I'll double it just in case + udelay(30000); + NetSendPacket(NetTxPacket, pktlen); }
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
In message 452D825F.8040304@magellan-technology.com you wrote:
I fully understand that and no-one wants to have to include delays in their system but unfortunately Microsoft didn't write their DHCP server code to allow for a client which responds as quickly as U-Boot can.
;-)
--- current/net/bootp.c 2005-11-18 12:18:48.000000000 +1100 +++ u-boot-1.1.3-MAGARMv3/net/bootp.c 2006-10-11 16:35:51.000000000 +1000 @@ -844,6 +844,10 @@ NetSetIP(iphdr, 0xFFFFFFFFL, PORT_BOOTPS, PORT_BOOTPC, iplen);
debug ("Transmitting DHCPREQUEST packet: len = %d\n", pktlen);
// delay a small amount because Windows Server 2003 has problems if youreply too quickly
// 15ms was proven to be OK on my at91rm9200 system, so I'll double itjust in case
udelay(30000);NetSendPacket(NetTxPacket, pktlen);}
Please submit a proper patch, i. e.
* Include a CHANGELOG entry * Make sure not to violate the coding style (no C++ comments, indentation by TABs, line length < 70 * Make sure that your mailer does not wrap lines
Best regards,
Wolfgang Denk
In message 452C3EEA.9010202@magellan-technology.com you wrote:
I'm seeing problems with the DHCP mechanism in U-Boot and the DHCP server on Windows Server 2000/2003. We use U-Boot 1.2 on an at91rm9200 based platform with the DM9161 PHY.
Please update to the latest version, i. e. top of tree in git repository.
Best regards,
Wolfgang Denk
participants (2)
-
Aras Vaichas -
Wolfgang Denk