[Dnsmasq-discuss] RaspberryPi PCAP file

Sat Dec 4 21:07:02 UTC 2021

On Sat, Dec 04, 2021 at 12:11:13PM -0800, Carl Karsten wrote:
> On Sat, Dec 4, 2021 at 10:12 AM Geert Stappers wrote:
> > On Sat, Dec 04, 2021 at 12:42:52PM +0100, Community Member via Dnsmasq-discuss wrote:
> > > On Fri, Dec 3, 2021 at 12:50 PM Geert Stappers wrote:
> > > >
> > > > What would help is providing a fairly complete  network packet capture
> > > > of a Raspi attempting to netboot.
> > > >
> > > wget http://now.zapto.org/temp/RPI3bp13.pcap
> > > client Raspberry Pi 3 Model B Plus Rev 1.3
> >
> > My observation on the PCAP file
> > * there are several stages
> > * each stage starts with a (partial) DHCP session
> >
> >
> > The first stage:
> > * DHCP Discover with option 97, Client Identifier,
> >   f6 27 6d 7a f6 27 6d 7a f6 27 6d 7a f6 27 6d 7a
> >   from client
> > * DHCP Offer with filename 'ipxe/undionly.kpxe'
> >   from server
> > * No DHCP Request, No DHCP Acknowledge
> > * Client TFTP Requests 'bootcode.bin'
> > * Server TFTP sents that 'bootcode.bin'
> 
> > * Client TFTP Requests 'bootsig.bin'
> > * Server TFTP sents 'bootcode.bin'
> 
> Are you sure?
> client requests bootsig,..
> server sends bootcode...
> implies the server ignores the request and sends something else.
> 
> I'm guessing this is a typo on your part, as the server log shows:
> Dec  3 16:59:51 rpi-cb-1f-f7 dnsmasq-tftp[1584]: file
> /srv/tftp/bootsig.bin not found
> which is correct, there no bootsig.bin

Euh yes, a typo on my part.

> > The second stage:
> > * DHCP Discover with option 97, Client Identifier,
> >   f6 27 6d 7a f6 27 6d 7a f6 27 6d 7a f6 27 6d 7a
> >   from client  (yes, that is the same identifier)
> > * DHCP Offer with filename 'ipxe/undionly.kpxe'
> >   from server (yes, that is the same filename)
> > * No DHCP Request, No DHCP Acknowledge
> > * Client TFTP Requests '7a6d27f6/start.elf'
> > * Server response not clear to me
> > * Client TFTP Requests '7a6d27f6/start.elf'
> > * Server response not clear to me
> > * Client TFTP Requests '7a6d27f6/autoboot.txt
> >
> > At that point there was enough information for me.  I'm only interested
> > in a better dnsmasq. For a better netbooting raspi am I NO stakeholder.[1]
> 
> Totally fine.  It isn't clear to me how you would even help fix pi as
> I don't think we get the source code.
> For any nonbelivers, this is something the Beagle Bone Black has to
> offer: much more open, which implies part of the pi is not open.
> 
> >
> > I do see a match in the begin of the Client Identifier ( f6 27 6d 7a )
> > and the "serial number" (7a6d27f6). More network captures should prove
> > that match.[2]
> 
> 
> 
> >
> >
> >
> > > server log from one boot:
> > > Dec  3 16:51:43 rpi-cb-1f-f7 dnsmasq-tftp[1584]: sent /srv/tftp/bootcode.bin to 10.21.0.162
> > > Dec  3 16:51:43 rpi-cb-1f-f7 dnsmasq-dhcp[1584]: DHCPDISCOVER(eth-local) b8:27:eb:6d:27:f6
> > > Dec  3 16:51:43 rpi-cb-1f-f7 dnsmasq-dhcp[1584]: DHCPOFFER(eth-local) 10.21.0.162 b8:27:eb:6d:27:f6
> > > Dec  3 16:51:43 rpi-cb-1f-f7 dnsmasq-tftp[1584]: failed sending /srv/tftp/7a6d27f6/start.elf to 10.21.0.162
> > > Dec  3 16:51:43 rpi-cb-1f-f7 dnsmasq-tftp[1584]: file /srv/tftp/7a6d27f6/autoboot.txt not found
> > > Dec  3 16:51:43 rpi-cb-1f-f7 dnsmasq-tftp[1584]: failed sending /srv/tftp/7a6d27f6/start.elf to 10.21.0.162
> > > Dec  3 16:51:43 rpi-cb-1f-f7 dnsmasq-tftp[1584]: sent /srv/tftp/7a6d27f6/config.txt to 10.21.0.162
> > > Dec  3 16:51:43 rpi-cb-1f-f7 dnsmasq-tftp[1584]: file /srv/tftp/7a6d27f6/recovery.elf not found
> > > Dec  3 16:51:47 rpi-cb-1f-f7 dnsmasq-tftp[1584]: sent /srv/tftp/7a6d27f6/start.elf to 10.21.0.162
> > > Dec  3 16:51:47 rpi-cb-1f-f7 dnsmasq-tftp[1584]: sent /srv/tftp/7a6d27f6/fixup.dat to 10.21.0.162
> > > Dec  3 16:51:48 rpi-cb-1f-f7 dnsmasq-tftp[1584]: file /srv/tftp/7a6d27f6/recovery.elf not found
> >
> > In https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q4/015955.html
> > is a reference to --dhcp-script as in the dnsmasq manual page.  The dhcp-script has
> > access to the environment variable DNSMASQ_CLIENT_ID
> 
> Thank you!
> 
> >
> > I think that can solve the original problem (
> >  https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q4/015954.html
> > ).
> >
> >
> > Groeten
> > Geert Stappers
> >
> > Foot notes:
> > [1] Make me stakeholder by providing enough RaspberryPi hardware
> >     Even better provide me with hardware that should get better
> >     netbooting.
> 
> My pi netboot needs are basically satisfied,

OK

And what about the dnsmasq needs that did get us here???

> but enabling contributions is a thing I do.
> I'll put some effort into this, but I'm not sure it makes sense for
> you to spend time on the pi's client given there may not be a path for
> patches to be accepted.
> 
> https://github.com/raspberrypi/firmware/blob/master/boot/LICENCE.broadcom
> """
> Redistribution. Redistribution and use in binary form, without
> modification, are permitted provided that the following conditions are
> """
> 
> My first effort will be to see if I can find someone that would be
> interested in accepting your work.

Retransmitting

> > [1] Make me stakeholder by providing enough RaspberryPi hardware
> >     Even better provide me with hardware that should get better
> >     netbooting.

I think that makes

> My first effort will be to see if I can find someone that would be
> interested in accepting your work.

another effort as "first effort".

> > [2] I'm willing to check more .pcap files
> 
> I'm assuming much of the 97mb is after the kernel boots.  Is there
> anything useful there?

No, nothing useful in that part.

> It would be easy enough for me to cut that short.

The worthwhile thing is 
> > I do see a match in the begin of the Client Identifier ( f6 27 6d 7a )
> > and the "serial number" (7a6d27f6). More network captures should prove
> > that match.[2]

Groeten
Geert Stappers
-- 
Silence is hard to parse