dhcpcd-discuss

On Mon, Mar 27, 2017 at 11:59 AM, Roy Marples <roy@xxxxxxxxxxxx> wrote:

> On 07/03/2017 20:57, Shahid Mahmood wrote:
> > Hi Roy,
> > There is a crash found during restart of dhcpcd. Brief bt:
> > ...
> >
> >     Core was generated by `dhcpcd -4 -f /var/run/dhcp/dhcpcd.conf -c
> >     /bin/dhcpcd-run-hooks --l'.
> >     Program terminated with signal SIGSEGV, Segmentation fault.
> >     ...
> >
> >     #0  0x3d737264 in ?? ()
> >     #1  0x0001e0d4 in arp_packet (len=<optimized out>, data=0xbee65938
> "",
> >         ifp=<optimized out>) at arp.c:180
> >     #2  arp_read (arg=0xfdc108) at arp.c:206
> >     #3  0x00010148 in eloop_start (eloop=0xfdbdc8, signals=0xbee65a70,
> >         signals@entry=0xbee65a68) at eloop.c:969
> >     #4  0x0000aff0 in main (argc=<optimized out>, argv=<optimized out>)
> >         at dhcpcd.c:1940
> >
> >     # dhcpcd --version
> >     dhcpcd 6.11.5
> >     Copyright (c) 2006-2016 Roy Marples
> >     Compiled in features: INET IPv4LL INET6 DHCPv6 AUTH
> >
> > Detailed bt attached, as well as dhcpcd.conf. I am trying to reproduce
> > the crash but not too hopeful if it will occur again.
> >
> > Let me know if you need any more info.
>
> OK, I tracked this down after giving the Solaris port some loving.
>
That is great news!

>
> Because of the BPF API on BSD and Solaris, we need to read the whole BPF
> buffer from the kernel and process that packet by packet. Linux doesn't
> have this limitation but has to have the same processing loop in dhcp.c
> and arp.c.
>
> The actual issue is that during packet processing, the state could be
> freed at any time. But this is not being checked before trying to read
> the next packet.
>
> The reason why this hasn't been seen by myself until now is all my
> machines are quite quick and the code will naturally break the loop with
> EOF before the next qualifying ARP packet hits the interface. The only
> reason why I just found this now is that my Solaris dev box is emulated
> on a NetBSD XEN host and that is quite slow. It takes minutes to boot
> rather than seconds the other guests take. Also, the BPF implementation
> on Solaris is documented to be quite slow as well .. well slow at
> notifying userland of new packets so they queue and expose this error.
>
> I've pushed patches to trunk and dhcpcd-6 branches to fix this.
>
Thanks for the fix! Will it be available a release? If so which one?

>
> Roy
>

-shahid