netdev - RE: Response error to fragmented ICMP echo request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 7 Mar 2023 12:56:17 +0000
From:   "Song, Xiongwei" <Xiongwei.Song@...driver.com>
To:     Vladimir Oltean <vladimir.oltean@....com>
CC:     "claudiu.manoil@....com" <claudiu.manoil@....com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Response error to fragmented ICMP echo request

Hello Vladimir,

Thanks for the quick response.

> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@....com>
> Sent: Tuesday, March 7, 2023 8:35 PM
> To: Song, Xiongwei <Xiongwei.Song@...driver.com>
> Cc: claudiu.manoil@....com; alexandre.belloni@...tlin.com;
> UNGLinuxDriver@...rochip.com; davem@...emloft.net; edumazet@...gle.com;
> kuba@...nel.org; pabeni@...hat.com; richardcochran@...il.com; linux-
> kernel@...r.kernel.org; netdev@...r.kernel.org
> Subject: Re: Response error to fragmented ICMP echo request
> 
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the
> content is safe.
> 
> Hello Xiongwei,
> 
> On Tue, Mar 07, 2023 at 12:11:52PM +0000, Song, Xiongwei wrote:
> > ......snip......
> > failing SW:
> > rx_octets                       +64
> > rx_unicast                      +1
> > rx_frames_below_65_octets       +1
> > rx_yellow_prio_0                +1
> > *drop_yellow_prio_0              +1
> > ......snip......
> >
> > 3). From pcap file(the pcap was collected on the senderside (VM))
> >
> > Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
> > Ethernet II, Src: 7c:72:6e:d4:44:5f (7c:72:6e:d4:44:5f), Dst: aa:3a:b3:e7:67:5c
> (aa:3a:b3:e7:67:5c)
> >     Destination: aa:3a:b3:e7:67:5c (aa:3a:b3:e7:67:5c)
> >     Source: 7c:72:6e:d4:44:5f (7c:72:6e:d4:44:5f)
> >     Type: 802.1Q Virtual LAN (0x8100)
> > 802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 981
> >     110. .... .... .... = Priority: Internetwork Control (6)
> >     ...0 .... .... .... = DEI: Ineligible
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >     .... 0011 1101 0101 = ID: 981
> >     Type: ARP (0x0806)
> >     Padding: 0000000000000000000000000000
> >     Trailer: 00000000
> >
> > Frame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits)
> > Ethernet II, Src: aa:3a:b3:e7:67:5c (aa:3a:b3:e7:67:5c), Dst: 7c:72:6e:d4:44:5f
> (7c:72:6e:d4:44:5f)
> > 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 981
> >     000. .... .... .... = Priority: Best Effort (default) (0)
> >     ...0 .... .... .... = DEI: Ineligible
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >     .... 0011 1101 0101 = ID: 981
> >     Type: ARP (0x0806)
> >
> > Frame 3: 47 bytes on wire (376 bits), 47 bytes captured (376 bits)
> > Ethernet II, Src: aa:3a:b3:e7:67:5c (aa:3a:b3:e7:67:5c), Dst: 7c:72:6e:d4:44:5f
> (7c:72:6e:d4:44:5f)
> > 802.1Q Virtual LAN, PRI: 0, DEI: 1, ID: 981
> >     000. .... .... .... = Priority: Best Effort (default) (0)
> >     ...1 .... .... .... = DEI: Eligible
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >     .... 0011 1101 0101 = ID: 981
> >     Type: IPv4 (0x0800)
> >
> > Frame 4: 46 bytes on wire (368 bits), 46 bytes captured (368 bits)
> > Ethernet II, Src: aa:3a:b3:e7:67:5c (aa:3a:b3:e7:67:5c), Dst: 7c:72:6e:d4:44:5f
> (7c:72:6e:d4:44:5f)
> > 802.1Q Virtual LAN, PRI: 0, DEI: 1, ID: 981
> >     000. .... .... .... = Priority: Best Effort (default) (0)
> >     ...1 .... .... .... = DEI: Eligible
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >     .... 0011 1101 0101 = ID: 981
> >     Type: IPv4 (0x0800)
> >
> > 4). What we've found so far
> >
> > According binary search, we found out the following commit causes this issue:
> > a4ae997adcbd("net: mscc: ocelot: initialize watermarks to sane defaults").
> > Without this commit the test case was passed.
> >
> > Could you please take a look? Please let me know if you need more debug info.
> 
> I've marked the DEI values in the message you posted above.
> 
> Commit a4ae997adcbd ("net: mscc: ocelot: initialize watermarks to sane defaults")
> tells the hardware to not allow frames with DEI=1 consume from the shared switch
> resources (buffers / frame references) by default. Drop Eligible Indicator = 1
> means "eligible for dropping". The only chance for DEI=1 frames to not be dropped
> is to set up a resource reservation for that stream, via the devlink-sb command.

Oh.., thanks for the detailed explanation.

> 
> Frames 3 and 4 are sent with DEI=1 and are dropped, frames 1 and 2 are
> sent with DEI=0 and are not dropped. I'm not sure if varying the DEI
> field is part of the intentions of the test? Is there any RFC which says
> that IP fragments over VLAN should use DEI=1, or some other reason?

I didn't notice that. Let me check the test why set DEI=1. 

Have a good day.

Regards,
Xiongwei