PXE boot Redhat Enterprise Linux 4 update 7, 8 fails for hosts on the same subnet as the dhcp server about staticdhcpd

[GoogleCodeExporter]

I know this is ancient, and that you've likely found a fix or moved on by now, 
but if you are still able to reproduce this, can you attach a PCAP 
(tcpdump/Wireshark) trace of what both systems see?

My guess is that the ports involved aren't what staticDHCPd expects to deal 
with and that the packets are actually being sent, but aren't being received. 
An alternative is that an option that RHEL was looking for isn't present, and 
there may be a hint in its request that can be used to adapt behaviour 
appropriately.

Original comment by red.hamsterx on 29 Mar 2012 at 5:39

[GoogleCodeExporter]

Guessing this is done since it's been a year.

Original comment by red.hamsterx on 27 Mar 2013 at 5:24

• Changed state: Done

[GoogleCodeExporter]

The pxebooting (bootp) involves two rounds of 'handshakes' between dhcp server 
and client. See: http://www.tcpipguide.com/free/t_BOOTPDetailedOperation.htm 
The booting does not work for EL4 U7/U8 probably because when dhcp server 
answers the client request for the second handshake, it still does a 
'broadcast' as it does for the first round. I changed the flag to 'unicast', 
then the server was able to boot. Why EL5 and later hosts were able to work, I 
have no idea.

Original comment by [email protected] on 28 Mar 2013 at 8:35

[GoogleCodeExporter]

Curious...

In all cases, the code will check the sender's address and determine whether 
the client's IP is unicast or not 
(http://code.google.com/p/staticdhcpd/source/browse/branches/logging-web/staticD
HCPd/staticdhcpdlib/dhcp.py?r=477#800) before deciding where to send the 
response. PXE should be no different.

I know it's been a long time, and thanks for following up, Andrew, but if you 
can give me a pcap for this situation (both working and not), I'd like to study 
it to see if I can spot the abnormality or otherwise see if I can compensate 
for the unusual behaviour.

There's no hard requirement in the PXE specs, from what I recall, that says the 
server providing PXE must be the same as the server providing DHCP, so it's 
unreasonable for the client to expect that the second server knows its lease 
status. That said, since, in this case, the server does know the lease-status 
of the client, sending two packets, one unicast and one broadcast, in the case 
of PXE, shouldn't cause any problems and that can be made an option pretty 
easily.

Original comment by red.hamsterx on 28 Mar 2013 at 8:47

• Changed state: Accepted

[GoogleCodeExporter]

Actually, I'll just go ahead and build those in as options in 2.0.0:
 * An option to make all PXE requests go to client_ip, regardless of whether it was a broadcast request or not
 * An option to make all PXE requests, if they look like a broadcast request, go to both addresses

2.0.0 should have an RC package tomorrow, unless I get hit with something big 
before then.

Original comment by red.hamsterx on 28 Mar 2013 at 8:59

[GoogleCodeExporter]

Actually, no, that's a mistake on my side. I missed the clause that said if 
ciaddr is non-zero, use ciaddr instead. I'll make the change and release 1.5.8 
and 1.6.3 with a corresponding patch when I release 2.0.0.

Original comment by red.hamsterx on 28 Mar 2013 at 9:17

[GoogleCodeExporter]

Ok, I might have misled you with the 'broacast/unicast' statement earlier. This 
has been quite some time for me too. I looked again at my code and your recent 
code 
(http://code.google.com/p/staticdhcpd/source/browse/branches/logging-web/staticD
HCPd/staticdhcpdlib/dhcp.py?r=477#800).
For the line below in 'def _handleDHCPDiscover':   
  self._sendDHCPPacket(
                     wrapper.packet, wrapper.source_address, wrapper.pxe,
                     wrapper.mac, definition.ip
                    )
For my 'fix', I did a check to see if the discover request is from the first or 
second round communication. If it is from second round, I just set the 
wrapper.source_address to the ip that I know that should be assigned to the 
client. Instead of relying on whatever that is sent back from the client. My 
earlier confusion of 'broadcast/unicast' probably stemed from my observation 
that the cases where the boot failed, the wrapper.source_address was all 
255.255.255.255, instead of the client's actual IP address. So this might be a 
bug of Redhat Enterprise linux 4 that failed to set the src ip in the packet 
properly and was fixed in Redhat 5?  Unfortunately I don't have the testing 
environment to do a pcap.

Original comment by [email protected] on 28 Mar 2013 at 9:32

[GoogleCodeExporter]

No, I don't think you misled me at all, Andrew.

ciaddr and the sender's actual address are two entirely different things: the 
first one is part of the packet, saying "this is my address" and the second one 
is the address of the socket that actually sent the packet.

My code has only been looking at the socket's address, oblivious to the 
possibility that the client might be using broadcast to find the PXE server 
(which makes sense here, because the DHCP server has no obligation to set the 
next server's IP in the response packet if it doesn't know that the client 
requires PXE), while still including a bit of information saying "I'd like to 
be contacted here, please".

This is a logical error on my side and it was likely addressed by RedHat 
accepting broadcast responses as equivalent to unicast in later versions of the 
software they included.

Original comment by red.hamsterx on 28 Mar 2013 at 9:38

[GoogleCodeExporter]

1.6.8 and 1.5.7 have been published, with the change also integrated into 2.0.0.

Since you've already found a fix for this issue, I'll close it as Fixed. I 
don't expect you to test it on my behalf, because RHEL 4 is old and your 
environment is probably stable now, but thank you very much for reporting it 
and for helping to find the problem.

Original comment by red.hamsterx on 28 Mar 2013 at 10:16

• Changed state: Fixed