Date: Tue, 25 Oct 2022 11:11:54 -0500 From: Mike Karels <mike@karels.net> To: Ronald Klop <ronald-lists@klop.ws> Cc: freebsd-arm@freebsd.org Subject: Re: wake-on-lan lost from rpi4 (works on rpi3) Message-ID: <202210251611.29PGBsbq016681@mail.karels.net> In-Reply-To: Your message of Tue, 25 Oct 2022 10:22:38 -0500. <676FFB6B-0D38-47D4-AED8-EA2D5F685F43@karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>=
metric 0 mtu 1500
> >>> options=3D68000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6,TXC=
SUM_IPV6>
> >>>
> >>>
> >>> RPI3 runs:
> >>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64
> >>>
> >>> ue0: flags=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> me=
tric 0 mtu 1500
> >>> options=3D80009<RXCSUM,VLAN_MTU,LINKSTATE>
> >>>
> >>>
> >>> 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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> =
metric 0 mtu 1500
> >>> options=3D80000<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 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202210251611.29PGBsbq016681>