From nobody Tue Oct 25 16:11:54 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MxcQN5fg6z4gCpf for ; Tue, 25 Oct 2022 16:11:56 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4MxcQM6LF1z49Wh for ; Tue, 25 Oct 2022 16:11:55 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 29PGBsGq016682 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 25 Oct 2022 11:11:55 -0500 (CDT) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 29PGBsbq016681; Tue, 25 Oct 2022 11:11:54 -0500 (CDT) (envelope-from mike) Message-Id: <202210251611.29PGBsbq016681@mail.karels.net> To: Ronald Klop cc: freebsd-arm@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: wake-on-lan lost from rpi4 (works on rpi3) In-reply-to: Your message of Tue, 25 Oct 2022 10:22:38 -0500. <676FFB6B-0D38-47D4-AED8-EA2D5F685F43@karels.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16679.1666714314.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2022 11:11:54 -0500 X-Rspamd-Queue-Id: 4MxcQM6LF1z49Wh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [-1.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; HAS_REPLYTO(0.00)[mike@karels.net]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FREEFALL_USER(0.00)[mike]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[karels.net]; FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net] X-ThisMailContainsUnwantedMimeParts: N I wrote: > On 25 Oct 2022, at 9:13, Ronald Klop wrote: > > Van: Mike Karels > > Datum: dinsdag, 25 oktober 2022 14:55 > > Aan: Ronald Klop > > 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 RPI3= B+ 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 R= PI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* o= n 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/ro= nald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64 > >>> > >>> genet0: flags=3D8943= metric 0 mtu 1500 > >>> options=3D68000b > >>> > >>> > >>> RPI3 runs: > >>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64 > >>> > >>> ue0: flags=3D8943 me= tric 0 mtu 1500 > >>> options=3D80009 > >>> > >>> > >>> Does genet0 not support these packages? > >>> What can prevent this packet to go on the ethernet while tcpdump sti= ll shows it is outgoing on the interface? > >>> genet0 does have a vlan configured connected to a bridge0 for some j= ails > >>> vlan3: flags=3D8943 = metric 0 mtu 1500 > >>> options=3D80000 > >>> 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 b= ut 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 =3D=3D ETHERTYPE_IP) { > > COPY(((struct ip *)p)->ip_hl << 2); > > offset +=3D ((struct ip *)p)->ip_hl << 2; > > } else if (ether_type =3D=3D ETHERTYPE_IPV6) { > > COPY(sizeof(struct ip6_hdr)); > > offset +=3D 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/gene= t/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 +=3D min(gen_tx_hdr_min, m->m_len); } return (offset); #undef COPY It needs an updated comment, but should be testable. Mike > > Regards, > > Ronald.