RE: [PATCH v2] net: usb: ax88179_178a: avoid writing the mac address before first reading
Hello,
I am using a TP-Link UE306 USB Ethernet adapter. The kernel detects it as an ASIX AX88179A USB Ethernet adapter. When using a different MAC address than the adapter's own (i.e. MAC address randomization), I am unable to send or receive packets unless set to promiscuous mode.
I am using NetworkManager to manage my connections. When I set 802-3-ethernet.cloned-mac-address to the device's MAC address in the connection settings (i.e. `nmcli con edit), the device works as expected. When that property is not set (null value), the device is only able to receive packets when set to promiscuous mode.
uname -a output: Linux hostname 6.8.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 18:53:26 +0000 x86_64 GNU/Linux This is Arch Linux's kernel. The patches applied are here: https://github.com/archlinux/linux/releases/tag/v6.8.8-arch1
dmesg: [37988.917741] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd [37989.208722] usb 2-2: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00 [37989.208744] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [37989.208753] usb 2-2: Product: AX88179A [37989.208760] usb 2-2: Manufacturer: ASIX [37989.208766] usb 2-2: SerialNumber: 0003B40D [37989.481930] cdc_ncm 2-2:2.0: MAC-Address: <removed> [37989.481949] cdc_ncm 2-2:2.0: setting rx_max = 16384 [37989.494646] cdc_ncm 2-2:2.0: setting tx_max = 16384 [37989.506072] cdc_ncm 2-2:2.0 eth1: register 'cdc_ncm' at usb-0000:00:14.0-2, CDC NCM (NO ZLP), <removed>
journalctl (from when not in promiscuous mode): Apr 29 17:34:47 hostname kernel: usb 2-1: new SuperSpeed USB device number 5 using xhci_hcd Apr 29 17:34:48 hostname kernel: usb 2-1: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00 Apr 29 17:34:48 hostname kernel: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Apr 29 17:34:48 hostname kernel: usb 2-1: Product: AX88179A Apr 29 17:34:48 hostname kernel: usb 2-1: Manufacturer: ASIX Apr 29 17:34:48 hostname kernel: usb 2-1: SerialNumber: 0003B40D Apr 29 17:34:48 hostname kernel: cdc_ncm 2-1:2.0: MAC-Address: <removed> Apr 29 17:34:48 hostname kernel: cdc_ncm 2-1:2.0: setting rx_max = 16384 Apr 29 17:34:48 hostname kernel: cdc_ncm 2-1:2.0: setting tx_max = 16384 Apr 29 17:34:48 hostname kernel: cdc_ncm 2-1:2.0 eth1: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM (NO ZLP), <removed> Apr 29 17:34:48 hostname NetworkManager[5652]: <info> [1714430088.5005] manager: (eth1): new Ethernet device (/org/freedesktop/NetworkManager/Devices/14) Apr 29 17:34:48 hostname mtp-probe[6423]: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1" Apr 29 17:34:48 hostname mtp-probe[6423]: bus: 2, device: 5 was not an MTP device Apr 29 17:34:49 hostname (udev-worker)[6422]: Network interface NamePolicy= disabled on kernel command line. Apr 29 17:34:49 hostname NetworkManager[5652]: <info> [1714430089.1558] device (eth1): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') Apr 29 17:34:49 hostname mtp-probe[6456]: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1" Apr 29 17:34:49 hostname mtp-probe[6456]: bus: 2, device: 5 was not an MTP device Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2247] device (eth1): carrier: link connected Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2255] device (eth1): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed') Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2275] policy: auto-activating connection 'Wired connection 2' (e1106b48-8695-3ed4-b512-a0909ddaa247) Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2279] device (eth1): Activation: starting connection 'Wired connection 2' (e1106b48-8695-3ed4-b512-a0909ddaa247) Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2280] device (eth1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2282] manager: NetworkManager state is now CONNECTING Apr 29 17:34:51 hostname NetworkManager[5652]: <warn> [1714430091.2284] platform-linux: do-change-link[9]: failure 16 (Device or resource busy) Apr 29 17:34:51 hostname systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully. Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3634] device (eth1): set-hw-addr: set-cloned MAC address to 6A:0D:A2:E2:9D:A6 (random) Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3646] device (eth1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3729] device (eth1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3740] dhcp4 (eth1): activation: beginning transaction (timeout in 45 seconds) Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3791] dhcp4 (eth1): dhclient started with pid 6459 Apr 29 17:34:51 hostname dhclient[6459]: DHCPREQUEST for 192.168.1.169 on eth1 to 255.255.255.255 port 67 Apr 29 17:34:51 hostname dhclient[6459]: DHCPNAK from 192.168.1.1 Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.4578] dhcp4 (eth1): state changed no lease
Thanks, Isaac Ganoung
On Mon, 29 Apr 2024 18:16:05 -0500 Isaac Ganoung wrote:
uname -a output: Linux hostname 6.8.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 18:53:26 +0000 x86_64 GNU/Linux This is Arch Linux's kernel. The patches applied are here: https://github.com/archlinux/linux/releases/tag/v6.8.8-arch1
v6.8.8 has 56f78615b already. We need another patch, Jose?
v6.8.8 has 56f78615b already. We need another patch, Jose?
Hello Jakub,
I will try to analyze it during the next week (I will be out until then).
In the meantime, in order to get more information about the possible regression:
Isaac, Which version was it working in? Do you know if it was working before d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets")?
Best regards José Ignacio
Hi, Jose
On Wed, 1 May 2024 at 00:01, Jose Ignacio Tornos Martinez jtornosm@redhat.com wrote:
v6.8.8 has 56f78615b already. We need another patch, Jose?
Hello Jakub,
I will try to analyze it during the next week (I will be out until then).
Not sure if you have checked it already, this commit causes an issue for the db845c + ACK android15-6.6[1] + AOSP main Android configuration, the ethernet does not work, there is no ip address assigned, like: db845c:/ # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 02:00:89:7a:fb:61 Driver ax88179_178a UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 TX bytes:0
db845c:/ # if I have this change reverted, then it will work again: db845c:/ # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 02:00:89:7a:fb:61 Driver ax88179_178a inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 240e:305:2c88:4700:4b6d:926d:1592:fc5e/64 Scope: Global inet6 addr: 240e:305:2c88:4700:edc9:86ec:7c5e:b028/64 Scope: Global inet6 addr: fe80::32ce:8a2e:269d:e53f/64 Scope: Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:966 errors:0 dropped:33 overruns:0 frame:0 TX packets:475 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:51193 TX bytes:39472
db845c:/ #
One thing to be noted here is that, during the boot, the MAC address will be reassigned to make sure each board has its own unique MAC address with the following commands: /vendor/bin/ifconfig eth0 down /vendor/bin/ifconfig eth0 hw ether "${ETHADDR}" /vendor/bin/ifconfig eth0 up
Could you please help have a check and fix or give some suggestions on this issue?
[1]: https://android.googlesource.com/kernel/common/+/refs/heads/android15-6.6
Hello Yongqin,
Sorry for the inconveniences.
I don't have the db845c, could you provide information about the type of device and protocol used? Related driver logs would be very helpful for this.
Best regards José Ignacio
Hi, Jose
On Wed, 8 May 2024 at 15:57, Jose Ignacio Tornos Martinez jtornosm@redhat.com wrote:
Hello Yongqin,
Sorry for the inconveniences.
I don't have the db845c, could you provide information about the type of device and protocol used?
The db845c uses an RJ45 as the physical interface. It has the translation from PCIe0 to USB and USB to Gigabit Ethernet controller.
For details, maybe you could check the hardware details from the documents here: https://www.96boards.org/documentation/consumer/dragonboard/dragonboard845c/...
Related driver logs would be very helpful for this.
Here is the log from the serial console side: https://gist.github.com/liuyq/809247d8a12aa1d9e03058e8371a4d44
Please let me know if I could try and provide more information for the investigation.
Hi, Jose
On Wed, 8 May 2024 at 12:41, Yongqin Liu yongqin.liu@linaro.org wrote:
Hi, Jose
On Wed, 8 May 2024 at 15:57, Jose Ignacio Tornos Martinez jtornosm@redhat.com wrote:
Hello Yongqin,
Sorry for the inconveniences.
I don't have the db845c, could you provide information about the type of device and protocol used?
The db845c uses an RJ45 as the physical interface. It has the translation from PCIe0 to USB and USB to Gigabit Ethernet controller.
For details, maybe you could check the hardware details from the documents here: https://www.96boards.org/documentation/consumer/dragonboard/dragonboard845c/...
Related driver logs would be very helpful for this.
Here is the log from the serial console side: https://gist.github.com/liuyq/809247d8a12aa1d9e03058e8371a4d44
Please let me know if I could try and provide more information for the investigation.
Just want to check, not sure if you have checked the serial log file, or do you have other suggestions about what we should try next,
Hello Yongqin,
I could not get a lot of information from the logs, but at least I identified the device. Anyway, I found the issue and the solution is being applied: https://lore.kernel.org/netdev/171564122955.1634.5508968909715338167.git-pat...
Best regards José Ignacio
Hi Jose On Tue, 14 May 2024 at 09:00, Jose Ignacio Tornos Martinez jtornosm@redhat.com wrote:
Hello Yongqin,
I could not get a lot of information from the logs, but at least I identified the device. Anyway, I found the issue and the solution is being applied: https://lore.kernel.org/netdev/171564122955.1634.5508968909715338167.git-pat...
Ah, I was not aware of it:(
Thanks a lot for the work!
Hi, Jose
On Tue, 14 May 2024 at 17:14, Yongqin Liu yongqin.liu@linaro.org wrote:
Hi Jose On Tue, 14 May 2024 at 09:00, Jose Ignacio Tornos Martinez jtornosm@redhat.com wrote:
Hello Yongqin,
I could not get a lot of information from the logs, but at least I identified the device. Anyway, I found the issue and the solution is being applied: https://lore.kernel.org/netdev/171564122955.1634.5508968909715338167.git-pat...
Ah, I was not aware of it:(
Sorry, I was in a trip last week, and not able to test it,
But the patch does not help for my case, here is the output on the serial console side after I cherry picked the above patch you shared with me.
Could you please help to check more?
linux-stable-mirror@lists.linaro.org
-
Isaac Ganoung -
Jakub Kicinski -
Jose Ignacio Tornos Martinez -
Yongqin Liu