From nobody Tue Oct 25 15:22:38 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 4MxbKZ43Z2z4g5mW for ; Tue, 25 Oct 2022 15:22:42 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4MxbKY4W6Wz42V9 for ; Tue, 25 Oct 2022 15:22:41 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTP id 29PFMdLl016344; Tue, 25 Oct 2022 10:22:40 -0500 (CDT) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([10.0.1.1]) by mail.karels.net with ESMTPSA id yP0ZHT//V2PWPwAA4+wvSQ (envelope-from ); Tue, 25 Oct 2022 10:22:39 -0500 From: Mike Karels To: Ronald Klop Cc: freebsd-arm@freebsd.org Subject: Re: wake-on-lan lost from rpi4 (works on rpi3) Date: Tue, 25 Oct 2022 10:22:38 -0500 X-Mailer: MailMate (1.14r5921) Message-ID: <676FFB6B-0D38-47D4-AED8-EA2D5F685F43@karels.net> In-Reply-To: <1407175820.10534.1666707226593@localhost> References: <108673236.151493.1666699064016@localhost> <64FDF71E-B0B8-4625-833E-CCA62785DEB4@karels.net> <1407175820.10534.1666707226593@localhost> 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MxbKY4W6Wz42V9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(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)[]; DMARC_NA(0.00)[karels.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 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 RP= I4 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: S= at 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 met= ric 0 mtu 1500 >>> options=3D80009 >>> >>> >>> Does genet0 not support these packages? >>> What can prevent this packet to go on the ethernet while tcpdump stil= l shows it is outgoing on the interface? >>> genet0 does have a vlan configured connected to a bridge0 for some ja= ils >>> vlan3: flags=3D8943 m= etric 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=E2=80=99t 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 bu= t 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=E2=80=99t tested it yet. Mike > Regards, > Ronald.