WAN DHCP and MAC address Issue - can't get address!

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Author Message
TheScotsman
DD-WRT Novice


Joined: 09 Dec 2016
Posts: 22

PostPosted: Mon Aug 17, 2020 21:09    Post subject: WAN DHCP and MAC address Issue - can't get address! Reply with quote
I'm running r43516 on an ASUS RT-AC5300. When I was doing my initial config and testing, I noticed something very odd: the MAC addresses for the WAN and for the Wireless were set to 00:00:00:00:00:01 and 00:00:00:00:00:02! MAC cloning wasn't turned on; but when I enabled it to test with, it did have those two values (granted, it may have READ them and populated the fields, similar to what the static IP fields do if you toggle to static from DHCP). I worked out what looks like the pattern for MAC addresses on the AC5300 and am currently using MAC cloning to set those. Not a show-stopper by any stretch, but thought I'd mention it.

Worse issue: I can't seem to reliably obtain a WAN IP via DHCP. I ran into this issue when using an Xfinity XB6 cable router - most of the time DD-WRT wouldn't pick up an address. I did notice, however, that changing the WAN MAC address on DD-WRT and applying would generally make it pick right up. Just doing DHCP Release/Renew in the UI did NOT work. Since I was always getting the same address (and my last Comcast address was stable across years), I just configured for Static IP and forgot about it. Thought perhaps it was XFi being weird (given all the other gorp they pour into those routers) so didn't think much of it or post on it - my mistake.

Because the XFi XB6 looked like it was being unreliable, I just replaced it with a Netgear CM1150V. In a day's testing trying to troubleshoot the cable-side issues that led to me buying it in the first place, it's received at least 4 different IP addresses from Comcast. And that's when the DHCP problem on the DD-WRT came right back to the top - it took a while for me to remember the issue, the symptom of course was that DD-WRT wouldn't pickup an address (and I HAD remembered to switch it back to DHCP from static). Turns out it wasn't XFi weirdness, it was DD-WRT all along.

I can work around it by changing the MAC address by a digit and applying the change in the UI. Obviously not ideal, but it'll work now that I know about it.

1) Anyone seen this problem and know of a fix for it?
2) Absent a permanent fix, is there anyway via script that I can mimic the UI actions (i.e. change the MAC by a digit, then trigger whatever other actions occur when "Apply Changes" happens on the MAC Cloning page)?

Many thanks!
Sponsor
Wildlion
DD-WRT Guru


Joined: 24 May 2016
Posts: 1407

PostPosted: Mon Aug 17, 2020 22:47    Post subject: Reply with quote
My initial reaction is:

Did you do a nvram reset? Normally that can help clear errors on configurations.

I am surprised that the MAC addresses are showing up bad, those are read from the hardware.

I know that the cable modems/accounts sometimes have limits for number of allocated ips based on MAC addresses. They also have dhcp enabled and there are time limits, so unless I read wrong you said that you were wanting to do a dhcp release/renew but you were getting the same ip address. That makes perfect sense. If I remember the directions correctly, they say to unplug the cable modem or machine overnight (8 hours) that should clear it from teh networks dhcp history.

The actions you describe are very script-able
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14125
Location: Texas, USA

PostPosted: Mon Aug 17, 2020 23:46    Post subject: Reply with quote
Power down your upstream modem and the 5300. Let it sit for a few minutes. Power up modem and wait until it syncs. Power up router. It's probably that nonsense of your modem holding your old router's MAC. Used to, you had to contact the ISP and go through a bunch of horse hockey to get it fixed.
_________________
"Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT
Pogo - A minimal level of ability is expected and needed...
DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)

----------------------
Linux User #377467 counter.li.org / linuxcounter.net
TheScotsman
DD-WRT Novice


Joined: 09 Dec 2016
Posts: 22

PostPosted: Tue Aug 18, 2020 1:23    Post subject: Reply with quote
Thanks guys - Wildlion, I did do an NVRAM reset when I installed DD-WRT on the AC5300. It was a brand new installation on a factor-fresh unit so I wasn't sure it was necessary, but I didn't want take any chances. I wonder if it glitched because of the network layout of the AC5300 - the WAN port is vlan2, not one of the ethx ports, so perhaps it didn't know what to actually read ...? Doesn't explain the wireless though - although with eth1 (2.4Ghz) and eth2 (5Ghz) both bridged maybe it couldn't read those right either. I'll save the config and do some playing around, maybe I can find a pattern.

I tried the power down/up sequence you suggested kernel-panic69, but it doesn't seem to work - I suspect you're right that it's holding the old MAC. What's odd (to Wildlion's response) is that it did exactly the same thing with the Comcast-provided XB6 (which is a modem/router/wifi combo, serves up internal addresses via DHCP direct off the box) and with the Netgear CM1150V (which is a true cable modem and presents just the ISP-issued IP address). Since they're two vastly different devices but the behavior is the same, I assumed (maybe incorrectly) that my DD-WRT AC5300 is where the fault is.

It's vexing because a modem reboot (as when troubleshooting their spotty connectivity) blows me up if the WAN IP changes, and a router reboot on the AC5300 also blows me up because it won't even pickup its prior address again. In either case it seems I need to nudge the MAC to a new value to force IP assignment.

I think ifconfig vlan2 up hw ether xx:xx:xx:xx:xx:xx dynamic would be the right command to give it a new MAC and bring it up to pull a new DHCP address when this happens ...? Will give it a try the next time it hiccups.
Wildlion
DD-WRT Guru


Joined: 24 May 2016
Posts: 1407

PostPosted: Tue Aug 18, 2020 23:19    Post subject: Reply with quote
THat is weird. I know that sometimes after the initial flash that there can be some initial errors, and I have found that even after a while nvram can get corrupted. So it was just a thought....


Is there any way to isolate the two things? For example having the router on its own and see if everything is okay and if the modem would hand out fine to a computer or a different router?

VLAN 2 on the WAN I think is default and the LAN is VLAN 1.

Do know that the Comcast does configure the modems remotely, if i remember it is done on boot up the modem effectively looks for tftp server to get its config, so it could be how comcast configures and a settings interaction. I am not on comcast so YMMV

edit: corrected typo, LAN is VLAN 1


Last edited by Wildlion on Wed Aug 19, 2020 20:52; edited 1 time in total
TheScotsman
DD-WRT Novice


Joined: 09 Dec 2016
Posts: 22

PostPosted: Wed Aug 19, 2020 17:18    Post subject: Reply with quote
I'll try doing some more testing on it ... so far what I've seen is that both cable modems (the old XB6 and the new CM1150V) were issuing a DHCP address fine if I connect a computer directly. Prior to the AC5300 I had an Asus RT-N66U running (if my notes are right) DD-WRT v3.0-r43381 big (06/10/20) that picked up an address fine from the XB6 - I haven't tested it with the CM1150V, but I do still have it here and configured so I can play around if the family will tolerate some more network downtime!

For now everything seems to be in a state of stable detente - my Comcast connection has stability and speed issues that we're working through, and it's required several reboots of the CM1150V. So far the AC5300 has picked up its address everytime (or retained the old one, it hasn't changed); a reboot of the AC5300 yesterday also went OK. Maybe it was just a glitch during Comcast's initial activation of the modem ...
TheScotsman
DD-WRT Novice


Joined: 09 Dec 2016
Posts: 22

PostPosted: Fri Apr 23, 2021 14:26    Post subject: Reply with quote
Reopening this thread as I have more info and also a workaround, but would like to try to find the root cause. Post might be a bit caffeine fueled, it's been a few late nights!

To recap the key points, after replacing an ASUS RT-N66U (running build r43381) with an ASUS RT-AC5300 (running build r43516), I was having difficulties getting the AC5300 to pickup a DHCP address. It would often take some finagling of powering everything down, then up, and sometimes switching WAN modes and/or MAC addresses on the AC5300 to get it to finally pick up a WAN address. Since Comcast (ISP) and the AC5300 were reasonably stable otherwise, I just lived with it. I'd also replaced Comcast's home gateway (modem/router/wifi-in-one) with my own cable modem (a Netgear CM1150V), and wasn't 100% sure DD-WRT was the problem anyway.

Cue Comcast having a service outage, and once they were back I could NOT get the AC5300 back online, and actually managed to brick it in the process (tale for another time, but thank you DD-WRT forum folks, posts you'd already made helped me get it back to life, reset to factory firmware and settings, and then back on DD-WRT - thank you!). While the AC5300 was bricked, I dropped my old N66U back into service and hand-configured it to mostly match the AC5300's settings so the family wouldn't kill me for lack of internet - and damn if it didn't do the exact same thing of being a pain in the ass about getting a DHCP address. Now I was sure it was the ISP or cable modem causing the issue, right? (Narrator: It was not, in fact, the ISP or cable modem.)

Once the AC5300 was back in service, I built an inline sniffer with a Raspberry Pi 4 and an extra USB 1G ethernet adapter (damn handy, wish I'd done this before) and captured a bunch of traces of traffic in different configurations so that I could try to see what was different in the failing scenario vs. when it finally worked - one thing that stood out was that when failing it appeared the DD-WRT devices weren't soliciting a DHCP address.

Cue a breakthrough - while setup with the AC5300 actually working, and the N66U as a client of it (on different address ranges of course) and NOT getting an IP, I noticed that on the (working) AC5300 udhcpc was running; but on the (not working) N66U it was not. Additionally, the link of /tmp/udhcpc to /sbin/rc was also missing.

Running the following immediately got the N66U back up and running:
Code:
ln -s /sbin/rc /tmp/udhcpc
udhcpc -i vlan2 -p /var/run/udhcpc.pid -s /tmp/udhcpc -O routes -O msstaticroutes -O staticroutes -H ASUSN66U --background


Further testing on both routers showed that whenever they were failing to connect, udhcpc wasn't running and /tmp/udhcpc was missing.

My workaround at the moment - I have a script to manually setup and start udhcpc if it seems to be missing; it's badly named because this isn't really a restart, but whatever:

Code:

#!/bin/sh
# wanrestart - complete restart trigger on the WAN interface (vlan2), based on the assumption
#              that something went wrong and udhcpc isn't running.

# 1) See if UDHCPC is running, kill it if it is.
echo "Running PS to look for udhcpc"
ps | grep "[u]dhcpc"
echo " "
PIDFILE=/var/run/udhcpc.pid
if test -f "$PIDFILE"; then
  echo "$PIDFILE exists, will try to kill the process if it's even running"
  PID=$(cat "$PIDFILE")
  echo "Sending SIGTERM to $PID"
  kill $PID
else
  echo "$PIDFILE doesn't exist."
fi
echo " "

# 2) Recreate links and clear files if needed
echo "Clearing files and recreating links (errors normal)"
rm "$PIDFILE"
ln -s /sbin/rc /tmp/udhcpc
echo " "

# 3) Take down the WAN interface, sleep a few seconds, bring it back up
echo "Restarting WAN interface (vlan2)"
ifconfig vlan2 down
sleep 5
ifconfig vlan2 up
echo " "

# 4) Restart udhcpc
echo "Restarting udhcpc, hopefully we'll get an IP and be off to the races!"
udhcpc -i vlan2 -p /var/run/udhcpc.pid -s /tmp/udhcpc -O routes -O msstaticroutes -O staticroutes -H ASUSRTAC5300 --background



And in my startup script:

Code:

# If udhcpc isn't running force start it now
PIDFILE=/var/run/udhcpc.pid
if test -f "$PIDFILE"; then
  echo "STARTUP:  udhcpc appears to be running at startup"
else
  echo "STARTUP:  udhcpc not running, going to run our WAN restart"
  /jffs/usr/bin/wanrestart
  sleep 5
fi


While this works, I'd like to try to figure out why udhcpc is failing to start. This had never been an issue before on the N66U, which ran reliably for years, so my suspicion is that it's somehow settings-related, but it might be a build issue (the N66U ran for most of it's life on build r26138M, it only got upgraded to r43381 for a short time before being replaced). I'm not seeing anything in the syslog that's obvious (either on-device or via the syslogd capture). Perhaps a start would be - what is the startup process on DD-WRT and where would udhcpc normally get setup (the /tmp/udhcpc link created, etc.) and started?

Thanks!
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14125
Location: Texas, USA

PostPosted: Fri Apr 23, 2021 14:30    Post subject: Reply with quote
My advice is to upgrade to the most recent release, which is currently 46442:

https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2021/04-23-2021-r46442/

Reset only if you absolutely need to if any issues arise or persist.

_________________
"Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT
Pogo - A minimal level of ability is expected and needed...
DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)

----------------------
Linux User #377467 counter.li.org / linuxcounter.net
TheScotsman
DD-WRT Novice


Joined: 09 Dec 2016
Posts: 22

PostPosted: Fri Apr 23, 2021 15:08    Post subject: Reply with quote
Thanks KP, I've downloaded for both the N66U and the AC5300, will flash it tonight on the N66U to start testing and later this weekend on the AC5300.
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14125
Location: Texas, USA

PostPosted: Fri Apr 23, 2021 15:28    Post subject: Reply with quote
The implied "upgrade and report if the issue still persists after upgrading; if need be, reset to defaults and re-configure from scratch after saving screenshots of your current configuration and report if the issue still persists after reset" was meant to be in my previous post. Please also report in the build release thread:

https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=328956

_________________
"Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT
Pogo - A minimal level of ability is expected and needed...
DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)

----------------------
Linux User #377467 counter.li.org / linuxcounter.net
TheScotsman
DD-WRT Novice


Joined: 09 Dec 2016
Posts: 22

PostPosted: Sat Apr 24, 2021 0:22    Post subject: Reply with quote
Upgraded my N66U to r46442 without resetting, the udhcpc problem persisted. However, I got a lot closer to the cause! I was curious to see what changes there were between the current build and my my old releases (r43381 big on the ASUS RT-N66U , r43516 on the ASUS RT-AC5300) so I went looking for the changelog and found the SVN timeline at https://svn.dd-wrt.com/timeline. Did some poking and stumbled on an open ticket, https://svn.dd-wrt.com/ticket/6520 "Use NVRAM for client lease DB (no wan ip)". That's it! At some point I turned this option on (notionally wanted to keep leases stable across a boot although in my setting it honestly doesn't matter since anything I care about has a static lease anyway). If I turn off the "Use NVRAM for client lease DB" option on the services tab, my issue goes completely away - WAN IP gets picked up on every boot, and if I DHCP release/renew the WAN IP from the Status->WAN tab it works perfectly. If I turn the option back on, it may hang onto the address successfully across a reboot, but anything that causes a change (such as releasing it, or forcing the upstream router to give it a different address) breaks it again.

Happens on both the current r46442 build and the older r43881 build. I haven't tampered with the AC5300 yet (kid is doing overdue homework and relying on the connection!) but will reflash it to r46442 over the weekend and report any operational issues in the build thread. I already updated the SVN ticket.

Glad to have a solution other than my hacked workaround - I'd had to worry that when I'm out of the house or away Comcast will hiccup and the family will lose the internet without a reliable pattern to get it back, seems that's solved with a simple uncheck of a box. Very Happy
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum