Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Oct 2022 20:31:48 +0200 (CEST)
From:      Ronald Klop <ronald-lists@klop.ws>
To:        mike@karels.net
Cc:        freebsd-arm@freebsd.org
Subject:   Re: wake-on-lan lost from rpi4 (works on rpi3)
Message-ID:  <1539824734.231347.1666722708425@localhost>
In-Reply-To: <202210251611.29PGBsbq016681@mail.karels.net>
References:  Your message of Tue, 25 Oct 2022 10:22:38 -0500. <676FFB6B-0D38-47D4-AED8-EA2D5F685F43@karels.net> <202210251611.29PGBsbq016681@mail.karels.net>

next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_231346_1677104857.1666722708420
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Mike Karels <mike@karels.net>
Datum: dinsdag, 25 oktober 2022 18:11
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: freebsd-arm@freebsd.org
Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
> 
> I wrote:
> > On 25 Oct 2022, at 9:13, Ronald Klop wrote:
> 
> > > Van: Mike Karels <mike@karels.net>
> > > Datum: dinsdag, 25 oktober 2022 14:55
> > > Aan: Ronald Klop <ronald-lists@klop.ws>
> > > CC: freebsd-arm@freebsd.org
> > > Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
> > >>
> > >> On 25 Oct 2022, at 6:57, Ronald Klop wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.
> > >>> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505
> > >>>
> > >>> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.
> > >>> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505
> > >>>
> > >>> Firewall ipfw does not indicate that it blocks anything.
> > >>>
> > >>> RPI4 runs:
> > >>> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64
> > >>>
> > >>> genet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > >>>    options=68000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
> > >>>
> > >>>
> > >>> RPI3 runs:
> > >>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64
> > >>>
> > >>> ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > >>>    options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
> > >>>
> > >>>
> > >>> Does genet0 not support these packages?
> > >>> What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?
> > >>> genet0 does have a vlan configured connected to a bridge0 for some jails
> > >>> vlan3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > >>>    options=80000<LINKSTATE>
> > >>>    groups: vlan
> > >>>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0
> > >>>
> > >>> ue0 is itself connected to a bridge0
> > >>
> > >> Is the RPI3 also on a vlan and bridge?
> > >>
> > >> Is the router (or switch) expecting the packet on the vlan?
> > >> If so, maybe you need to send on vlan3 rather than genet0.
> > >>
> > >> The genet interface has some oddities about packet layouts;
> > >> that could be hitting here.  You could try disabling TCP TX
> > >> checksum offload: ifconfig genet0 -txcsum -txcsum6; that
> > >> simplifies some of the issues.
> > >>
> > >>         Mike
> > >>
> > >>> Regards,
> > >>> Ronald.
> > >
> > >
> > > Hi,
> > >
> > > Thanks for the hint. I experimented some further.
> > >
> > > Disabling -txcsum -rxcsum didn't matter.
> 
> > -rxcsum doesn't matter, but you need to do -txcsum6 as well as
> > -txcsum.  (See the code that calls gen_parse_tx.)
> 
> > > But when I use bridge0 or vlan3 as device then it goes into the wire but on the VLAN which is not where my NAS is which I want to boot.
> > >
> > > Looking at the driver I found this interesting peace of code.
> > >
> > > static int
> > > gen_parse_tx(struct mbuf *m, int csum_flags) {
> > > ...
> > >        if (ether_type == ETHERTYPE_IP) {
> > >                COPY(((struct ip *)p)->ip_hl << 2);
> > >                offset += ((struct ip *)p)->ip_hl << 2;
> > >        } else if (ether_type == ETHERTYPE_IPV6) {
> > >                COPY(sizeof(struct ip6_hdr));
> > >                offset += sizeof(struct ip6_hdr);
> > >        } else {
> > >                /*
> > >                 * Unknown whether other cases require moving a header;
> > >                 * ARP works without.
> > >                 */
> > >        }
> > > ...
> > > }
> > >
> > > There is also some code which handles EHTERTYPE_VLAN.
> > >
> > > I don't have time to start debugging this today. But would this ring a bell to anybody in connection to a wake-on-lan packet?
> 
> > I ran some experiments with tx checksum disabled, and it seems to
> > matter.  I have a change for the last block you listed that might
> > help, but I haven't tested it yet.
> 
> This patch seems to work:
> 
> diff --git a/sys/arm64/broadcom/genet/if_genet.c b/sys/arm64/broadcom/genet/if_genet.c
> index 327af8acbcdd..b7ab86e7931d 100644
> --- a/sys/arm64/broadcom/genet/if_genet.c
> +++ b/sys/arm64/broadcom/genet/if_genet.c
> @@ -1305,6 +1305,8 @@ gen_parse_tx(struct mbuf *m, int csum_flags)
>          * Unknown whether other cases require moving a header;
>          * ARP works without.
>          */
> +       COPY(min(gen_tx_hdr_min, m->m_len));
> +       offset += min(gen_tx_hdr_min, m->m_len);
>     }
>     return (offset);
>  #undef COPY
> 
> It needs an updated comment, but should be testable.
> 
>         Mike
> 
> > > Regards,
> > > Ronald.
> 
>  

Hi,

Thanks. Disabling both -txcsum and -txcsum6 works for me also.
I can test your patch tommorow or on Thursday. I'm first testing a big mongodb 6.0 patch I hope to commit soon and this build occupies my rpi4 for some more hours.

Regards,
Ronald.
 
------=_Part_231346_1677104857.1666722708420
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html><head></head><body>&nbsp;
<p><strong>Van:</strong> Mike Karels &lt;mike@karels.net&gt;<br>
<strong>Datum:</strong> dinsdag, 25 oktober 2022 18:11<br>
<strong>Aan:</strong> Ronald Klop &lt;ronald-lists@klop.ws&gt;<br>
<strong>CC:</strong> freebsd-arm@freebsd.org<br>
<strong>Onderwerp:</strong> Re: wake-on-lan lost from rpi4 (works on rpi3)</p>

<blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left: #000000 2px solid; margin-right: 0px">
<div class="MessageRFC822Viewer" id="P">
<div class="TextPlainViewer" id="P.P">I wrote:<br>
&gt; On 25 Oct 2022, at 9:13, Ronald Klop wrote:<br>
<br>
&gt; &gt; Van: Mike Karels &lt;mike@karels.net&gt;<br>
&gt; &gt; Datum: dinsdag, 25 oktober 2022 14:55<br>
&gt; &gt; Aan: Ronald Klop &lt;ronald-lists@klop.ws&gt;<br>
&gt; &gt; CC: freebsd-arm@freebsd.org<br>
&gt; &gt; Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On 25 Oct 2022, at 6:57, Ronald Klop wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; Hi,<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.<br>
&gt; &gt;&gt;&gt; 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda &gt; 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.<br>
&gt; &gt;&gt;&gt; 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda &gt; 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Firewall ipfw does not indicate that it blocks anything.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; RPI4 runs:<br>
&gt; &gt;&gt;&gt; FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022 &nbsp;&nbsp;&nbsp;&nbsp;ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; genet0: flags=8943&lt;UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br>
&gt; &gt;&gt;&gt; &nbsp;&nbsp;&nbsp;options=68000b&lt;RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; RPI3 runs:<br>
&gt; &gt;&gt;&gt; FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; ue0: flags=8943&lt;UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br>
&gt; &gt;&gt;&gt; &nbsp;&nbsp;&nbsp;options=80009&lt;RXCSUM,VLAN_MTU,LINKSTATE&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Does genet0 not support these packages?<br>
&gt; &gt;&gt;&gt; What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?<br>
&gt; &gt;&gt;&gt; genet0 does have a vlan configured connected to a bridge0 for some jails<br>
&gt; &gt;&gt;&gt; vlan3: flags=8943&lt;UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br>
&gt; &gt;&gt;&gt; &nbsp;&nbsp;&nbsp;options=80000&lt;LINKSTATE&gt;<br>
&gt; &gt;&gt;&gt; &nbsp;&nbsp;&nbsp;groups: vlan<br>
&gt; &gt;&gt;&gt; &nbsp;&nbsp;&nbsp;vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; ue0 is itself connected to a bridge0<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Is the RPI3 also on a vlan and bridge?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Is the router (or switch) expecting the packet on the vlan?<br>
&gt; &gt;&gt; If so, maybe you need to send on vlan3 rather than genet0.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; The genet interface has some oddities about packet layouts;<br>
&gt; &gt;&gt; that could be hitting here. &nbsp;You could try disabling TCP TX<br>
&gt; &gt;&gt; checksum offload: ifconfig genet0 -txcsum -txcsum6; that<br>
&gt; &gt;&gt; simplifies some of the issues.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mike<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; Regards,<br>
&gt; &gt;&gt;&gt; Ronald.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; Thanks for the hint. I experimented some further.<br>
&gt; &gt;<br>
&gt; &gt; Disabling -txcsum -rxcsum didn't matter.<br>
<br>
&gt; -rxcsum doesn't matter, but you need to do -txcsum6 as well as<br>
&gt; -txcsum. &nbsp;(See the code that calls gen_parse_tx.)<br>
<br>
&gt; &gt; But when I use bridge0 or vlan3 as device then it goes into the wire but on the VLAN which is not where my NAS is which I want to boot.<br>
&gt; &gt;<br>
&gt; &gt; Looking at the driver I found this interesting peace of code.<br>
&gt; &gt;<br>
&gt; &gt; static int<br>
&gt; &gt; gen_parse_tx(struct mbuf *m, int csum_flags) {<br>
&gt; &gt; ...<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (ether_type == ETHERTYPE_IP) {<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;COPY(((struct ip *)p)-&gt;ip_hl &lt;&lt; 2);<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;offset += ((struct ip *)p)-&gt;ip_hl &lt;&lt; 2;<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} else if (ether_type == ETHERTYPE_IPV6) {<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;COPY(sizeof(struct ip6_hdr));<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;offset += sizeof(struct ip6_hdr);<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} else {<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/*<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;* Unknown whether other cases require moving a header;<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;* ARP works without.<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*/<br>
&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br>
&gt; &gt; ...<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; There is also some code which handles EHTERTYPE_VLAN.<br>
&gt; &gt;<br>
&gt; &gt; I don't have time to start debugging this today. But would this ring a bell to anybody in connection to a wake-on-lan packet?<br>
<br>
&gt; I ran some experiments with tx checksum disabled, and it seems to<br>
&gt; matter. &nbsp;I have a change for the last block you listed that might<br>
&gt; help, but I haven't tested it yet.<br>
<br>
This patch seems to work:<br>
<br>
diff --git a/sys/arm64/broadcom/genet/if_genet.c b/sys/arm64/broadcom/genet/if_genet.c<br>
index 327af8acbcdd..b7ab86e7931d 100644<br>
--- a/sys/arm64/broadcom/genet/if_genet.c<br>
+++ b/sys/arm64/broadcom/genet/if_genet.c<br>
@@ -1305,6 +1305,8 @@ gen_parse_tx(struct mbuf *m, int csum_flags)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;* Unknown whether other cases require moving a header;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;* ARP works without.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*/<br>
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;COPY(min(gen_tx_hdr_min, m-&gt;m_len));<br>
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;offset += min(gen_tx_hdr_min, m-&gt;m_len);<br>
&nbsp;&nbsp;&nbsp;&nbsp;}<br>
&nbsp;&nbsp;&nbsp;&nbsp;return (offset);<br>
&nbsp;#undef COPY<br>
<br>
It needs an updated comment, but should be testable.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mike<br>
<br>
&gt; &gt; Regards,<br>
&gt; &gt; Ronald.<br>
<br>
&nbsp;</div>
</div>
</blockquote>
<br>
Hi,<br>
<br>
Thanks. Disabling both -txcsum and -txcsum6 works for me also.<br>
I can test your patch tommorow or on Thursday. I'm first testing a big mongodb 6.0 patch I hope to commit soon and this build occupies my rpi4 for some more hours.<br>
<br>
Regards,<br>
Ronald.<br>
&nbsp;</body></html>
------=_Part_231346_1677104857.1666722708420--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1539824734.231347.1666722708425>