Apparently ifconfig does not show if eth1 is in promiscuous mode or not.
Neither does ip link.
I started 'tcpdump -e -v -i eth1.3902 pppoed' for a few seconds to trigger promiscuous mode, and then compared the output of the above commands. There was no difference (except the packet counts).
ip monitor link showed up a line for start and stop, but no details hinting at promiscuous mode:
[2020-04-29 14:43:24] 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default
[2020-04-29 14:43:24] link/ether c4:XX:XX:XX:XX:ed brd ff:ff:ff:ff:ff:ff
[2020-04-29 14:43:24] 48: eth1.3902@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
[2020-04-29 14:43:24] link/ether c4:XX:XX:XX:XX:ed brd ff:ff:ff:ff:ff:ff
[2020-04-29 14:43:38] 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default
[2020-04-29 14:43:38] link/ether c4:XX:XX:XX:XX:ed brd ff:ff:ff:ff:ff:ff
[2020-04-29 14:43:38] 48: eth1.3902@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
[2020-04-29 14:43:38] link/ether c4:XX:XX:XX:XX:ed brd ff:ff:ff:ff:ff:ff
only syslog said the promiscuous mode was activated and then deactivated.
Wed Apr 29 14:43:24 2020 kern.info kernel: [853998.131984] device eth1.3902 entered promiscuous mode
Wed Apr 29 14:43:24 2020 kern.info kernel: [853998.137162] device eth1 entered promiscuous mode
Wed Apr 29 14:43:38 2020 kern.info kernel: [854012.994273] device eth1.3902 left promiscuous mode
Wed Apr 29 14:43:38 2020 kern.info kernel: [854012.999393] device eth1 left promiscuous mode
Anyway, the problem happens regardless if I run tcpdump or not.
Also:
There Dianne Skoll says that in their code, the PADT packet is checked to have the correct (our) ethHdr.h_dest
I made a quick look at the kernel pppoe.c and there is no such check (I might have missed it though).
My take under current findings is:
- ISP sends PADT to another party, but on "my" line; it shouldn't, but that's life...
- the net if in my router picks it up; it shouldn't, but that's life...
- the PPPoE code picks it up (it shouldn't, but that's life...) and then terminates the connection
If that is correct, my options are:
- switch ISP (the previous I had did not use PPPoE, just plain E... sweet memories...)
- fix kernel pppoe code to ignore PADT packets sent to others
- fix netif code? netif firmware?
- filter out the bogus packets (maybe with ebtables)
As for fresh data:
output of : tcpdump -e -v -p -i eth1 vlan 3902 and pppoed
[2020-04-29 12:41:56] tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
[2020-04-29 13:49:13] 13:49:13.163623 a4:7b:2c:9e:c7:44 (oui Unknown) > 44:4e:6d:fd:c7:39 (oui Unknown), ethertype 802.1Q (0x8100), length 101: vlan 3902, p 1, ethertype PPPoE D, PPPoE PADO [Service-Name] [AC-Name "SIMB_TABOR_BNG1"] [Host-Uniq 0x444E6DFDC739AAAAAAAAB9000000AAAAAAAA4621426F78202020AAAAAAAA] [AC-Cookie ".5b.u...~.F.mlKv"]
and simultaneously running: tcpdump -evpni eth1.3902 (not ether[0x14:2] = 0x21 and not ether[0x14:2] = 0x57) or pppoed
13:49:13.163623 a4:7b:2c:9e:c7:44 > 44:4e:6d:fd:c7:39, ethertype PPPoE D (0x8863), length 97: PPPoE PADO [Service-Name] [AC-Name "SIMB_TABOR_BNG1"] [Host-Uniq 0x444E6DFDC739AAAAAAAAB9000000AAAAAAAA4621426F78202020AAAAAAAA] [AC-Cookie ".5b.u...~.F.mlKv"]
13:49:13.168608 a4:7b:2c:9e:c7:44 > 44:4e:6d:fd:c7:39, ethertype PPPoE S (0x8864), length 56: PPPoE [ses 0x1] LCP (0xc021), length 21: LCP, Conf-Request (0x01), id 120, length 21
13:49:13.170601 a4:7b:2c:9e:c7:44 > 44:4e:6d:fd:c7:39, ethertype PPPoE D (0x8863), length 58: PPPoE PADS [ses 0x1] [Service-Name] [Host-Uniq 0x444E6DFDC739AAAAAAAAB9000000AAAAAAAA4621426F78202020AAAAAAAA]
14:10:11.180520 a4:7b:2c:9e:c7:44 > 44:4e:6d:fd:c7:39, ethertype PPPoE D (0x8863), length 97: PPPoE PADO [Service-Name] [AC-Name "SIMB_TABOR_BNG1"] [Host-Uniq 0x444E6DFDC739AAAAAAAABB000000AAAAAAAA4621426F78202020AAAAAAAA] [AC-Cookie ".5b.u...~.F.mlKv"]
14:10:11.182514 a4:7b:2c:9e:c7:44 > 44:4e:6d:fd:c7:39, ethertype PPPoE S (0x8864), length 56: PPPoE [ses 0x1] LCP (0xc021), length 21: LCP, Conf-Request (0x01), id 75, length 21
14:10:11.184493 a4:7b:2c:9e:c7:44 > 44:4e:6d:fd:c7:39, ethertype PPPoE D (0x8863), length 58: PPPoE PADS [ses 0x1] [Service-Name] [Host-Uniq 0x444E6DFDC739AAAAAAAABB000000AAAAAAAA4621426F78202020AAAAAAAA]
(note: I filtered out packets sent to or from my MAC)
So I get packets sent to someone else, even if not having eth1 in promiscuous mode.