[ipxe-devel] iPXE doesn't load when using ISC Kea 1.1

[Ledochowski, Roy]

Hi again

I've tested it with sending the 'file' option alone and with 'file' and option 67.  Kea fails both tests in the same manner.  DHCPd succeeds with only the 'file' option as expected.


-----Original Message-----
From: ipxe-devel-bounces at lists.ipxe.org [mailto:ipxe-devel-bounces at lists.ipxe.org] On Behalf Of Geert Stappers
Sent: Thursday, January 05, 2017 12:32 PM
To: ipxe-devel at lists.ipxe.org
Subject: Re: [ipxe-devel] iPXE doesn't load when using ISC Kea 1.1

On Thu, Jan 05, 2017 at 05:08:37PM +0000, Ledochowski, Roy wrote:
> From: Geert Stappers, Sent: Wednesday, January 04, 2017 9:55 PM
> To: Ledochowski, Roy <roy.ledochowski at hpe.com>; 
> ipxe-devel at lists.ipxe.org
> > On Thu, Jan 05, 2017 at 12:25:19AM +0000, Ledochowski, Roy wrote:
> > > Michael Brown, Sent Wednesday, January 04, 2017 4:00 PM:
> > > > 
> > > > Use tcpdump to capture the raw packets (add "-w tcpdump.out") 
> > > > and then open the resulting file in wireshark.  You'll be able 
> > > > to see the destination MAC along with all other packet fields.
> > > 
> > > You're exactly right. DHCPd sends its offer to the broadcast 
> > > address while Kea sends to  the client's unicast address.  It 
> > > seems the PXE ROM doesn't care.
> > > 
> > 
> > I saw in the "text tcpdump" another possible error.
> > 
> > Now that there are raw packets captures (generated with "-w 
> > filename"), I would like to analyze both. Please sent me[1] the  kea 
> > capture and the dhcpd capture.
> > 
> 
> Hi Geert
> 
> Thanks for the reply.  I sent the two captures to you directly.
> 

Yes, got them.

Where I missed in the original posting in the DHCP offer a value for parameter 67, bootfilename, is that value missing both in the working and _non_ working dhcp server.

Other observations:

* iPXE is being loaded as undionly.kpxe for the "original bootROM"
* the "original bootROM" is happy with both unicast and broadcast DHCP offers
* in the working configuration there is twice "DHCP Discover plus DHCP Offer",
  the "original bootROM" does only once "DHCP Discover plus DHCP offer"
* iPXE does four "DHCP Discovers". Packets 111, 113,117 and 119
* Kea does four "DHCP Offers". Packets 112, 114, 118 and 120


And the most interresting observation is packet 116 in the Kea.pcap, which is a reply on packet 115 in capture file.

115: DHCP server doing an ARP request for the iPXE client
116: the iPXE client ARP replying "I have that IPv4 address"

$ /usr/sbin/tcpdump -nr kea.pcap arp | $( some_filtering )
01:02:27.978877 ARP, Request who-has 10.1.1.124 tell 10.1.1.20, length 28
01:02:27.979055 ARP, Reply 10.1.1.124 is-at 00:0c:29:73:f2:92, length 46

So some part of the the DHCP offer from kea is processed correctly.


Groeten
Geert Stappers
--
Leven en laten leven