[Dnsmasq-discuss] RaspberryPi PCAP file

Sat Dec 4 20:11:13 UTC 2021

On Sat, Dec 4, 2021 at 10:12 AM Geert Stappers via Dnsmasq-discuss
<dnsmasq-discuss at lists.thekelleys.org.uk> 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:
> > > On Thu, Dec 02, 2021 at 10:02:27PM +0000, Simon Kelley wrote:
> > > > I've not played with Pi, but assuming it's some variety of the PXE
> > > > protocol, that usually tries  pathnames constructed from the MAC
> > > > address, then the IP address with decreasing specificity (Ie
> > > > 192.168.1.100, then 192.168.1, then 192.168, then 192) and finally it
> > > > tries a fixed pathname. If you don't want to have machine-specific boot
> > > > files, just don't provide those files and the boot process will drop
> > > > though top the generic ones.
> > >
> > >
> > > 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

>
>
> 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-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]: file /srv/tftp/bootsig.bin not found
> > 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]: error 0 Early terminate received from 10.21.0.162
> > 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]: error 0 Early terminate received from 10.21.0.162
> > 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 neetboot needs are basically satisfied, 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.

> [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?  It would be easy enough for me to cut that
short.

> --
> Silence is hard to parse
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

-- 
Carl K