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 14:35:22 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     "Song, Xiongwei" <Xiongwei.Song@...driver.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 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.

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?