On 25.09.2014 15:07, Sean Bruno wrote: > On Thu, 2014-09-25 at 09:18 +0400, Gleb Smirnoff wrote: >> On Wed, Sep 24, 2014 at 07:40:23PM -0700, Adrian Chadd wrote: >> A> Hm, I saw this from Kate on IRC. Did anyone figure out _where_ these >> A> frames are coming from? >> A> >> A> Just dropping them is cool, but I'd really like to see the contents of >> A> the frames and what their origin is. >> A> >> A> I'm worried that they're valid stack-generated frames.. >> >> I agree on this. Fixing NULL pointer derefs with NULL check is not >> always a right thing to do. >> A> > >> A> > Log: >> A> > Fix NULL pointer deref in ipfw when using dummynet at layer 2. >> A> > Drop packet if pkg->ifp is NULL, which is the case here. >> A> > >> A> > ref. https://github.com/HardenedBSD/hardenedBSD >> A> > commit 4eef3881c64f6e3aa38eebbeaf27a947a5d47dd7 >> A> > >> A> > PR 193861 -- DUMMYNET LAYER2: kernel panic >> A> > >> A> > in this case a kernel panic occurs. Hence, when we do not get an >> interface, >> A> > we just drop the packet in question.
> Ok, moving off to freebsd-net. How should we proceded with debugging > further? Probably this can occurs when outgoing interface disappeared (netgrapg/tun/tap/lagg/vlan/usb ethernet), but packets were not send yet (delayed in the dummynet pipe). I think this is well known problem. -- WBR, Andrey V. Elsukov _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
