[PATCH v2] net: dsa: tag_mtk: add padding for tx packets

[Felix Fietkau]

Hi Vladimir,


On 11.05.22 00:21, Vladimir Oltean wrote:
> It sounds as if this is masking a problem on the receiver end, because
> not only does my enetc port receive the packet, it also replies to the
> ARP request.
> 
> pc # sudo tcpreplay -i eth1 arp-broken.pcap
> root at debian:~# ip addr add 192.168.42.1/24 dev eno0
> root at debian:~# tcpdump -i eno0 -e -n --no-promiscuous-mode arp
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on eno0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
> 22:18:58.846753 f4:d4:88:5e:6f:d2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.42.1 tell 192.168.42.173, length 46
> 22:18:58.846806 00:04:9f:05:f4:ab > f4:d4:88:5e:6f:d2, ethertype ARP (0x0806), length 42: Reply 192.168.42.1 is-at 00:04:9f:05:f4:ab, length 28
> ^C
> 2 packets captured
> 2 packets received by filter
> 0 packets dropped by kernel
> 
> What MAC/driver has trouble with these packets? Is there anything wrong
> in ethtool stats? Do they even reach software? You can also use
> "dropwatch -l kas" for some hints if they do.
For some reason I can't reproduce the issue of ARPs not getting replies 
anymore.
The garbage data is still present in the ARP packets without my patch 
though. So regardless of whether ARP packets are processed correctly or 
if they just trip up on some receivers under specific conditions, I 
believe my patch is valid and should be applied.

Who knows, maybe the garbage padding even leaks some data from previous 
packets, or some other information from within the switch.

- Felix