From nobody Tue Oct 25 12:55:05 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 4MxX3P6nWkz4fQh3 for ; Tue, 25 Oct 2022 12:55:13 +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 4MxX3N5HRbz3jp6 for ; Tue, 25 Oct 2022 12:55:12 +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 29PCt5Sn015686; Tue, 25 Oct 2022 07:55:06 -0500 (CDT) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([10.0.1.1]) by mail.karels.net with ESMTPSA id +tKxNKncV2NEPQAA4+wvSQ (envelope-from ); Tue, 25 Oct 2022 07:55:05 -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 07:55:05 -0500 X-Mailer: MailMate (1.14r5921) Message-ID: <64FDF71E-B0B8-4625-833E-CCA62785DEB4@karels.net> In-Reply-To: <108673236.151493.1666699064016@localhost> References: <108673236.151493.1666699064016@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 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MxX3N5HRbz3jp6 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 [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; 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 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 o= n 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/rona= ld/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64 > > genet0: flags=3D8943 me= tric 0 mtu 1500 > options=3D68000b > > > RPI3 runs: > FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64 > > ue0: flags=3D8943 metri= c 0 mtu 1500 > options=3D80009 > > > 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 jail= s > vlan3: flags=3D8943 met= ric 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.