Re: wake-on-lan lost from rpi4 (works on rpi3)

Mike Karels <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On 25 Oct 2022, at 9:13, Ronald Klop wrote:

> Van: Mike Karels <[email protected]>
> Datum: dinsdag, 25 oktober 2022 14:55
> Aan: Ronald Klop <[email protected]>
> CC: [email protected]
> 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.

		Mike

> Regards,
> Ronald.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.