OpenWrt Forum Archive

Topic: Built Kamikaze, no WAN DHCP?

The content of this topic has been archived on 23 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I've taken my first steps into the new world of Kamikaze...  Built the latest and greatest under Ubuntu (on my MacBook Pro) and left all the default options as they were, 2.4 kernel, all packages built, etc.  Flashed the created image to my WRTSL54GS and it rebooted fine, serial console showed that the router was up and running, but no IP was being picked up via the WAN connection, which had the default setting for DHCP.

Under RC5/6, my router was picking up an address just fine hanging off my existing home network, and I'm a bit stumped on where to look to see what might have gone wrong.  I did verify that udhcpc was active, and tried ifwan down/up without success.

Could you post your network config file?

root@OpenWrt:/etc/config# cat network
#### VLAN configuration
config switch eth0
        option vlan0    "0 1 2 3 5*"
        option vlan1    "4 5"


#### Loopback configuration
config interface loopback
        option ifname   "lo"
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0


#### LAN configuration
config interface lan
        option type     bridge
        option ifname   "eth0.0"
        option proto    static
        option ipaddr   192.168.1.1
        option netmask  255.255.255.0


#### WAN configuration
config interface        wan
        option ifname   "eth0.1"
        option proto    dhcp

That is interesting. I am having the same problem but I believed that it was because of the 2.6 kernel. The network was ok with White Russian RC6, but fails in the compiled Kamikaze.

Can you try to set an static address and ping from another computer?

I have this same problem after updating a long neglected box to the current head. The interface comes up, and I can sniff on it with tcpdump and see traffic, but no packets go out. Even if I configure the interface manually I get nothing out.

There are some messages in the kernel logs about PHY trouble...

...
BFL_ENETADM not set in boardflags. Use force=1 to ignore.
Probing device eth1: [/home/jim/openwrt/trunk/build_mipsel/linux-2.6-brcm47xx/kmod-switch/switch-robo.c:91] SIOCGETCPHYRD failed!
[/home/jim/openwrt/trunk/build_mipsel/linux-2.6-brcm47xx/kmod-switch/switch-robo.c:91] SIOCGETCPHYRD failed!
No Robo switch in managed mode found
...
BFL_ENETADM not set in boardflags. Use force=1 to ignore.
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth1: PHY Reset would not complete.
...

There is no switch on the WAN port, as I understand the wrtsl54gs, though that message comes up for eth0 as well.

We have the same problem. I see this is dmesg:

2.4 White Russian:

Probing device eth0: found!
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
mini_fo: using base directory: /
mini_fo: using storage directory: /tmp/root
jffs2.bbc: SIZE compression mode activated.
PCI: Setting latency timer of device 01:01.0 to 64
PCI: Enabling device 01:01.0 (0004 -> 0006)
eth2: Broadcom BCM4318 802.11 Wireless Controller 3.90.37.0
BFL_ENETADM not set in boardflags. Use force=1 to ignore.
device eth0 entered promiscuous mode
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
device eth2 entered promiscuous mode
br0: port 2(eth2) entering learning state
br0: port 1(eth0) entering learning state
br0: port 2(eth2) entering forwarding state
br0: topology change detected, propagating
br0: port 1(eth0) entering forwarding state
br0: topology change detected, propagating
b44: eth1: Link is up at 100 Mbps, full duplex.
b44: eth1: Flow control is off for TX and off for RX.

2.6 Kamikaze

Probing device eth0: [/usr/src/buildslave/buildroot-ng-brcm47xx-2.6/build/build_mipsel/linux-2.6-brcm47xx/kmod-switch/switch-robo.c:91] SIOC
GETCPHYRD failed!
[/usr/src/buildslave/buildroot-ng-brcm47xx-2.6/build/build_mipsel/linux-2.6-brcm47xx/kmod-switch/switch-robo.c:91] SIOCGETCPHYRD failed!
No Robo switch in managed mode found
Probing device eth1: [/usr/src/buildslave/buildroot-ng-brcm47xx-2.6/build/build_mipsel/linux-2.6-brcm47xx/kmod-switch/switch-robo.c:91] SIOC
GETCPHYRD failed!
[/usr/src/buildslave/buildroot-ng-brcm47xx-2.6/build/build_mipsel/linux-2.6-brcm47xx/kmod-switch/switch-robo.c:91] SIOCGETCPHYRD failed!
No Robo switch in managed mode found
Probing device eth2: No such device
Probing device eth3: No such device
BFL_ENETADM not set in boardflags. Use force=1 to ignore.
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
mini_fo: using base directory: /
mini_fo: using storage directory: /jffs
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth1: PHY Reset would not complete.
Probing device eth0: found!
BFL_ENETADM not set in boardflags. Use force=1 to ignore.

I will try a kamikaze with kernel 2.4 tomorrow. If the bug is present then I will try to debug the kamikaze init scripts....

P.S.: is there a way to attach a file is this forum?

I have the same problem with the current snapshot.

My Belkin F5D7231-4P always fails to pick up an WAN IP address. I previously installed Whiterussian 0.9 on the router and never had this problem. I have also seen the same problem on a Buffalo WHR-G54S, so the issue seems to be a bug or compatibility.

Can anyone suggest a fix ?

Thanks,
Kebab

Also I have the same problem in RT210w use the Kamikaze  r6226  WAN static or dhcp can't have communication with LAN
Trying to find it!
James

I have this problem on my WRTSL54GS, but only with the 2.6 kernel.  2.4 works fine.  This is with Kamikaze 7.06, released today.

The lights look fine on both ends of the connection.  If I plug it into my laptop, running a DHCP server, it never sees a request.  tcpdump shows nothing at all.

I get:

OpenWrt user.err kernel: b44: eth1: PHY Reset would not complete.

in the log.

Here is the relevant portion of the log:

Jan  1 00:00:13 OpenWrt user.info kernel: b44: eth0: Link is up at 100 Mbps, full duplex.
Jan  1 00:00:13 OpenWrt user.info kernel: b44: eth0: Flow control is off for TX and off for RX.
Jan  1 00:00:13 OpenWrt user.warn kernel: Probing device eth0: found!
Jan  1 00:00:13 OpenWrt user.info kernel: mini_fo: using base directory: /
Jan  1 00:00:13 OpenWrt user.info kernel: mini_fo: using storage directory: /tmp/root
Jan  1 00:00:15 OpenWrt user.info kernel: b44: eth0: Link is up at 100 Mbps, full duplex.
Jan  1 00:00:15 OpenWrt user.info kernel: b44: eth0: Flow control is off for TX and off for RX.
Jan  1 00:00:15 OpenWrt user.info kernel: device eth0 entered promiscuous mode
Jan  1 00:00:16 OpenWrt user.info kernel: device eth0 left promiscuous mode
Jan  1 00:00:16 OpenWrt user.info kernel: br-lan: port 1(eth0) entering disabled state
Jan  1 00:00:16 OpenWrt user.err kernel: b44: eth1: PHY Reset would not complete.
Jan  1 00:00:16 OpenWrt user.info kernel: b44: eth0: Link is up at 100 Mbps, full duplex.
Jan  1 00:00:16 OpenWrt user.info kernel: b44: eth0: Flow control is off for TX and off for RX.
Jan  1 00:00:16 OpenWrt user.info kernel: device eth0 entered promiscuous mode
Jan  1 00:00:16 OpenWrt user.info : udhcpc (v1.4.2) started
Jan  1 00:00:17 OpenWrt user.info : Sending discover...
Jan  1 00:00:18 OpenWrt user.err kernel: b44: eth1: PHY Reset would not complete.
Jan  1 00:00:18 OpenWrt user.warn kernel: BFL_ENETADM not set in boardflags. Use force=1 to ignore.
Jan  1 00:00:19 OpenWrt user.info kernel: PPP generic driver version 2.4.2
Jan  1 00:00:19 OpenWrt user.info kernel: br-lan: port 1(eth0) entering learning state
Jan  1 00:00:19 OpenWrt user.info kernel: br-lan: topology change detected, propagating
Jan  1 00:00:19 OpenWrt user.info kernel: br-lan: port 1(eth0) entering forwarding state
Jan  1 00:00:20 OpenWrt user.info kernel: wlan: 0.8.4.2 (0.9.2.1)
Jan  1 00:00:20 OpenWrt user.info : Sending discover...
Jan  1 00:00:20 OpenWrt user.warn kernel: ath_hal: module license 'Proprietary' taints kernel.
Jan  1 00:00:20 OpenWrt user.info kernel: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, REGOPS_FUNC)
Jan  1 00:00:20 OpenWrt user.info kernel: ath_rate_sample: 1.2 (0.9.2.1)
Jan  1 00:00:20 OpenWrt user.info kernel: wlan: mac acl policy registered
Jan  1 00:00:21 OpenWrt user.info kernel: ath_pci: 0.9.4.5 (0.9.2.1)
Jan  1 00:00:23 OpenWrt user.info : Sending discover...
Jan  1 00:00:23 OpenWrt cron.notice crond[1221]: crond 2.3.2 dillon, started, log level 8
Jan  1 00:00:26 OpenWrt user.info : Sending discover...
Jan  1 00:00:29 OpenWrt user.info : Sending discover...

I posted a fix to this in another thread...
  http://forum.openwrt.org/viewtopic.php?id=10528

It may not be the right fix, but it works and it shines a light directly on the problem for anyone that has datasheets to do the right fix.

I haven't checked this with the 2.6.21 kernel, only 2.6.19. I'm away from my test rigs for a couple weeks can't check.

The discussion might have continued from here.