USB QNAP QNA-UC5G1T dongle

Hi,

I have tested the usb dongle QNAP QNA-UC5G1T.
Sometimes I have sometimes some troubles when rebooting. The DHCP or the hardware is not well handled.
This dongle is on the red network with dhcp settings.

have you any ideas of what I can do?

note: the dongle has the last firmware taken on qnap website

The log when it is OK.
Aug 1 05:23:29 ipfire kernel: usb 2-4: new SuperSpeed USB device number 3 using xhci_hcd
Aug 1 05:23:29 ipfire kernel: usb 2-4: New USB device found, idVendor=1c04, idProduct=0015, bcdDevice= 1.01
Aug 1 05:23:29 ipfire kernel: usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 1 05:23:29 ipfire kernel: usb 2-4: Product: Pacific▒
Aug 1 05:23:29 ipfire kernel: usb 2-4: Manufacturer: QNAP▒
Aug 1 05:23:29 ipfire kernel: usb 2-4: SerialNumber: 2BI03146
Aug 1 05:23:29 ipfire kernel: aqc111 2-4:1.0 eth0: register ‘aqc111’ at usb-0000:00:14.0-4, QNAP QNA-UC5G1T USB to 5GbE Adapter, 24:5e:be:7e:cb:19
Aug 1 05:23:29 ipfire kernel: aqc111 2-4:1.0 red0: renamed from eth0
Aug 1 05:23:30 ipfire vnstatd[3769]: Interface “red0” enabled.

The log when it’s failed.
Aug 1 05:22:42 ipfire kernel: usb usb4: USB disconnect, device number 1
Aug 1 05:22:42 ipfire dhcpcd[3989]: red0: carrier lost
Aug 1 05:22:42 ipfire charon: 05[KNL] interface red0 deactivated
Aug 1 05:22:42 ipfire kernel: usb 4-1: USB disconnect, device number 2
Aug 1 05:22:42 ipfire kernel: aqc111 4-1:1.0 red0: unregister ‘aqc111’ usb-0000:6c:00.0-1, QNAP QNA-UC5G1T USB to 5GbE Adapter
Aug 1 05:22:42 ipfire kernel: aqc111 4-1:1.0 red0: Failed to read(0x1) reg index 0x0002: -19
Aug 1 05:22:42 ipfire kernel: aqc111 4-1:1.0 red0: Failed to write(0x1) reg index 0x0002: -19
Aug 1 05:22:42 ipfire kernel: aqc111 4-1:1.0 red0: Failed to write(0x1) reg index 0x0002: -19
Aug 1 05:22:42 ipfire kernel: aqc111 4-1:1.0 red0: Failed to write(0x61) reg index 0x0000: -19
Aug 1 05:22:42 ipfire charon: 08[KNL] 192.168.10.35 disappeared from red0
Aug 1 05:22:42 ipfire charon: 11[KNL] interface red0 deleted
Aug 1 05:22:42 ipfire kernel: aqc111 4-1:1.0 red0 (unregistered): Failed to write(0x1) reg index 0x0002: -19
Aug 1 05:22:42 ipfire kernel: aqc111 4-1:1.0 red0 (unregistered): Failed to write(0x1) reg index 0x0002: -19
Aug 1 05:22:42 ipfire kernel: aqc111 4-1:1.0 red0 (unregistered): Failed to write(0x61) reg index 0x0000: -19
Aug 1 05:22:42 ipfire kernel: xhci_hcd 0000:6c:00.0: USB bus 4 deregistered
Aug 1 05:22:42 ipfire kernel: xhci_hcd 0000:6c:00.0: remove, state 4
Aug 1 05:22:42 ipfire kernel: usb usb3: USB disconnect, device number 1
Aug 1 05:22:42 ipfire kernel: xhci_hcd 0000:6c:00.0: Host halt failed, -19
Aug 1 05:22:42 ipfire kernel: xhci_hcd 0000:6c:00.0: Host not accessible, reset failed.
Aug 1 05:22:42 ipfire kernel: xhci_hcd 0000:6c:00.0: USB bus 3 deregistered
Aug 1 05:22:42 ipfire kernel: pcieport 0000:03:01.0: Unable to change power state from D3hot to D0, device inaccessible
Aug 1 05:22:42 ipfire kernel: pcieport 0000:03:01.0: Runtime PM usage count underflow!
Aug 1 05:22:42 ipfire kernel: pcieport 0000:03:00.0: Unable to change power state from D3hot to D0, device inaccessible
Aug 1 05:22:42 ipfire kernel: pci_bus 0000:04: busn_res: [bus 04] is released
Aug 1 05:22:42 ipfire kernel: pci 0000:03:00.0: Removing from iommu group 13
Aug 1 05:22:42 ipfire kernel: pci_bus 0000:05: busn_res: [bus 05-6b] is released
Aug 1 05:22:42 ipfire kernel: pci 0000:03:01.0: Removing from iommu group 14
Aug 1 05:22:42 ipfire kernel: pci 0000:6c:00.0: Removing from iommu group 15
Aug 1 05:22:42 ipfire kernel: pci_bus 0000:6c: busn_res: [bus 6c] is released
Aug 1 05:22:42 ipfire kernel: pci 0000:03:02.0: Removing from iommu group 15
Aug 1 05:22:42 ipfire kernel: pci_bus 0000:03: busn_res: [bus 03-6c] is released
Aug 1 05:22:42 ipfire kernel: pci 0000:02:00.0: Removing from iommu group 12
Aug 1 05:22:42 ipfire dhcpcd[3989]: ps_bpf_recvbpf: unexpected event 0x0100
Aug 1 05:22:42 ipfire dhcpcd[3989]: red0: deleting route to 192.168.10.0/24
Aug 1 05:22:42 ipfire dhcpcd[3989]: red0: deleting default route via 192.168.10.254
Aug 1 05:22:42 ipfire dhcpcd.exe[8220]: red0 has been brought down (EXPIRE)
Aug 1 05:22:42 ipfire charon: 00[DMN] SIGINT received, shutting down
Aug 1 05:22:42 ipfire openvpnserver[7717]: ERROR: Linux route delete command failed: external program exited with error status: 2
Aug 1 05:22:42 ipfire openvpnserver[7717]: /sbin/ip addr del dev tun0 local 192.168.6.1 peer 192.168.6.2
Aug 1 05:22:42 ipfire openvpnserver[7717]: Linux ip addr del failed: external program exited with error status: 2
Aug 1 05:22:42 ipfire openvpnserver[7717]: SIGTERM[hard,] received, process exiting
Aug 1 05:22:42 ipfire root[7757]: Connection to OpenVPN has been lost: Could not read from socket
Aug 1 05:22:42 ipfire ipsec_starter[7686]: charon stopped after 200 ms
Aug 1 05:22:42 ipfire ipsec_starter[7686]: ipsec starter stopped
Aug 1 05:22:43 ipfire ntpd[7951]: Deleting interface #4 red0, 192.168.10.35#123, interface stats: received=2, sent=2, dropped=0, active_time=10 secs
Aug 1 05:22:43 ipfire ntpd[7951]: 193.52.136.2 local addr 192.168.10.35 →
Aug 1 05:22:43 ipfire ntpd[7951]: 195.154.226.102 local addr 192.168.10.35 →
Aug 1 05:22:43 ipfire ntpd[7951]: Deleting interface #6 tun0, 192.168.6.1#123, interface stats: received=0, sent=0, dropped=0, active_time=10 secs
Aug 1 05:22:45 ipfire vnstatd[3769]: Interface “tun0” disabled.
Aug 1 05:22:45 ipfire vnstatd[3769]: Interface “red0” disabled.
Aug 1 05:22:46 ipfire kernel: DROP_CTINVALID IN= OUT=orange0 SRC=192.168.1.1 DST=192.168.1.29 LEN=162 TOS=0x00 PREC=0xC0 TTL=64 ID=58782 PROTO=ICMP TYPE=3 CODE=0 [SRC=192.168.1.29 DST=90.6.52.56 LEN=134 TOS=0x00 PREC=0x00 TTL=64 ID=5811 DF PROTO=TCP SPT=993 DPT=51124 WINDOW=506 RES=0x00 ACK PSH FIN URGP=0 ]
Aug 1 05:22:50 ipfire dhcpcd[3989]: red0: removing interface
Aug 1 05:22:50 ipfire dhcpcd.exe[9700]: Unhandled DHCP event: DEPARTED
Aug 1 05:22:50 ipfire dhcpcd[3989]: main: control_stop: No such file or directory
Aug 1 05:22:50 ipfire dhcpcd[3989]: dhcpcd exited

Thanks you

Based on the logs, it’s evident that the issue stems from the USB adapter, rather than the DHCP service. Unfortunately, USB interfaces are known for their unreliability. A possible cause could be that when failing the system might attempt to access the dongle before it is completely ready, which can lead to these errors.

You can try different USB ports, but I assume you have already tested this. I wish I could be more useful, but I think other than using a real ethernet card, there is not much you can do.

1 Like

I will test next week but I have updated my bios.

I was in version 72 and I see some update in version 73 and upper.
I have also an usb 3 orange with capability charging which will always turn on the dongle.

I have restarted several time, with the dongle without any network cable, and I have now always a led turn on on my rj45 port. That was not the case this morning, I hope the new bios fix my trouble. I don’t want to break my network for the end of this week. I need it, I will retry next one.

what the bios update fix on usb :

  • Fixed issue regarding USB connector naming for BE products
  • Updated BIOS code for BIOS recovery with USB flash drive
  • Fixed issue: Blue USB 3.0 port have 5V every time when system AC
    power turn on/turn off.

I was on a blue USB 3.0 port but I don’t understand the 3rd point.

A USB 3.0 port (color-coded blue) typically supplies power at 5V. However, this power should not be constantly supplied especially when the system is being turned on or off. Constant power could potentially lead to power management issues or even hardware damage in extreme cases.

So, this log entry suggests that the firmware update has fixed an issue where the USB 3.0 port was improperly receiving constant power whenever the system was turned on or off. Now, with the firmware update, the power management for the USB port should behave as expected, providing power when necessary and not maintaining a constant 5V when the system is powering on or off.

1 Like

the trouble is not solved.
the dongle is working nice on reboot if I do not plug a cable. One of the 2 leds of the rj45 is turned on.
If I plug a cable, I have traffic. At reboot, none of the 2 led are turned on. If I shutdown the pc and restart it, I have no trouble, I think because the pc is off, the dongle is ‘reset’.
So, for me the trouble happens when ipfire is shutdowning. The dongle seems to received something wrong which put the device in a wrong state. The only wait to restore the dongle is to cut the electricity.

@world
what about the possibility to use the TB3 from the BE :person_shrugging:
this would be PCie :smiley_cat:

I can not do that, i have an Intel NUC. I can only use USB dongle.

maybe you can try to reset the USB interface programmatically at the end of the boot sequence. To do so you could write a script to be called in rc.local.

For example:

#!/bin/bash

# the script will reset the specified USB device by disabling and then 
# re-enabling it. The $1 argument is used to extract the bus and device 
# numbers which are then used to build the path to the authorized file. 
# The cut command is used to extract the bus and device numbers
# from the device file path.

if [[ $# -ne 1 ]]; then
    echo "Usage: $0 device" >&2
    echo "Reset the USB device having the specified device file (e.g., /dev/bus/usb/001/004)" >&2
    exit 1
fi

# Parse bus and device number from device file path
BUS=$(echo $1 | cut -f5 -d'/')
DEV=$(echo $1 | cut -f6 -d'/')

echo "Resetting USB device $1"
# Disable device
sudo sh -c "echo 0 > /sys/bus/usb/devices/${BUS}-${DEV}/authorized"
# Re-enable device
sudo sh -c "echo 1 > /sys/bus/usb/devices/${BUS}-${DEV}/authorized"

This script will try to disable and then re-enable a USB device, effectively resetting it (in some system). To find the device, you can use dmesg | grep -i usb when you plug and unplug the dongle.

You can test manually this proof of concepts by putting your dongle in the “bad” state and manually issue echo 0 > /sys/bus/usb/devices/${BUS}-${DEV}/authorized followed by echo 1 > /sys/bus/usb/devices/${BUS}-${DEV}/authorized. Replace the variables with the bus and device number.

If it works (I doubt it, but it is worth trying) then you can script it.

1 Like

I will try next week end or after vacation in september.

thanks you for the help