Messages in this thread | | | Date | Wed, 11 May 2022 01:21:01 +0300 | From | Vladimir Oltean <> | Subject | Re: [PATCH v2] net: dsa: tag_mtk: add padding for tx packets |
| |
On Wed, May 11, 2022 at 12:06:25AM +0200, Felix Fietkau wrote: > > On 10.05.22 18:52, Vladimir Oltean wrote: > > On Tue, May 10, 2022 at 04:52:16PM +0200, Felix Fietkau wrote: > > > > > > On 10.05.22 14:37, Vladimir Oltean wrote: > > > > On Tue, May 10, 2022 at 11:40:13AM +0200, Felix Fietkau wrote: > > > > > Padding for transmitted packets needs to account for the special tag. > > > > > With not enough padding, garbage bytes are inserted by the switch at the > > > > > end of small packets. > > > > > I don't think padding bytes are guaranteed to be zeroes. Aren't > > > they > > > > discarded? What is the issue? > > > With the broken padding, ARP requests are silently discarded on the receiver > > > side in my test. Adding the padding explicitly fixes the issue. > > > > > > - Felix > > > > Ok, I'm not going to complain too much about the patch, but I'm still > > curious where are the so-called "broken" packets discarded. > > I think the receiving MAC should be passing up to software a buffer > > without the extra padding beyond the L2 payload length (at least that's > > the behavior I'm familiar with). > > I don't know where exactly these packets are discarded. > After digging through the devices I used during the tests, I just found some > leftover pcap files that show the differences in the received packets. Since > the packets are bigger after my patch, I can't rule out that packet size > instead of the padding may have made a difference here in getting the ARP > requests accepted by the receiver. > > I've extracted the ARP requests and you can find them here: > http://nbd.name/arp-broken.pcap
arp-broken.pcap was collected at the receiver MAC, right? So the packets actually exited the switch?
> http://nbd.name/arp-working.pcap > > - Felix
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.
| |