Passive TAP / HUB and Ethernet Bridge

conntrack is too high in the protocol stack.... and only present for local and routed packets that pass "through" the router... the unreplied entries seem to be un-connected voip? ( i.e. the client probably falls back to a udp connection when tcp fails? )

( sorry i'm a visual person... i take it this device is inline between your WAN port and an NTD ( isp-modem or similar )

is it a gigabit link?

So I cannot hope off listening with conntrack the bridged traffic ?

It's between my switch and my OpenWRT Internet Routeur...

Yes

try monitoring one end of a veth pair... with the other end in the bridge

Can you tell more please ?
I am not sure to understand your proposal...

something like this...

opkg install kmod-veth tc kmod-dummy

sourceIF=br-lan
destIF=dummy0

tc qdisc add dev "$sourceIF" ingress
tc filter add dev "$sourceIF" parent ffff: \
          protocol all \
          u32 match u8 0 0 \
          action mirred egress mirror dev "$destIF"

tc qdisc add dev "$sourceIF" handle 1: root prio
tc filter add dev "$sourceIF" parent 1: \
          protocol all \
          u32 match u8 0 0 \
          action mirred egress mirror dev "$destIF"

ifconfig $destIF up
tcpdump -elni $destIF

or this... for veth

destIF=vethD
tapIF=vethS
ip link add $tapIF type veth peer name $destIF
brctl addif br-lan $tapIF
ifconfig $tapIF up
ifconfig $destIF up

thanks...

I made a full reboot and test your first method script, but get some errors...

root@monitor:/# tc qdisc add dev "$sourceIF" handle 1: root prio
RTNETLINK answers: No such file or directory
root@monitor:/# tc filter add dev "$sourceIF" parent 1: \
8 >           protocol all \
i>           u32 match u8 0 0 \
r>           action mirred egress mirror dev "$destIF"
RTNETLINK answers: Invalid argument
We have an error talking to the kernel, -1

here tcpdump get only igmp and udp...

Will try the second method with veth !

yeah... they are rough and dirty examples ( not tested )... but should be enough to hopefully help you out...

as mentioned the switching fabric likely shortcuts your kernel... but they are useful tools to have up your sleeve anyways... :wink:

Am i okay to add one more command ?
ip link add $destIF type veth peer name $tapIF

sure it is a new path to explore... :wink: thank you...

For now my tcpdump stay silent with veth... completly silent on the vethD...
Just as all others network bridged on the vethS which is part of the bridge...
I have add all networks interfaces promisc and also have add the VLAN untagged on the vethS

but inside is still getting (showing) only UDP, IGMP traffic...

I may have forget to say that the bridge traffic is ok... all the devices are communicating transparently through my bridge, but I need to get them traffic being verbose from the bridge ...

This line adds the interfaces... it's like saying "create veth1+veth2" so you only do it once... i'm no expert... maybe someone more knowledgeable can help with a clearer example...

But the dummy version works for me on x86... ( no hardware switch )... so from here it does seem like your switching hardware doesn't touch the kernel...

If you can live with 100Mb/s for testing purposes... you can always do this

only PROTO=2 and PROTO=UDP are logged from NFLOG with the RULE :
root@monitor:/# iptables -t raw -I PREROUTING -i br-lan -j LOG

same results with daemonlogger package


opkg install daemonlogger

sif=br-lan
dif=dummy2


ip link add $dif type dummy
ip link set dev $dif up

daemonlogger -i $sif -o $dif -d

tcpdump -leni $dif

still only ARP, IGMP !
still no IPv4 TCP...

with my test I get this working without IPv4 :

sysctl net.bridge.bridge-nf-call-iptables=1
sysctl net.bridge.bridge-nf-call-ip6tables=1

root@monitor:~# bridge vlan
port	vlan ids
lan1	 1 PVID Egress Untagged

lan0	 1 PVID Egress Untagged

br-lan	 1 PVID Egress Untagged

root@monitor:~# echo "1"> /sys/class/net/br-lan/bridge/nf_call_iptables
root@monitor:~# cat /sys/class/net/br-lan/bridge/nf_call_iptables 
1

and then with a VLAN added to one of the bridge device, I get more verbose tcpdump;

root@monitor:~# bridge vlan add vid 100 dev lan0 pvid untagged
root@monitor:~# bridge vlan
port	vlan ids
lan1	 1 PVID Egress Untagged

lan0	 1 Egress Untagged
	 100 PVID Egress Untagged

br-lan	 1 PVID Egress Untagged

root@monitor:~# 

May be conntrack is useless on a bridge and I have to get NFLOG instead of NFCT ?

root@monitor:~# tcpdump -qn -p tcp dst port 443 -i br-lan
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes

Get a lot of trace from my bridge... so no more silent !
Will look to post a complete resolution...

thanks

1 Like

Looks like it is possible, because it is working now !

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.