ns3 + tap-bridge, adhoc MAC filtering issue

GANLIN TANG

unread,

Dec 9, 2025, 1:51:02 AMDec 9

to ns-3-users

Hello:

I'm trying to using docker + tap-bridge to build an adhoc network. I using ns3.37.

The bridge build for each docker is below:

sudo ip tuntap add mode tap name tap-1

sudo ip link set tap-1 up

sudo ip link add name br-1 type bridge

sudo ip link set br-1 up

sudo ip link set tap-1 master br-1

sudo docker run -it --name vm-1 --network none --privileged 3c9b03467122 /bin/bash

PID_LEFT=$(sudo docker inspect -f '{{.State.Pid}}' vm-1)

sudo ip link add veth-3 type veth peer name veth-1-br

sudo ip link set veth-1 netns $PID_LEFT

sudo ip link set veth-1-br master br-1

sudo ip link set veth-1-br up

sudo nsenter -t $PID_LEFT -n ip link set dev lo up

sudo nsenter -t $PID_LEFT -n ip link set dev veth-1 up

sudo nsenter -t $PID_LEFT -n ip addr add 10.0.0.1/24 dev veth-1

but there are several questions:

(1) the packet src_mac will change to tap-3's src_mac for every packet no matter receive or send packet from docker

(2) when I try to build a network test the adhoc MAC filtering like:

Screenshot from 2025-12-09 15-39-44.png

I translate the packet from point 0 to point 2 using OLSR protocol.

the point 0 ip route is :

10.0.0.0/24 dev veth-1 proto kernel scope link src 10.0.0.1
10.0.0.2 via 10.0.0.2 dev veth-1 metric 2 onlink
10.0.0.3 via 10.0.0.2 dev veth-1 metric 2 onlink
10.0.0.4 via 10.0.0.4 dev veth-1 metric 2 onlink

so it won't pass the point 3 which ip is 10.0.0.4, so the packet next mac address should be point 1's mac address.

But when I using tcpdump -i veth-4 -n -e udp and not port 698 in point 3 it still show:

06:34:14.157071 1e:cf:58:14:15:e0 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 1512: 10.0.0.1.56183 > 10.0.0.3.5001: UDP, length 1470
06:34:14.181849 1e:cf:58:14:15:e0 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 1512: 10.0.0.1.56183 > 10.0.0.3.5001: UDP, length 1470
06:34:14.192373 0e:92:5c:f0:c8:8b > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 1512: 10.0.0.1.56183 > 10.0.0.3.5001: UDP, length 1470

The point 3 still catch the packet from point 0, which the dst_mac is not itselfs.

So the adhoc mac filtering ability have issue.

The below is the information of each node's and bridge data:

veth-1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.1 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::200:ff:fe00:1 prefixlen 64 scopeid 0x20<link>
ether 00:00:00:00:00:01 txqueuelen 1000 (Ethernet)
RX packets 4297 bytes 1154931 (1.1 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3145 bytes 1779460 (1.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth-2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.2 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::200:ff:fe00:2 prefixlen 64 scopeid 0x20<link>
ether 00:00:00:00:00:02 txqueuelen 1000 (Ethernet)
RX packets 6315 bytes 1517009 (1.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2818 bytes 1261826 (1.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth-3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.3 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::200:ff:fe00:3 prefixlen 64 scopeid 0x20<link>
ether 00:00:00:00:00:03 txqueuelen 1000 (Ethernet)
RX packets 3081 bytes 1027417 (1.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2217 bytes 218426 (218.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth-4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.4 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::200:ff:fe00:4 prefixlen 64 scopeid 0x20<link>
ether 00:00:00:00:00:04 txqueuelen 1000 (Ethernet)
RX packets 5076 bytes 2134016 (2.1 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2173 bytes 216758 (216.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

br-1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::90bf:79ff:fe18:abd9 prefixlen 64 scopeid 0x20<link>
ether 92:bf:79:18:ab:d9 txqueuelen 1000 (Ethernet)
RX packets 6137 bytes 640395 (640.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 33 bytes 4720 (4.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

br-2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::ac2d:f1ff:fe96:e56f prefixlen 64 scopeid 0x20<link>
ether ae:2d:f1:96:e5:6f txqueuelen 1000 (Ethernet)
RX packets 7972 bytes 793661 (793.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 35 bytes 4904 (4.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

br-3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::1407:19ff:fea7:13df prefixlen 64 scopeid 0x20<link>
ether 16:07:19:a7:13:df txqueuelen 1000 (Ethernet)
RX packets 4782 bytes 507142 (507.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 29 bytes 3819 (3.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

br-4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::803e:27ff:fe58:25c1 prefixlen 64 scopeid 0x20<link>
ether 82:3e:27:58:25:c1 txqueuelen 1000 (Ethernet)
RX packets 6134 bytes 639520 (639.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 34 bytes 4834 (4.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap-1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::1ccf:58ff:fe14:15e0 prefixlen 64 scopeid 0x20<link>
ether 1e:cf:58:14:15:e0 txqueuelen 1000 (Ethernet)
RX packets 4433 bytes 1171319 (1.1 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3235 bytes 1792207 (1.7 MB)
TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0

tap-2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::c92:5cff:fef0:c88b prefixlen 64 scopeid 0x20<link>
ether 0e:92:5c:f0:c8:8b txqueuelen 1000 (Ethernet)
RX packets 6465 bytes 1528541 (1.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2883 bytes 1275755 (1.2 MB)
TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0

tap-3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::3814:b8ff:fe57:c2a4 prefixlen 64 scopeid 0x20<link>
ether 3a:14:b8:57:c2:a4 txqueuelen 1000 (Ethernet)
RX packets 3074 bytes 1027344 (1.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2257 bytes 224440 (224.4 KB)
TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0

tap-4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::70b6:92ff:fe08:7418 prefixlen 64 scopeid 0x20<link>
ether 72:b6:92:08:74:18 txqueuelen 1000 (Ethernet)
RX packets 5071 bytes 2132454 (2.1 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2193 bytes 222337 (222.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth-1-br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::8c2f:afff:fe6e:7dd8 prefixlen 64 scopeid 0x20<link>
ether 8e:2f:af:6e:7d:d8 txqueuelen 1000 (Ethernet)
RX packets 3247 bytes 1789896 (1.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4498 bytes 1180581 (1.1 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth-2-br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::e46c:86ff:fe5a:6bb7 prefixlen 64 scopeid 0x20<link>
ether e6:6c:86:5a:6b:b7 txqueuelen 1000 (Ethernet)
RX packets 2893 bytes 1273368 (1.2 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6532 bytes 1537987 (1.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth-3-br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::8037:ebff:fe0c:6f92 prefixlen 64 scopeid 0x20<link>
ether 82:37:eb:0c:6f:92 txqueuelen 1000 (Ethernet)
RX packets 2271 bytes 223070 (223.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3134 bytes 1035635 (1.0 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth-4-br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::64ad:36ff:fe86:eddf prefixlen 64 scopeid 0x20<link>
ether 66:ad:36:86:ed:df txqueuelen 1000 (Ethernet)
RX packets 2203 bytes 219850 (219.8 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5137 bytes 2141830 (2.1 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

adhoc_wifi.cc

Tommaso Pecorella

unread,

Dec 10, 2025, 6:48:49 PMDec 10

to ns-3-users

Typically tcdump will disable all the MAC level filtering (because that's what it does).

This doesn't means that the upper layers will accept the packet, just that tcpdump is recoding the packets, no matter what.

GANLIN TANG

unread,

Dec 10, 2025, 7:17:19 PMDec 10

to ns-3-users

Hello Tommaso:

First of all, thanks for the reply!

According to the conditon of my setting:

brctl show :

br-1 8000.92bf7918abd9 no tap-1 veth-1-br

br-2 8000.ae2df196e56f no tap-2 veth-2-br

br-3 8000.160719a713df no tap-3 veth-3-br

br-4 8000.823e275825c1 no tap-4 veth-4-br

It mean the every docker connect to the different bridge,

every linux bridge only accept the packet from the ns3 wifi node, the docker also only accept the packet from ns3 wifi node.

The docker accept packet process should like:

ns-3 wifi node
↓
TapBridge
↓
tap-x
↓
linux bridge
↓
docker

And the result about the tcpdump is coming from the docker inside port, it's mean I get the packet inside docker.

So if the ns3 node in ns3 environment already flitered the different mac packets, the port in docker should not accept these kind packets.

And if I add:

sudo ebtables -A FORWARD -i tap-3 -d ff:ff:ff:ff:ff:ff -j ACCEPT

sudo ebtables -A FORWARD -i tap-3 -d b6:6d:f4:26:18:a7 -j ACCEPT

sudo ebtables -A FORWARD -i tap-3 -j DROP

using these command to limit the tap-x port of linux bridge, then the packet will be like only accept the dst_mac which same with docker.

Thanks!

GANLIN TANG

unread,

Dec 21, 2025, 8:49:06 PM (8 days ago) Dec 21

to ns-3-users

Hello:

I'm still using the tap-bridge plus docker to make the topology, but there is a problem happened.

In this topology even just 2 node, the wlan's retrans number is very high, even almost every segment have the ack but it still retranst it every time.

I have upload the topology code and the .pcap file which get from the simulation.
Thanks!