I have a WRTSL54GS, RC6 installed, and for some reason it won't sync up with my cable modem (Amit U10C003).  I have an older router, works fine.  I can power down the cable modem and plug my PowerBook in, bring it up, the PB works fine, so I know that plugging in something with a different MAC address will still get a DHCP address.

I plug the SL54 in, and the Internet light just blinks constantly, likewise the Ethernet light on the cable modem, and I never pick up an IP address.  I can bring up my old router, hook the SL54 into that, gets an IP just fine.  I've also taken it to work and it's gotten an IP on the office LAN no problem, so everything works separately, just for some reason not together.

The last thing I could think of was that the ports weren't syncing up because of a speed or duplex issue, but I can't find any way to set the WAN port's settings in OpenWRT.  I did try putting a hub between the cable modem and the SL54 to see if that helped, it didn't, and I really didn't expect that to work anyway.

Have you power cycled your cable modem in-between? Mediacom out here in Iowa will give you only the number of IPs you paid for based on mac addresses- if you power cycle, it gets reset and assigns to new device(s). Some cable providers might require you to register the mac on some sort of a 10.0* page.

(Last edited by Loconut1389 on 10 Nov 2006, 13:17)

Yes, the cable modem is getting power cycled.  I can plug anything else I have here in and get it up and running, no MAC registration is needed.  Only the SL54 isn't picking up an IP.

I may just try reflashing back to the factory firmware just to get OpenWRT out of the picture if nothing eles pops up in this thread today.

I'm more and more convinced that there is something going wrong with the autonegitiation between the router and the cable modem, causing the ports to flap.  I've found some similar threads here, but not much in the way of resolution:

http://forum.openwrt.org/viewtopic.php?id=3488

http://forum.openwrt.org/viewtopic.php?id=3301

I need to see if I can track down the mentioned robocfg utility...

Found and installed robocfg, I seemed to be able to enable and disable ports, but I was unable to change the port speed or duplex on the wan port.  Grrr...

sorry i didnt have more info. i hope you figure it out.

Ok, new info.  I reflashed back to the original Linksys firmware, plugged the router into the cable modem, restarted both, and I did in fact get a valid connection, surfed a few web pages to be sure, all looked good.  So, I flashed back to to RC6, let the router restart, and had no connection.

Interestingly, The OpenWrt Admin web page for LAN did show a correct DNS server listed from my cable provider (could that have been saved from NVRAM?) but it did not show a WAN address under the WAN tab (correctly set for DHCP).  So, something in RC6 is preventing a DHCP connection from taking place.  Now I'm really stumped...

Reverting to RC5 made no difference.

(Last edited by JimWright on 12 Nov 2006, 05:03)

You can check to see if a DNS server is configured in NVRAM by SSHing to the router and typing nvram show | grep dns.  If you see something there that you want to get rid of, you can use, for example nvram unset wan_dns && nvram commit.

At this point, I think it might be wise to sniff a few packets.  Get tcpdump installed on the unit - normally, this is as easy as ipkg install tcpdump but you might need to fiddle a bit more as this depends on an Internet connection.  SSH to the router and type ifdown wan.  Now, be sure you've got a clean slate by removing power from your cable modem, waiting a few seconds, and then plugging it back in.  Give it a minute or two to sync up.  While you're waiting, fire up tcpdump on the router: tcpdump -i eth1 -envvXs1536 port 67 or port 68.  (Replace eth1 with whatever nvram get wan_ifname tells you - I think this is eth1 on yours, but you should double-check.)  When your cable modem's synced up and ready to go, open another SSH connection to your router and type ifup wan.  Now you can watch tcpdump to see the DHCP packets on the interface you asked for - the ones traveling between your router and cable modem.  Is the router talking to the cable modem?  Is it getting any responses?

I did have that DNS address stuck in the NVRAM, I cleared that out before taking the next steps listed.

Taking the wan down then back up:

root@OpenWrt:~# ifdown wan
root@OpenWrt:~# ifup wan
info, udhcpc (v0.9.9-pre) started
debug, Sending discover...
root@OpenWrt:~# debug, Sending discover...
debug, Sending discover...
info, No lease, forking to background.

The tcpdump was quiet long, I'm not sure which bits there were relative to this issue:

root@OpenWrt:~# tcpdump -i eth1 -envvXs1536 port 67 or port 68
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 1536 bytes
16:56:02.740466 00:90:4c:60:00:2b > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl  64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:90:4c:60:00:2b, length: 548, xid:0xb963350f, flags: [none] (0x0000)
          Client Ethernet Address: 00:90:4c:60:00:2b
          Vendor-rfc1048:
            DHCP:DISCOVER
            CID:[ether]00:90:4c:60:00:2b
            VC:"udhcp 0.9.9-pre"
            PR:SM+DG+NS+HN+DN+BR

(hex code clipped)

16:56:07.432038 00:07:0d:ad:2c:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 354: (tos 0x0, ttl 255, id 49634, offset 0, flags [none], proto: UDP (17), length: 340) 10.34.32.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length: 312, xid:0x3b38e91e, flags: [Broadcast] (0x8000)
          Your IP: 70.112.122.13
          Gateway IP: 10.34.32.1
          Client Ethernet Address: 00:07:e9:e5:d6:ca
          Vendor-rfc1048:
            DHCP:OFFER
            SID:10.34.32.1
            LT:78196
            SM:255.255.252.0
            DN:"austin.rr.com"
            DG:70.112.120.1
            NS:24.93.41.125,24.93.41.126
            RD:Y

(more hex code clipped)

16:56:07.456820 00:07:0d:ad:2c:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 370: (tos 0x0, ttl 255, id 49649, offset 0, flags [none], proto: UDP (17), length: 356) 10.34.32.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length: 328, xid:0x3b38e91e, flags: [Broadcast] (0x8000)
          Your IP: 70.112.122.13
          Gateway IP: 10.34.32.1
          Client Ethernet Address: 00:07:e9:e5:d6:ca
          Vendor-rfc1048:
            DHCP:ACK
            SID:10.34.32.1
            LT:78196
            SM:255.255.252.0
            DN:"austin.rr.com"
            DG:70.112.120.1
            NS:24.93.41.125,24.93.41.126
            RD:Y
            FQDN:255/255/"LIGHTHOUSE."

(more hex clipped)

16:56:07.500017 00:07:0d:ad:2c:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 409: (tos 0x0, ttl 255, id 49703, offset 0, flags [none], proto: UDP (17), length: 395) 10.34.32.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length: 367, xid:0x11765d40, flags: [Broadcast] (0x8000)
          Your IP: 10.34.49.135
          Server IP: 24.93.40.160
          Gateway IP: 10.34.32.1
          Client Ethernet Address: 00:d0:59:fa:a2:76
          file "iselIP1BW1_1.bin@CiIxhwBCgIQ7PcQSurN84ASjUWpJjGpI"
          Vendor-rfc1048:
            DHCP:OFFER
            SID:24.93.41.130
            LT:522347
            SM:255.255.224.0
            TZ:0
            DG:10.34.32.1
            TS:24.93.40.160
            LOG:24.93.35.114
            T177:17455920,774909488,774921472
            BF:"iselIP1BW1_1.bin@CiIxhwBCgIQ7PcQSurN84ASjUWpJjGpI"

(clip)

          Your IP: 10.34.49.135
          Server IP: 24.93.40.160
          Gateway IP: 10.34.32.1
          Client Ethernet Address: 00:d0:59:fa:a2:76
          file "iselIP1BW1_1.bin@CiIxhyMXfLQDfpdnWobJeOKy67p4r17T"
          Vendor-rfc1048:
            DHCP:ACK
            SID:24.93.41.130
            LT:522347
            SM:255.255.224.0
            TZ:0
            DG:10.34.32.1
            TS:24.93.40.160
            LOG:24.93.35.114
            T177:17455920,774909488,774921472
            BF:"iselIP1BW1_1.bin@CiIxhyMXfLQDfpdnWobJeOKy67p4r17T"

Things went on in this manner for a while till I stopped the dump.  I'm not an expert, but I'm seeing DHCP offers, followed by ACKs, then another offer/ack, repeatedly.  Normally the IP picked up by my cable modem from RoadRunner is 70.123.x.x.

(Last edited by JimWright on 13 Nov 2006, 00:12)

Today's update...  Went down to the local Roadrunner office, picked up a new cable modem, brought it home and swapped out the old one, absolutely no change at all.  The WRTSL54GS still can't pick up a DHCP address while running OpenWRT.

There has to be some configuration option that's being set incorrectly from the original Linkys code...

After much more investigating tonight, I see that my dump above didn't include as much of the correct info as it should have, and the ACK that I was seeing apparently was going to another MAC address (correct MAC above is 00:90:4c:60:00:2b), and what I'm actually seeing is just repeated DISCOVER attempts, and nothing back.  This sounds very much like my packets are being discarded upstream, and I think I may have hit on the answer, this thread has the details:

http://forum.bsr-clan.de/ftopic8253-0-asc-15.html

Put simply, udhcp is creating too large of a packet, and my ISP looks to be restricting the packet size allowed for DHCP requests.  This would explain perfectly why the original Linksys firmware worked, but the OpenWRT code didn't.  I don't know what packet size Linksys sends by default (D-Link apparently sends 342 bytes), and as can be seen from the above dump my packet size is 590 bytes, and a cutoff of 576 bytes seems to be common, or at least common enough to be a concern.

The thread above documented a fix to the udhcp code, and mentioned a workaround for dd-wrt but I can't see how to apply that here.  I've submitted bug report #962 for this, hopefully it will be something that can be fixed without too much difficulty.

Can we get confirmation that this has been fixed? I've run into the exact same problem last night (getting endless "Sending discover ..." messages), although I have not done tcpdump yet, since it was late last night when I upgraded the router. I'm going to try resetting back to defaults and try configuring again, since a colleague of mine had this problem too and solved it that way. If that does not help, I can do the tcpdump, if it's going to help fix this problem.

I'm running RC6 on WRT54GL v1.1.

Thanks in advance!

(Last edited by Darkstone on 8 Mar 2007, 10:40)

I've tried resetting to defaults, but it didn't help. The moment I flashed the stock Linksys kernel, everything was OK again. I'm going to try upgrading to OpenWrt again and see what happens.

(added by edit)

I believe I figured out what the problem was. Somehow, my version of udhcpc was 0.9.9-pre, which obviously suffered from this problem. When flashing to latest X-Wrt image, version 1.4.0 was installed and everything was OK. Just FYI for anyone who might run into the same problem.

(Last edited by Darkstone on 8 Mar 2007, 20:30)

The Whiterussian releases are using Busybox 1.0, X-WRT and Kamikaze are using a later build which includes an improved udhcp routine.  It's possible to add the newer busybox to Whiterussian, but it's easier to just install the latest X-WRT build and go from there, until Kamikaze is ready for prime time.