Comfast CF-E385AC boot with LAN cable attached – no Rx packets

I have flashed my Comfast CF-E385AC with the latest stable and the latest snapshot releases and found both have a problem when booting with network cables attached. The OpenWrt based firmware provided by Comfast does not have this issue.

With the OpenWrt firmware there is no network connectivity after booting with Ethernet cables attached to either interface. I am using the default configuration for my tests but more complex configurations work well if booted with no cables attached. When cables are attached during boot wired interfaces do not respond when the process completes.

Investigating using the serial console and running ifconfig shows that packets are being sent out but the Rx data for all interfaces except loopback are 0. Checking the switch counters using swconfig shows that both Rx and Tx data is passing for the switch port connected to the interface. Modifying the network configuration and reloading does not correct the problem. Booted with or without cables attached, the router comes up normally from the serial console and the output of dmesg is identical.

Further investigation shows that if cables are attached before the U-boot code brings up the interface the problem occurs. If cables are attached immediately after the U-boot has passed this point in the startup sequence and before OpenWrt boot starts the interfaces work normally after booting completes. The U-Boot console output for a successful boot shows both eth0 and eth1 down (cables unplugged):

U-Boot 1.1.4-g93f29c3b-dirty (May 4 2018 - 11:10:12)

ap135 - Scorpion 1.0DRAM:

sri

Scorpion 1.0

ath_ddr_initial_config(233): (32bit) ddr1 init

tap = 0x00000002

Tap (low, high) = (0xaa55aa55, 0x0)

Tap values = (0x8, 0x8, 0x8, 0x8)

 4 MB

eth0 link down

FAIL

eth1 link down

FAIL

Using eth0 device

Tx Timed out

Tx Timed out

ping failed;

Hit any key to stop autoboot: 0

## Booting image at 9f050000 ...

If a cable is attached to a port (eth0 in this case) the U-Boot output shows this port being initialized. Once this occurs the router ports will not work after boot.

U-Boot 1.1.4-g93f29c3b-dirty (May 4 2018 - 11:10:12)

ap135 - Scorpion 1.0DRAM:

sri

Scorpion 1.0

ath_ddr_initial_config(233): (32bit) ddr1 init

tap = 0x00000002

Tap (low, high) = (0xaa55aa55, 0x0)

Tap values = (0x8, 0x8, 0x8, 0x8)

 4 MB

eth0 up

athrs17_reg_init_wan done

SGMII in forced mode

athr_gmac_sgmii_setup SGMII done

: cfg1 0x800c0000 cfg2 0x7214

eth1: 20:0d:b0:70:87:c2

eth1 up

Setting 0x18116290 to 0x60c0214f

eth0 link down

FAIL

dup 1 speed 1000

Using eth1 device

ping failed;

Hit any key to stop autoboot: 0

## Booting image at 9f050000 ...

My assumption is that some initialization from the U-Boot code remains during the OpenWrt boot and causes this issue.

I need some advice and help on this as I'm now at the point were code changes are likely needed to fix this issue. Where would be the best place in the code to investigate and add additional initialization if needed?

I am facing the same issue. Did you managed to solve this problem?

I don't have this device, I have other Comfast devices.
I remember that some model when you flash openwrt, the lan and wan port reverse resulting in wan as lan

It does not matter where you plug in the cable if it boots with an active connection you will not reach it over Ethernet (WAN or LAN port). But it is possible to connect to it via WiFi.

did you managed to fix this?

I just install openwrt 19.07.4 on my CF-E385AC and I'm having the same problem.

Also, does anyone know if this router has been ported to ath79?

I managed to have it working in the following way:

  • deleted WAN and WAN6 interfaces
  • bridge the eth1.2 in LAN
  • restart the router and connect to it using the "WAN" port intead

hope this helps

I too encounter this issue. If booting with the the LAN ethernet connected, I do observe an arp packet for 192.16.1.10 and a TFTP request coming out of its LAN port (if there is some machine at 192.168.1.10), but after that, no further packets come from the LAN port, and the 192.168.1.1 is unreachable. I've seen the issue with both of these firmware versions: openwrt-19.07.3-ar71xx-generic-cf-e385ac-squashfs-sysupgrade and openwrt-19.07.4-ar71xx-generic-cf-e385ac-squashfs-sysupgrade.

If anyone has pointers for how to try to do to resolve this, I do have a working serial console access, and an unmodified second router of the same type.

Fixed in 19.07.7

1 Like

I still have this issue in 19.07.7, both on a clean install on a brand new device, and on a device upgraded from 19.07.04.