I have found the bug, it's a one-line change in netinet/if_ether.c
@@ -574,5 +574,4 @@ in_arpinput(m)
m_freem(m);
return;
}
- ia = ifatoia(ifa);
match:
I am waiting for re@ to approve the commit. The c
On Thu, Dec 20, 2001 at 11:08:14PM -0800, Luigi Rizzo wrote:
> On Fri, Dec 21, 2001 at 12:02:15PM +0800, Yusuf Goolamabbas wrote:
> > >
> > > How repeatable is the problem ? It shouldn't be hard to track, it looks
> > > like a null pointer dereference.
> >
> > 100% repeatable. The strange part i
On Fri, Dec 21, 2001 at 12:02:15PM +0800, Yusuf Goolamabbas wrote:
> >
> > How repeatable is the problem ? It shouldn't be hard to track, it looks
> > like a null pointer dereference.
>
> 100% repeatable. The strange part is that the same rules including the
> ${fwcmd} add 400 pass udp from 0.0.
> I wonder if this isn't related to some change in the handling of
> interface lists, routes or arp entries. I do not recall any recent
> change in the dummynet/bridge code that might cause this.
>
> On passing. the line ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
> has not been suppor
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: 4.4-stable kernel panic with dummynet/bridging. Same rules
work fine with 4.3-RC
I wonder if this isn't related to some change in the handling of
interface lists, routes or arp entries. I do not recall any recent
change in the
I wonder if this isn't related to some change in the handling of
interface lists, routes or arp entries. I do not recall any recent
change in the dummynet/bridge code that might cause this.
On passing. the line ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
has not been supported for a lo
H I thought it was just me, and I hadn't had a chance yet to go
digging. I just enabled OPTIONS = BRIDGE in the kernel and I was getting
spontaneous reboots, but they pointed to NATD blowing up. Essentially
the same error though. Removing OPTIONS = BRIDGE seems to have stopped
the reboots.
