Never mind, I found commit b3bdc3acbb44d74d0b7ba4d97169577a2b46dc88 that fixed this in 4.10-rc9 or so. Sorry for wasting your time.
Regards, Tom Cook On Mon, Mar 1, 2021 at 3:00 PM Tom Cook <tom.k.c...@gmail.com> wrote: > > I'm trying to use MACSEC on an arm64 embedded platform; I'm trying to > create an encrypted channel between two of them rather than doing > switch port access etc. The vendor's BSP only provides a 4.9 kernel > so that's what I'm using. I've added CONFIG_MACSEC=y to the kernel > config. This then forces CONFIG_CRYPTO_GCM=y and CONFIG_CRYPTO_AES=y. > > I've tried both manual configuration of MACSEC interfaces and also > using wpa_supplicant to do MKA negotiation. I then add IP addresses > to the MACSEC interfaces in the 192.168.149.0/24 subnet. In both > cases, the result is that the macsec0 interface has flags > BROADCAST,MULTICAST,UP,LOWER_UP but is in the UNKNOWN state. > Attempting to ping from one to the other results in encrypted ARP > frames being transmitted but then discarded at the receiver end. > tcpdump shows the frames arriving at the receiver and `ip -s macsec > show` shows these frames being added to the InPktsNotValid counter. > > AFAICT from macsec.c, InPktsNotValid means either that the decryption > failed or that memory allocation for the decryption failed. > > Is there some other bit of kernel config I need to do to get the > decryption to work correctly? > > The SOC is a cavium cn8030. This part is equipped with a crypto > accelerator but support for it is not compiled into the kernel. > > Thanks for any help, > Tom Cook
