Maybe VLAN, did not: eth1 entered promiscuous mode

I first setup Omina behind the ISP router and it was working.

Then plugged the cable directly in Omnia and fixed the VLAN (with help). eth1.101 got the IP number via DHCP and the route was setup but no traffic got through - not even ping .

As the IP was set there must have been some traffic and I looked at with
tcpdump -i eth1
and while using tcpdump the traffic suddenly got through.

root@turris:~# grep promisc /var/log/messages
2018-10-27 08:18:36 info kernel[]: [   22.604422] device eth0 entered promiscuous mode
2018-10-27 08:18:36 info kernel[]: [   22.624336] device eth2 entered promiscuous mode
2018-10-27 08:18:36 info kernel[]: [   23.115224] device wlan1 entered promiscuous mode
2018-10-27 08:18:36 info kernel[]: [   25.445318] device wlan0 entered promiscuous mode
2018-10-27 08:19:03 info kernel[]: [   60.241006] device eth1 entered promiscuous mode

The last line was when I started tcpdump.

The work around was to add a fix to /etc/rc.local:

ifconfig eth1 promisc

to put it into promiscous mode during boot.
(Bad hack: rc.local is somehow deprecated)

The question is: What went wrong? What could caused eth1 not to enter promiscous mode which I expect it has to?

tcpdump will put the interface in promisc-mode by default (use -p to disable that).

putting the interface in promisc in rc.local should not be required.

check your firewall settings

  • is eth1.101 the wan interface
  • OUTPUT policy should be ACCEPT
  • can lan interface forward to wan

I looked in the LuCI interface and it seems all OK.

The /etc/config/network has:

config interface 'wan'
    option ifname 'eth1.101'
    option proto 'dhcp'

The /etc/config/firewall has:

config zone
    option name 'wan'
    list network 'wan'
    list network 'wan6'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'

config forwarding
    option src 'lan'
    option dest 'wan'

what does tcpdump -i eth1 -nn -e show?
maybe your isp is sending to a specific mac-address incase you would need to change your eth1 mac accordingly.

I has changed the MAC to be the same as the equipment from the ISP. This makes it faster to switch to/from the ISP router. Otherwise I should wait up to two hours for a new DBCP lease.

The output below looks right…?

# tcpdump -i eth1 -nn -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:35:31.439715 8c:59:73:74:17:9a > 2c:21:31:a6:63:8a, ethertype 802.1Q (0x8100), length 116: vlan 101, p 0, ethertype IPv4, > Flags [P.], seq 1433628769:1433628815, ack 2089183453, win 33, options [nop,nop,TS val 1582931449 ecr 244435496], length 46
11:35:31.446125 2c:21:31:a6:63:8a > 8c:59:73:74:17:9a, ethertype 802.1Q (0x8100), length 116: vlan 101, p 0, ethertype IPv4, > Flags [P.], seq 1:47, ack 46, win 251, options [nop,nop,TS val 244494052 ecr 1582931449], length 46

I thought it was strange that eth0 and eth2 entered promiscuous mode but eth1 did not.

There are too many parameters which could have gone wrong. I’ll make a factory default later and run a diff and see if can spot the parameter which cause the problem.