.. so now there's a patch:
* is there a PR for this?
* if there is, can we get this patch and the discussion about this bug
placed in the PR? :)
That way it doesn't get lost. No, I lie. It doesn't get "too lost". :-)
Adrian
___
freebsd-net@freebsd.or
2011/9/29 Mikolaj Golub :
>
> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote:
>
> KM> Sorry, didn't look at the images (limited bw), I've seen something
> KM> like this before in timewait. This "can't happen" with UDP so will be
> KM> interested in learning more about the bug.
>
> The panic ca
On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote:
KM> Sorry, didn't look at the images (limited bw), I've seen something
KM> like this before in timewait. This "can't happen" with UDP so will be
KM> interested in learning more about the bug.
The panic can be easily triggered by this:
test_
On Wed, Sep 28, 2011 at 11:09:46AM +0200, Olivier Cochard-Labb wrote:
> Hi Yvan,
>
> 2011/9/28 VANHULLEBUS Yvan :
> >
> >> I'm trying to protect RIPng and OSPFv3 (I'm using Quagga and Bird),
> >> but I didn't know how to manage multicast traffic with setkey.
> >
> > You can't: IPsec has NOT be des
Hi Yvan,
2011/9/28 VANHULLEBUS Yvan :
>
>> I'm trying to protect RIPng and OSPFv3 (I'm using Quagga and Bird),
>> but I didn't know how to manage multicast traffic with setkey.
>
> You can't: IPsec has NOT be designed to protect multicast traffic
> (well, there are actually at least some drafts in
On Tue, Sep 27, 2011 at 10:26:32PM +0200, Olivier Cochard-Labb wrote:
> Hi,
Hi.
> I'm trying to protect RIPng and OSPFv3 (I'm using Quagga and Bird),
> but I didn't know how to manage multicast traffic with setkey.
You can't: IPsec has NOT be designed to protect multicast traffic
(well, there a
