Regression with AX88179A: can't manually set MAC address anymore

Regression with AX88179A: can't manually set MAC address anymore

[Sergio Callegari]

Hi, reporting here as the issue I am seeing is cross distro and relevant 
to recent kernels. Hope this is appropriate.

I have a USB hub with AX88179A ethernet. I was able to use it regularly, 
until something changed in recent kernels to have this interface 
supported by the cdc_ncm driver. After this change it is not possible 
anymore to work with a manually set MAC address.

More details:

- before the kernel changes, the interface was supported by a dedicated 
kernel driver. The driver had glitches but was more or less working. The 
main issue was that after some usage the driver stopped working. Could 
fix these glitches with the driver at 
https://github.com/nothingstopsme/AX88179_178A_Linux_Driver

- after the kernel changes, loading the ax88179_178a.ko does not create 
a network device anymore. The interface can be used with the cdc_ncm 
driver, however it is not possible anymore to use a manually set MAC 
address.

When you manually set a MAC this appears to be accepted (e.g. ip link 
reports it correctly), but the card does not receive data anymore. For 
instance, trying to connect to a DHCP server, you see that the server 
receives the request, makes an offer, but the offer is never received by 
the network card.

This may be the same issue reported here: 
https://discussion.fedoraproject.org/t/ax88179-178a-network-fails-to-start-usb-to-eth/77687 
where the user says he cannot use the adapter when Network Manager is 
configured to employ a randomized MAC address.

Would be great to have this regression fixed or at least to have the 
command setting the MAC address erroring out properly.

Thanks for the attention.

Sergio Callegari

Re: Regression with AX88179A: can't manually set MAC address anymore

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

On Tue, Sep 05, 2023 at 01:02:22PM +0200, Sergio Callegari wrote:
> Hi, reporting here as the issue I am seeing is cross distro and relevant to
> recent kernels. Hope this is appropriate.
> 
> I have a USB hub with AX88179A ethernet. I was able to use it regularly,
> until something changed in recent kernels to have this interface supported
> by the cdc_ncm driver. After this change it is not possible anymore to work
> with a manually set MAC address.

Exactly on what version range?

> 
> More details:
> 
> - before the kernel changes, the interface was supported by a dedicated
> kernel driver. The driver had glitches but was more or less working. The
> main issue was that after some usage the driver stopped working. Could fix
> these glitches with the driver at
> https://github.com/nothingstopsme/AX88179_178A_Linux_Driver

Did you mean that you use out-of-tree module?

> 
> - after the kernel changes, loading the ax88179_178a.ko does not create a
> network device anymore. The interface can be used with the cdc_ncm driver,
> however it is not possible anymore to use a manually set MAC address.
> 
> When you manually set a MAC this appears to be accepted (e.g. ip link
> reports it correctly), but the card does not receive data anymore. For
> instance, trying to connect to a DHCP server, you see that the server
> receives the request, makes an offer, but the offer is never received by the
> network card.
> 

How is the reproducer?

> This may be the same issue reported here: https://discussion.fedoraproject.org/t/ax88179-178a-network-fails-to-start-usb-to-eth/77687
> where the user says he cannot use the adapter when Network Manager is
> configured to employ a randomized MAC address.
> 

Confused...

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Regression with AX88179A: can't manually set MAC address anymore

[Sergio Callegari]

On 05/09/2023 14:31, Bagas Sanjaya wrote:
> On Tue, Sep 05, 2023 at 01:02:22PM +0200, Sergio Callegari wrote:
>> Hi, reporting here as the issue I am seeing is cross distro and relevant to
>> recent kernels. Hope this is appropriate.
>>
>> I have a USB hub with AX88179A ethernet. I was able to use it regularly,
>> until something changed in recent kernels to have this interface supported
>> by the cdc_ncm driver. After this change it is not possible anymore to work
>> with a manually set MAC address.
> Exactly on what version range?

Hard to say without extensive testing since distros move from kernel to 
kernel with big version jumps. The adapter was surely usable in ubuntu 
22.04 with kernel 5.15, breaking this Summer as kernel 6.2 arrived as an 
HWE kernel.

>> More details:
>>
>> - before the kernel changes, the interface was supported by a dedicated
>> kernel driver. The driver had glitches but was more or less working. The
>> main issue was that after some usage the driver stopped working. Could fix
>> these glitches with the driver at
>> https://github.com/nothingstopsme/AX88179_178A_Linux_Driver
> Did you mean that you use out-of-tree module?

I mean that with kernel 5.15 I could use the in-tree module with some 
glitches (interface occasionally stopping on teleconferencing) as well 
as the indicated out of tree module with no glitches.

With current kernels (certainly from 6.2 on) manually setting a MAC 
address breaks the interface. Furthermore, even if it compiles and loads 
fine, it is impossible to use the out of tree module because it does not 
create the eth device anymore (the eth device now appears with the 
cdc_ncn module). Being this an out of tree module, this is not very 
important, though.

>> - after the kernel changes, loading the ax88179_178a.ko does not create a
>> network device anymore. The interface can be used with the cdc_ncm driver,
>> however it is not possible anymore to use a manually set MAC address.
>>
>> When you manually set a MAC this appears to be accepted (e.g. ip link
>> reports it correctly), but the card does not receive data anymore. For
>> instance, trying to connect to a DHCP server, you see that the server
>> receives the request, makes an offer, but the offer is never received by the
>> network card.
>>
> How is the reproducer?

1. Turn down the interface with the `ip` command.

2. Use the `ip` command to set an hardware address (xx:xx:xx:xx:xx:xx) 
different from the original one (yy:yy:yy:yy:yy:yy) from the adapter.

3. Try to get an IP address from a DHCP server configured to respond to 
xx:xx:xx:xx:xx:xx

4. Observe that the system is unable to get an IP address from DHCP 
(keeps asking)

5. Look at the DHCP server logs and observe that the DHCP server 
receives the request from mac xx:xx:xx:xx:xx:xx and makes an offer, but 
this is never accepted (possibly never received).

Skipping 2. and setting the DHCP server to respond to yy:yy:yy:yy:yy:yy, 
everything works as expected. So it is the manual setting of an hardware 
address that triggers the issue. The DHCP server is OK: steps 1-5 work 
fine with other NICs and used to work fine with the AX88179A USB NIC 
with kernel 5.15.

Would like to triage better, but it is not easy for me since I do not 
own the USB Hubs containing the AX88179A based ethernet port. I get 
these where I work and I am not expected to detach them from the office 
equipment. I'll see what I can do.

>> This may be the same issue reported here:https://discussion.fedoraproject.org/t/ax88179-178a-network-fails-to-start-usb-to-eth/77687
>> where the user says he cannot use the adapter when Network Manager is
>> configured to employ a randomized MAC address.
>>
> Confused...

The discussion on the fedora forum that I linked is what provided me 
with a hint about the issue with the manual MAC address. In that 
discussion a user reports an issue about an AX88179A unusable in fedora 
(that uses fairly recent kernels). The user solved the issue disabling 
randomization of the MAC address (which implies changing the MAC). 
Namely he says "The wired connection had a “virtual mac address” 
randomly generated set in Network Manager GUI (I can’t remember why I 
had set that before) [...] disabling this configuration the wired 
connection started ok". However, the details are modest, so that user 
might as well had encountered an unrelated problem, pointing me to the 
manual MAC setting just by coincidence.

Thanks for your reply that testifies attention for the issue.

Sergio Callegari

Re: Regression with AX88179A: can't manually set MAC address anymore

[Andrew Lunn]

On Tue, Sep 05, 2023 at 01:02:22PM +0200, Sergio Callegari wrote:
> Hi, reporting here as the issue I am seeing is cross distro and relevant to
> recent kernels. Hope this is appropriate.
> 
> I have a USB hub with AX88179A ethernet. I was able to use it regularly,
> until something changed in recent kernels to have this interface supported
> by the cdc_ncm driver. After this change it is not possible anymore to work
> with a manually set MAC address.
> 
> More details:
> 
> - before the kernel changes, the interface was supported by a dedicated
> kernel driver. The driver had glitches but was more or less working. The
> main issue was that after some usage the driver stopped working. Could fix
> these glitches with the driver at
> https://github.com/nothingstopsme/AX88179_178A_Linux_Driver
> 
> - after the kernel changes, loading the ax88179_178a.ko does not create a
> network device anymore. The interface can be used with the cdc_ncm driver,
> however it is not possible anymore to use a manually set MAC address.

The cdc_ncm driver has a .ndo_set_mac_address implementation which
only changes the MAC address in the net_device structure. The
ax88179_178a driver however performs a hardware access:

       /* Set the MAC address */
        ret = ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_NODE_ID, ETH_ALEN,
                                 ETH_ALEN, net->dev_addr);

So it is quite likely that with the cdc_ncm driver, the hardware is
still performing ingress filtering based on the manufacturers assigned
MAC address, not the MAC address configured via ip link set.

I don't know the CDC NCM protocol, so i've no idea if this access is
part of the protocol. If it is, the cdc_ncm driver should be extended.

     Andrew

Re: Regression with AX88179A: can't manually set MAC address anymore

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Tue, Sep 05, 2023 at 09:34:53PM +0200, Sergio Callegari wrote:
> On 05/09/2023 14:31, Bagas Sanjaya wrote:
> > On Tue, Sep 05, 2023 at 01:02:22PM +0200, Sergio Callegari wrote:
> > > More details:
> > > 
> > > - before the kernel changes, the interface was supported by a dedicated
> > > kernel driver. The driver had glitches but was more or less working. The
> > > main issue was that after some usage the driver stopped working. Could fix
> > > these glitches with the driver at
> > > https://github.com/nothingstopsme/AX88179_178A_Linux_Driver
> > Did you mean that you use out-of-tree module?
> 
> I mean that with kernel 5.15 I could use the in-tree module with some
> glitches (interface occasionally stopping on teleconferencing) as well as
> the indicated out of tree module with no glitches.
> 
> With current kernels (certainly from 6.2 on) manually setting a MAC address
> breaks the interface. Furthermore, even if it compiles and loads fine, it is
> impossible to use the out of tree module because it does not create the eth
> device anymore (the eth device now appears with the cdc_ncn module). Being
> this an out of tree module, this is not very important, though.

Then can you please file issue against your external module on that
GH link?

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Regression with AX88179A: can't manually set MAC address anymore

[Sergio Callegari]

On 06/09/2023 03:43, Bagas Sanjaya wrote:
> On Tue, Sep 05, 2023 at 09:34:53PM +0200, Sergio Callegari wrote:
>> I mean that with kernel 5.15 I could use the in-tree module with some
>> glitches (interface occasionally stopping on teleconferencing) as well as
>> the indicated out of tree module with no glitches.
>>
>> With current kernels (certainly from 6.2 on) manually setting a MAC address
>> breaks the interface. Furthermore, even if it compiles and loads fine, it is
>> impossible to use the out of tree module because it does not create the eth
>> device anymore (the eth device now appears with the cdc_ncn module). Being
>> this an out of tree module, this is not very important, though.
> Then can you please file issue against your external module on that
> GH link?

Done, but as mentioned, out-of-tree implementations on GH are less 
interesting than having the in-tree driver working properly.

So if the in-tree driver could be fixed to correctly support the manual 
configuration of the hardware (MAC) address as it used to be that would 
be the best. I hope that Andrew Lunn's hypothesis is correct, and that 
cdc_ncm can be extended to work with AX88179A even when a manual MAC 
addr is configured.

Thanks,

Sergio

Re: Regression with AX88179A: can't manually set MAC address anymore

[Andrew Lunn]

> So if the in-tree driver could be fixed to correctly support the manual
> configuration of the hardware (MAC) address as it used to be that would be
> the best. I hope that Andrew Lunn's hypothesis is correct, and that cdc_ncm
> can be extended to work with AX88179A even when a manual MAC addr is
> configured.

I think it can, but it looks like it needs a different
implementation. The CDC NCM standard is publicly available. It
documents an optional call to set the MAC address, and there appears
to be a capability bit to indicate if its implemented in a specific
device. Ideally if the bit is not set -EOPNOTSUPP should be returned
when trying to set the MAC address, otherwise make the call to let the
hardware know of the new MAC address.

Sorry, i don't have the time or the hardware to actually implement
this. But i can review patches and help with processes.

      Andrew

	

Re: Regression with AX88179A: can't manually set MAC address anymore

[Sergio Callegari]

For the time being having AX88179A error out on attempts to set an 
hardware address would possibly be useful, though.

Sergio

On 06/09/2023 14:31, Andrew Lunn wrote:
>> So if the in-tree driver could be fixed to correctly support the manual
>> configuration of the hardware (MAC) address as it used to be that would be
>> the best. I hope that Andrew Lunn's hypothesis is correct, and that cdc_ncm
>> can be extended to work with AX88179A even when a manual MAC addr is
>> configured.
> I think it can, but it looks like it needs a different
> implementation. The CDC NCM standard is publicly available. It
> documents an optional call to set the MAC address, and there appears
> to be a capability bit to indicate if its implemented in a specific
> device. Ideally if the bit is not set -EOPNOTSUPP should be returned
> when trying to set the MAC address, otherwise make the call to let the
> hardware know of the new MAC address.
>
> Sorry, i don't have the time or the hardware to actually implement
> this. But i can review patches and help with processes.
>
>        Andrew
>
>