[Dnsmasq-discuss] RaspberryPi PCAP file

Sun Dec 5 00:03:55 UTC 2021

On Sat, Dec 4, 2021 at 1:42 PM Geert Stappers via Dnsmasq-discuss
<dnsmasq-discuss at lists.thekelleys.org.uk> wrote:
>
> 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???
>
>

Hmm.. I'm not out of the weeds just yet.

> > > 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

I need access to that value.  That's the serial number  f6 27 6d 7a
repeated 4 times.
but not
DNSMASQ_CLIENT_ID=01:b8:27:eb:6d:27:f6

Here is a quick test I did:
dhcp-script=/root/dnsmasq-test1.sh

/root/dnsmasq-test1.sh
#!/bin/bash -x
echo $* >> /tmp/dnsmasq-test1.txt
/usr/bin/env  >> /tmp/dnsmasq-test1.txt

/tmp/dnsmasq-test1.txt
old b8:27:eb:6d:27:f6 10.21.0.162 raspberrypi
DNSMASQ_TAGS=eth-local
DNSMASQ_INTERFACE=eth-local
DNSMASQ_VENDOR_CLASS=dhcpcd-8.1.2:Linux-5.10.63-v8+:aarch64:BCM2835
LANGUAGE=en_US:en
DNSMASQ_TIME_REMAINING=21600
DNSMASQ_CLIENT_ID=01:b8:27:eb:6d:27:f6
PIDFILE=/run/dnsmasq/dnsmasq.pid
DNSMASQ_LEASE_EXPIRES=1638680174
PWD=/
LANG=en_US.UTF-8
INVOCATION_ID=3bcf8de10dbb44e6b6d844ab5fa06d17
DNSMASQ_REQUESTED_OPTIONS=1,121,33,3,6,12,15,26,28,51,54,58,59,119
SHLVL=1
DNSMASQ_DOMAIN=video.debconf.org
JOURNAL_STREAM=8:28400
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DNSMASQ_SUPPLIED_HOSTNAME=raspberrypi
_=/usr/bin/env

>
> > 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]
>

Clever (nick of one of the regulars in #raspberrypi irc) recalled seeing this.

>
>
>
> Groeten
> Geert Stappers
> --
> 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