headers
Robert Swindells | 22 May 2012 18:46
Picon

bridge diffs


There are several PRs open on bridge(4).

I have been using the following diffs for a while now, they add bpf(4)
support as well as adding a static address cache entry for each
member interface.

Being able to use bpf on the bridge as well as any members may help
people to work out what is going on in their usage.

I would commit it in two parts. Any comments ?

Robert Swindells

Index: if_bridge.c
===================================================================
RCS file: /cvsroot/src/sys/net/if_bridge.c,v
retrieving revision 1.76
diff -u -r1.76 if_bridge.c
--- if_bridge.c 22 Mar 2012 12:59:33 -0000      1.76
+++ if_bridge.c 22 May 2012 16:37:53 -0000
 <at>  <at>  -385,6 +385,8  <at>  <at> 

        if_alloc_sadl(ifp);

+       bpf_attach(ifp, DLT_EN10MB, sizeof(struct ether_header));
+
        s = splnet();
        LIST_INSERT_HEAD(&bridge_list, sc, sc_list);
        splx(s);
(Continue reading)

Permalink | Reply |
headers
Darren Reed | 28 May 2012 13:49
Picon

Re: bridge diffs

What is the goal of the bpf_mtap() calls in bridge_input()?

At present, they reflect what packets are sent, rather than
what is actually received. There are many paths through
bridge_input() for a received packet to not be returned via
bpf and that concerns me because a received packet may go
missing when in fact it should be recorded.

Darren
Permalink | Reply |
headers
Robert Swindells | 28 May 2012 21:31
Picon

Re: bridge diffs


Darren Reed wrote:
>What is the goal of the bpf_mtap() calls in bridge_input()?

Help people work out whether their bridge is set up correctly.

>At present, they reflect what packets are sent, rather than
>what is actually received. There are many paths through
>bridge_input() for a received packet to not be returned via
>bpf and that concerns me because a received packet may go
>missing when in fact it should be recorded.

I felt that it was more useful to only log packets that are being
transferred across the bridge.

It is easy enough to apply a tap to a member interface as well to
see any differences.

Robert Swindells
Permalink | Reply |
headers
Darren Reed | 29 May 2012 10:17
Picon

Re: bridge diffs

On 29/05/2012 5:31 AM, Robert Swindells wrote:
> Darren Reed wrote:
>> What is the goal of the bpf_mtap() calls in bridge_input()?
> 
> Help people work out whether their bridge is set up correctly.
> 
>> At present, they reflect what packets are sent, rather than
>> what is actually received. There are many paths through
>> bridge_input() for a received packet to not be returned via
>> bpf and that concerns me because a received packet may go
>> missing when in fact it should be recorded.
> 
> I felt that it was more useful to only log packets that are being
> transferred across the bridge.
> 
> It is easy enough to apply a tap to a member interface as well to
> see any differences.

Ok, so the bpf_mtap calls in bridge are to support sniffing
bridged packets. Sounds good.

Darren
Permalink | Reply |

Gmane