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... 
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... 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
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.