I take the WAN into dhcp client and put it on my LAN switch (it is the admin connection used with ssh to manage and talk to the OpenWRT)
I take the two LAN into the unmanaged mode lan0 + lan1 bridged into br-lan... this LAN is into unmanaged protocol...
the LAN0 is linked to the WAN of the Internet Modem / router ISP box...
the LAN1 is linked to the WAN of the Roteur LAN/BOX...
They are linked transparently, and the br-lan act as a HUB/SWITCH... so the Internet works as usual...
I use a ssh tcpdump into wireshark , but it is all silent...
I only see tcpv6 icmpv6 multicast !?
I am getting nothing from the br-lan tcpdump !
where am I wrong ?
Do I need to use another dump than tcpdump (brcause I am not tcp dumping but ethernet bridge dumping ?)
Do I need to use another switches to tcpdump than the default as already documented ?
Here is the "default" link of my Internet access : INET - ADSL -[ WAN - ISPBOX - HOME ]- >< -[ WAN - EBINBOX - DMZ / LAN ]- >< -[ SWITCH ]
Here is the "monitor" addon
[ MONITOR ] : WAN ( DHCP ) ]- >< -[ SWITCH ( LAN ) ]
LAN0 ( BR-LAN ) ]- >< -[ HOME - ISPBOX ]
LAN1 ( BR-LAN ) ]- >< -[ WAN - EBINBOX ]
I'm not sure exactly what you're trying to do, but start by setting each port with a different VLAN so they are not hardware switching, then include the resulting VLANs into a software bridge. Tcpdump can (and should) be attached to a single port such as eth0.2 instead of br-lan. If you attach to br-lan you will only see traffic to or from the router's IP i.e. that which enters or leaves the bridge <--> kernel boundary, not everything that goes on within the bridge.
The kernel will not receive to port packets that were handled within the hardware switch. The other approach to this is to set up mirror mode within the switch, so all traffic on one port is copied to a specially configured port.
I have no VLAN with EspressoBin Board...
So I may understand from your answer that a bridge of two ethernets is doing hardware switching, so it will stay silent from tcpdump...?
Is there any other bridging possibilities, without VLAN tagging, to accomplish wath I want ?
How can I do software switching of two ethernet like a bridge but still tcpdumpable ?
To say it another way, I want to be transparent (for a plug and play solution) looking and analysing all the network traffic between two subnets; here it is between my ISP routeur and my personnal OpenWRT routeur.
I don't know anything specific to the expressobin but the manufacturer's page says it has a gigabit switch with three Ethernet cable ports, and presumably one or two CPU ports also attached to the switch. Is that how it is built?
What I would do is set up three VLANs inside the switch, each untagged to one port and all tagged to the CPU port. Then you have exposed the untagged traffic (I assume you don't have to worry about VLANs on the cables) on the respective cables to eth0.1 eth0.2 and eth0.3. Attach one of those to the standard LAN so you can log in. Then make an unmanaged bridge holding the two others. In hardware, break in to the circuit you want to monitor by passing through those two ports.
I want to use two of the ethernets cable ports for the "bridge" analysis.
The third is used to get the access for monitor / admin by ssh / luci to OpenWRT.
If the switch only operates unmanaged, you can't do this application. It is just going to hardware switch the packets between the active cable ports and the CPU has no chance to see them.
I have added ip-bridge and then I can look at the bridge...
It is a DSA switch (so VLAN supported)
I am still in OpenWRT 18.06.2
root@OpenWrt:~# bridge link
3: lan1 state UP @eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-br state forwarding priority 32 cost 19
4: lan0 state LOWERLAYERDOWN @eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master br-br state disabled priority 32 cost 100
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.
.
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 ?