On Wed, Jan 5, 2011 at 8:32 PM, Jan Johansson wrote:
>
> So I found a bug here.
>
> Your mk2 patch (didn't try the mk1) does not advertise gif
> tunnels this works with the unpatched binary.
Apologies for the delay on this one - finally got around to setting up
a test environment today. See [1] f
On Mon, Jan 3, 2011 at 5:27 PM, Jan Johansson wrote:
> If an CARP interface is in BACKUP state the route is still
> advertised which leads to assymetric routing.
Ok, the following should fix this. It's a little more involved; here's
what's new:
- Avoid sending LSAs if the link state is down (to a
Hi,
I've found that if an interface is declared passive (or is a CARP
interface) in ospf6d.conf, ospf6d will not send LSAs for that
interface, and any associated prefixes will not be advertised. This is
contrary to the behaviour in ospfd and what I would expect.
The problem appears to be that ori
On Wed, Jun 23, 2010 at 9:20 PM, Claudio Jeker wrote:
>
> We need to make sure it does not break something. This diff can affect
> both bridge(4) and trunk(4) so both setups need to be tested with
> various setting of promisc interfaces.
I've done some performance testing for various combinations
On Wed, Jun 23, 2010 at 12:57 AM, Claudio Jeker
wrote:
>
> I think something like the attached version may be the best solution.
> I don't like to do the bcmp() for every unicast packet since network cards
> come with nice mac filters that make this superfluous.
> From code inspection bridge(4) sh
On Wed, Jun 16, 2010 at 7:46 PM, Stuart Henderson
wrote:
> On 2010/06/16 18:36, Patrick Coleman wrote:
>> /*
>>* If packet is unicast and we're in promiscuous mode, make sure it
>>* is for us. Drop otherwise.
>> + *
>> +
Hi,
As discussed on misc@, I've come across a bug in OpenBSD's handling of
gratuitous Ethernet traffic, and it was suggested that I move the
discussion over here.
What I've found is that with certain configurations, an OpenBSD box
receiving Ethernet traffic with a destination MAC address that is
