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