lkml.org 
[lkml]   [2022]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] net: dsa: tag_mtk: add padding for tx packets

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@debian:~# ip addr add 192.168.42.1/24 dev eno0
> root@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

\
 
 \ /
  Last update: 2022-05-11 10:52    [W:0.074 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site