[Solved] Udhcpc does not work correctly

I am suffering from constant internet connection failure. I noticed after updating the firmware with Kernel 5.4. I have an Archer C60.


1 Like

I do not see any issue with udhcpc in those logs...

What I see is an ethernet connection going down and back up. That looks like a bug in the drivers, a damaged wire, or an issue on the device at the other end of the wire.

2 Likes

If it's from the drivers, it may be an OpenWrt problem. At no time did the device and cable move. At the other end of the cable is a cable modem and I don't think that's the problem.

In that case, you might want to change the subject of this post, or even open a bug report.

1 Like

I can confirm the same issue on GL-iNet AR300M hardware. I have a number of these on a project and all are the same (snapshot). First noticed on kernel 4.19.108.
I suspect a bug somewhere in ath9k drivers as it does not happen on the GL-iNet AR750S that uses ath10k.
It happens only on eth1 (wan), not on eth0.

Does the C60 use ath9k?

Yes, use ath9k and ath10k. I even have to manually restart the eth1 interface because it stops completely. But I wonder what that has to do with the problem.

also seen some odd behavior for ~3months... not 100% of the cause but udhcpc is high on my list... don't get interface flapping ( actually there is zero output at all ) so probably not the same issue... ( ath10 device )...

the odd thing is... in my case, rpi4 has no issues... so that either excludes dhcp or highlights some other odd interaction with certain chipsets / drivers... don't really run wireless on that device tho'.... ( armhf )

I'm pretty sure ath9k provides the ethernet and 2GHz drivers with ath10k providing 5GHz for the chipsets in these devices.
I have tried various ath79 devices and it seems that any using ath9k show the problem at least as far as I can see up to now. (ar300m, ar750m, ub nanostation-m and ub bullet-m and now C60)
My current guess is a bug in ath9k.......

I understand that ath9k is Wi-Fi only. I also see the two bands falling.

I assumed (possibly incorrectly) that both ath9k and ath10 contain ethernet drivers as well as wireless, which one provides ethernet depends on the SoC in use.
If this is not the case then where is the Qualcom ethernet driver? I don't see anything that looks like separate ethernet drivers in the manifest.
Any ideas on the driver package if it is separate?

This is what I have installed and I do not identify anything similar with Ethernet. Will it be in the kernel?

root@archer_c60:~# opkg list-installed
ath10k-firmware-qca9888-ct - 2020-04-24-2
base-files - 223-r13885-211548c523
busybox - 1.31.1-1
cgi-io - 19
ddns-scripts - 2.7.8-21
dnsmasq - 2.81-3
dropbear - 2020.80-1
firewall - 2019-11-22-8174814a-1
fstools - 2020-06-17-d34ea8eb-1
fwtool - 2019-11-12-8f7fe925-1
getrandom - 2019-12-31-0e34af14-4
hostapd-common - 2020-06-08-5a8b3662-2
htop - 2.2.0-3
ip-tiny - 5.7.0-2
ip6tables - 1.8.4-1
iperf3 - 3.7-1
iptables - 1.8.4-1
iptables-mod-conntrack-extra - 1.8.4-1
iptables-mod-ipopt - 1.8.4-1
iw - 5.4-1
iwinfo - 2020-06-03-2faa20e5-1
jshn - 2020-07-11-f4e9bf73-1
jsonfilter - 2018-02-04-c7e938d6-1
kernel - 5.4.52-1-64095d874e0e2dc8a8e279065e16e4cc
kmod-ath - 5.4.52+5.7-rc3-1-2
kmod-ath10k-ct-smallbuffers - 5.4.52+2020-06-30-edfbf916-1
kmod-ath9k - 5.4.52+5.7-rc3-1-2
kmod-ath9k-common - 5.4.52+5.7-rc3-1-2
kmod-cfg80211 - 5.4.52+5.7-rc3-1-2
kmod-gpio-button-hotplug - 5.4.52-3
kmod-hwmon-core - 5.4.52-1
kmod-ifb - 5.4.52-1
kmod-ip6tables - 5.4.52-1
kmod-ipt-conntrack - 5.4.52-1
kmod-ipt-conntrack-extra - 5.4.52-1
kmod-ipt-core - 5.4.52-1
kmod-ipt-ipopt - 5.4.52-1
kmod-ipt-nat - 5.4.52-1
kmod-ipt-offload - 5.4.52-1
kmod-ipt-raw - 5.4.52-1
kmod-ledtrig-default-on - 5.4.52-1
kmod-ledtrig-heartbeat - 5.4.52-1
kmod-ledtrig-netdev - 5.4.52-1
kmod-ledtrig-timer - 5.4.52-1
kmod-lib-crc-ccitt - 5.4.52-1
kmod-mac80211 - 5.4.52+5.7-rc3-1-2
kmod-nf-conntrack - 5.4.52-1
kmod-nf-conntrack6 - 5.4.52-1
kmod-nf-flow - 5.4.52-1
kmod-nf-ipt - 5.4.52-1
kmod-nf-ipt6 - 5.4.52-1
kmod-nf-nat - 5.4.52-1
kmod-nf-reject - 5.4.52-1
kmod-nf-reject6 - 5.4.52-1
kmod-ppp - 5.4.52-1
kmod-pppoe - 5.4.52-1
kmod-pppox - 5.4.52-1
kmod-sched-cake - 5.4.52-1
kmod-sched-cake-virtual - 5.4.52+2020-01-10-aeff7a3e-1
kmod-sched-core - 5.4.52-1
kmod-slhc - 5.4.52-1
kmod-udptunnel4 - 5.4.52-1
kmod-udptunnel6 - 5.4.52-1
kmod-wireguard - 5.4.52+1.0.20200712-1
libblobmsg-json - 2020-07-11-f4e9bf73-1
libc - 1.1.24-2
libelf1 - 0.179-1
libgcc1 - 8.4.0-2
libip4tc2 - 1.8.4-1
libip6tc2 - 1.8.4-1
libiwinfo-lua - 2020-06-03-2faa20e5-1
libiwinfo20200105 - 2020-06-03-2faa20e5-1
libjson-c5 - 0.14-1
libjson-script - 2020-07-11-f4e9bf73-1
liblua5.1.5 - 5.1.5-7
liblucihttp-lua - 2019-07-05-a34a17d5-1
liblucihttp0 - 2019-07-05-a34a17d5-1
libmbedtls12 - 2.16.6-1
libncurses6 - 6.2-1
libnl-tiny - 2019-10-29-0219008c-1
libpthread - 1.1.24-2
libubox20191228 - 2020-07-11-f4e9bf73-1
libubus-lua - 2020-02-05-171469e3-1
libubus20191227 - 2020-02-05-171469e3-1
libuci20130104 - 2020-04-24-ec8d3233-3
libuclient20160123 - 2020-06-17-c6609861-1
libustream-mbedtls20200215 - 2020-03-13-5e1bc342-1
libxtables12 - 1.8.4-1
logd - 2019-12-31-0e34af14-4
lua - 5.1.5-7
luci - git-20.201.64156-3b2a1e9
luci-app-ddns - git-20.201.64156-3b2a1e9
luci-app-firewall - git-20.201.64156-3b2a1e9
luci-app-opkg - git-20.201.64156-3b2a1e9
luci-app-sqm - 1.4.0
luci-app-wireguard - git-20.201.64156-3b2a1e9
luci-base - git-20.201.64156-3b2a1e9
luci-compat - git-20.201.64156-3b2a1e9
luci-i18n-base-en - git-20.201.64156-3b2a1e9
luci-i18n-base-es - git-20.201.64156-3b2a1e9
luci-i18n-ddns-en - git-20.201.64156-3b2a1e9
luci-i18n-ddns-es - git-20.201.64156-3b2a1e9
luci-i18n-firewall-en - git-20.201.64156-3b2a1e9
luci-i18n-firewall-es - git-20.201.64156-3b2a1e9
luci-i18n-opkg-en - git-20.201.64156-3b2a1e9
luci-i18n-opkg-es - git-20.201.64156-3b2a1e9
luci-i18n-sqm-en - git-20.201.64156-3b2a1e9
luci-i18n-sqm-es - git-20.201.64156-3b2a1e9
luci-i18n-wireguard-en - git-20.201.64156-3b2a1e9
luci-i18n-wireguard-es - git-20.201.64156-3b2a1e9
luci-lib-ip - git-20.201.64156-3b2a1e9
luci-lib-ipkg - git-20.201.64156-3b2a1e9
luci-lib-jsonc - git-20.201.64156-3b2a1e9
luci-lib-nixio - git-20.201.64156-3b2a1e9
luci-mod-admin-full - git-20.201.64156-3b2a1e9
luci-mod-network - git-20.201.64156-3b2a1e9
luci-mod-status - git-20.201.64156-3b2a1e9
luci-mod-system - git-20.201.64156-3b2a1e9
luci-proto-ipv6 - git-20.201.64156-3b2a1e9
luci-proto-ppp - git-20.201.64156-3b2a1e9
luci-proto-wireguard - git-20.201.64156-3b2a1e9
luci-ssl - git-20.201.64156-3b2a1e9
luci-theme-bootstrap - git-20.201.64156-3b2a1e9
luci-theme-openwrt-2020 - git-20.201.64156-3b2a1e9
mtd - 25
nano - 4.9.3-1
netifd - 2020-06-06-51e9fb81-1
odhcp6c - 2020-03-28-f575351c-16
odhcpd-ipv6only - 2020-06-21-5da52992-4
openwrt-keyring - 2019-07-25-8080ef34-1
opkg - 2020-05-07-f2166a89-1
ppp - 2.4.8.git-2020-05-25-2
ppp-mod-pppoe - 2.4.8.git-2020-05-25-2
procd - 2020-07-19-76adac5e-1
px5g-mbedtls - 9
rpcd - 2020-05-26-078bb57e-1
rpcd-mod-file - 2020-05-26-078bb57e-1
rpcd-mod-iwinfo - 2020-05-26-078bb57e-1
rpcd-mod-luci - 20191114
rpcd-mod-rrdns - 20170710
sqm-scripts - 1.4.0-8
swconfig - 12
tc - 5.7.0-2
terminfo - 6.2-1
uboot-envtools - 2020.04-1
ubox - 2019-12-31-0e34af14-4
ubus - 2020-02-05-171469e3-1
ubusd - 2020-02-05-171469e3-1
uci - 2020-04-24-ec8d3233-3
uclient-fetch - 2020-06-17-c6609861-1
uhttpd - 2020-06-03-939c281c-1
uhttpd-mod-ubus - 2020-06-03-939c281c-1
urandom-seed - 2
urngd - 2020-01-21-c7f7b6b6-1
usign - 2020-05-23-f1f65026-1
wireguard-tools - 1.0.20200513-1
wireless-regdb - 2020.04.29-1
wpad-basic - 2020-06-08-5a8b3662-2
zlib - 1.2.11-3

On an ar300m I removed ath9k and as expected the wireless wireless went with it. Ethernet still working though so you are I think correct, the ethernet driver is most likely in the kernel.
I'll try another with a static ip to eliminate udhcp (or not!)

@castillofrancodamian
Ok, that is set up with a static ip. I'll leave it to run overnight and see what happens.

10 hours with static ip and no problems yet.
With respect to ethernet drivers - extract from dmesg:

[    1.625479] libphy: ar8xxx-mdio: probed
[    1.638395] switch0: Atheros AR8229 rev. 1 switch registered on mdio.0
[    1.683099] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000, driver=Generic PHY]
[    1.693091] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[    1.701729] NET: Registered protocol family 10
[    1.711704] Segment Routing with IPv6
[    1.715653] NET: Registered protocol family 17
[    1.720351] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[    1.733751] 8021q: 802.1Q VLAN Support v1.8
[    2.057656] ag71xx 19000000.eth: connected to PHY at mdio.0:1f:04 [uid=004dd042, driver=Generic PHY]
[    2.068090] eth1: Atheros AG71xx at 0xb9000000, irq 4, mode: mii

Edit: Later that day :wink:
With udhcp running:

logread | grep "eth1: link down"
Thu Jul 23 11:22:28 2020 kern.info kernel: [ 6663.519296] eth1: link down
Thu Jul 23 12:31:24 2020 kern.info kernel: [10799.461414] eth1: link down
Thu Jul 23 13:12:28 2020 kern.info kernel: [13264.237097] eth1: link down
Thu Jul 23 13:28:08 2020 kern.info kernel: [14204.272128] eth1: link down
Thu Jul 23 15:06:57 2020 kern.info kernel: [20133.251404] eth1: link down
Thu Jul 23 16:25:53 2020 kern.info kernel: [24869.268091] eth1: link down
Thu Jul 23 17:08:22 2020 kern.info kernel: [27418.013317] eth1: link down
Thu Jul 23 17:55:55 2020 kern.info kernel: [30270.888871] eth1: link down
Thu Jul 23 18:18:29 2020 kern.info kernel: [31624.621165] eth1: link down
Thu Jul 23 18:55:12 2020 kern.info kernel: [33828.277624] eth1: link down
Thu Jul 23 18:56:24 2020 kern.info kernel: [33899.957927] eth1: link down
root@archer_c60:~# dmesg
[    1.383251] switch0: Atheros AR8229 rev. 1 switch registered on mdio.0
[    1.443477] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000, driver=Generic PHY]
[    1.453344] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[    1.459866] i2c /dev entries driver
[    1.465777] NET: Registered protocol family 10
[    1.475799] Segment Routing with IPv6
[    1.479747] NET: Registered protocol family 17
[    1.484422] 8021q: 802.1Q VLAN Support v1.8
[  120.578050] eth1: link down
[  122.786093] eth1: link up (100Mbps/Full duplex)
[  122.791163] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  532.380057] eth1: link down
[  535.099793] eth1: link up (100Mbps/Full duplex)
[  535.104854] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  598.619171] eth1: link down
[  600.827716] eth1: link up (100Mbps/Full duplex)
[  600.833008] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 1156.851721] eth1: link down
[ 1159.060387] eth1: link up (100Mbps/Full duplex)
[ 1159.065321] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 1164.180131] eth1: link down
[ 1166.388407] eth1: link up (100Mbps/Full duplex)
[ 1166.393920] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

Common factor....... some sort of interaction between the driver and dhcp client.

I don't get the issue with a GL-ar750s. I'll boot one up and see what it is running

@castillofrancodamian
And on the 750S:

[    1.260238] libphy: ag71xx_mdio: probed
[    1.267297] switch0: Atheros AR8337 rev. 2 switch registered on mdio.0
[    1.855301] ag71xx 19000000.eth: connected to PHY at mdio.0:00 [uid=004dd036, driver=Atheros AR8216/AR8236/AR8316]
[    1.866587] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: mii

So different driver here.

What version of Kernel do you use on those devices? Maybe it's a patch problem or something.

First noticed on kernel 4.19.108 and still a problem now as far as I know.

I started noticing when upgrading to Kernel 5.4.