root@monitor:~# bridge vlan
port vlan ids
lan1 200 PVID Egress Untagged
lan0 100 PVID Egress Untagged
br-lan 1 PVID Egress Untagged
all is fine with tcpdump, but not with ulogd while using NFCT plugin !...
Still cannot ulog from my bridge...
root@monitor:~# ebtables -F
root@monitor:~# ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
root@monitor:~# ebtables -A FORWARD --ulog -j DROP
Unable to update the kernel. Two possible causes:
1. Multiple ebtables programs were executing simultaneously. The ebtables
userspace tool doesn't by default support multiple ebtables programs running
concurrently. The ebtables option --concurrent or a tool like flock can be
used to support concurrent scripts that update the ebtables kernel tables.
2. The kernel doesn't support a certain ebtables extension, consider
recompiling your kernel or insmod the extension.
.
https://ebtables.netfilter.org/examples/basic.html#ex_ulog
https://www.systutorials.com/docs/linux/man/8-ebtables/
root@monitor:~# echo "nfnetlink_log" >/proc/sys/net/netfilter/nf_log/7
root@monitor:~# cat /proc/net/netfilter/nf_log
0 NONE (nfnetlink_log)
1 NONE (nfnetlink_log)
2 nf_log_ipv4 (nf_log_ipv4,nfnetlink_log)
3 NONE (nfnetlink_log)
4 NONE (nfnetlink_log)
5 NONE (nfnetlink_log)
6 NONE (nfnetlink_log)
7 nfnetlink_log (nfnetlink_log)
8 NONE (nfnetlink_log)
9 NONE (nfnetlink_log)
10 nf_log_ipv6 (nf_log_ipv6,nfnetlink_log)
11 NONE (nfnetlink_log)
12 NONE (nfnetlink_log)
Still the same problem of silent TCP on my bridge and the lan0/lan1 bridged...
I made a second try with this documentation : https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html and get some more success...
I can set the vlan_filtering only by sysctl:
root@monitor:~# echo "1">/sys/class/net/br0/bridge/vlan_filtering
root@monitor:~# cat /sys/class/net/br0/bridge/vlan_filtering 1
Now I get tcpdump only of IGMP, STP and some IPv6 (neightbour), some UDP (DNS:53)...
But still nothing from the IPv4 stack of what pass through the tunnel...
The traffic is correctly tunneled, but still silent !
I am stuck in this, testing all combinations possible...
Do I need IPT, EBT filter ?
Do I need some sysctl tweaking ?
thanks for the help...
Looks like my conntracking is faulty ?
root@monitor:~# conntrack -E
[DESTROY] udp 17 src=10.2.1.166 dst=51.15.191.239 sport=36478 dport=123 pac
kets=0 bytes=0 src=51.15.191.239 dst=10.2.1.166 sport=123 dport=36478 packets=0
bytes=0
[NEW] tcp 6 120 SYN_SENT src=10.2.1.111 dst=10.2.1.166 sport=34840 dpor
t=667 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34840
[DESTROY] tcp 6 src=10.2.1.111 dst=10.2.1.166 sport=34840 dport=667 packets
=1 bytes=60 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34840 pack
ets=1 bytes=40
[NEW] tcp 6 120 SYN_SENT src=10.2.1.111 dst=10.2.1.166 sport=34842 dpor
t=667 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34842
[DESTROY] tcp 6 src=10.2.1.111 dst=10.2.1.166 sport=34842 dport=667 packets
=1 bytes=60 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34842 pack
ets=1 bytes=40
[NEW] tcp 6 120 SYN_SENT src=10.2.1.111 dst=10.2.1.166 sport=34844 dpor
t=667 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34844
[DESTROY] tcp 6 src=10.2.1.111 dst=10.2.1.166 sport=34844 dport=667 packets
=1 bytes=60 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34844 pack
ets=1 bytes=40
[NEW] tcp 6 120 SYN_SENT src=10.2.1.111 dst=10.2.1.166 sport=34846 dpor
t=667 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34846
[DESTROY] tcp 6 src=10.2.1.111 dst=10.2.1.166 sport=34846 dport=667 packets
=1 bytes=60 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34846 pack
ets=1 bytes=40
[NEW] udp 17 60 src=fe80::f2ad:4eff:fe08:ab43 dst=ff02::1:2 sport=546 d
port=547 [UNREPLIED] src=ff02::1:2 dst=fe80::f2ad:4eff:fe08:ab43 sport=547 dport
=546
[NEW] udp 17 60 src=fe80::f2ad:4eff:fe08:aaca dst=fe80::f2ad:4eff:fe08:
ab43 sport=547 dport=546 [UNREPLIED] src=fe80::f2ad:4eff:fe08:ab43 dst=fe80::f2a
d:4eff:fe08:aaca sport=546 dport=547
[NEW] tcp 6 120 SYN_SENT src=10.2.1.111 dst=10.2.1.166 sport=34848 dpor
t=667 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34848
[DESTROY] tcp 6 src=10.2.1.111 dst=10.2.1.166 sport=34848 dport=667 packets
=1 bytes=60 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34848 pack
ets=1 bytes=40
[NEW] tcp 6 120 SYN_SENT src=10.2.1.111 dst=10.2.1.166 sport=34850 dpor
t=667 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34850
[DESTROY] tcp 6 src=10.2.1.111 dst=10.2.1.166 sport=34850 dport=667 packets
=1 bytes=60 [UNREPLIED] src=10.2.1.166 dst=10.2.1.111 sport=667 dport=34850 pack
ets=1 bytes=40
TCP stay UNREPLIED ???
while adding pseudo VLAN, tcpdump become MASS verbose... but still no connection track of IPv4...
# bridge vlan add vid 200 dev lan1 pvid untagged master
# bridge vlan add vid 100 dev lan0 pvid untagged master
root@monitor:~# bridge vlan
port vlan ids
lan1 200 PVID Egress Untagged
500 Egress Untagged
lan0 100 PVID Egress Untagged
500 Egress Untagged
br-lan 500 PVID
I have put all my network interface in promisc mode and also add ipt call on the bridge with
sysctl net.bridge.bridge-nf-call-iptables=1
sysctl net.bridge.bridge-nf-call-ip6tables=1
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
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.