Malfunctioning Tomato due to default MAC address

Discussion in 'Tomato Firmware' started by kyphos, Dec 4, 2012.

  1. kyphos

    kyphos Networkin' Nut Member

    keywords: Motorola WR850G Tomato MAC 001122334456

    This is a troubleshooting tale, based on my recent experience resolving a bizarre situation with Tomato firmware running on a Motorola WR850G. I'm posting it here in case my findings can help others solve a similar problem.

    My brother needed a small WiFi router for his place in Florida. I happened to have an unused Moto WR850G (similar to the venerable Linksys WRT54GL), so I flashed it with Toastman 1.28.7633.3 IPT-ND STD, configured it, and sent it to him. It's a plain-vanilla setup:
    - DHCP on the WAN, connected to a Moto Surfboard cable modem (Comcast is his ISP).
    - DNS configured to use OpenDNS instead of Comcast's DNS.
    - DHCP enabled on the LAN:
    - a DDNS service configured, (so I could locate its public IP).
    - remote admin access enabled, with https:// on port 443 (so I could log in and admin it)
    - SSH enabled on port 2323

    Once it was configured, I tested the router to verify everything worked as expected, and shipped it to him. He plugged it in behind his cable modem, power cycled the modem, and tried to connect to the internet from his LAN-connected PC. Nothing. He rebooted a few times. Cursed the gods of technology. He then phoned me (in Canada), and I spent two hours on the phone with him trying to figure out what was going on.

    Here are the symptoms:
    - the Tomato GUI was working fine.
    - Tomato had issued a DHCP request to Comcast and received a response. Displayed on the Overview page was a legitimate Comcast public IP address, subnet, and gateway.
    - his LAN-connected PC could obtain an IP lease for from Tomato
    - Tomato was unable to retrieve the current time. (i.e. requests to NTP failed).
    - the DDNS update failed, with 'unknown error -1'.
    - using the ping tool (Tools/System), it couldn't ping common web servers such as,, amazon. com.
    - pings to or failed (Google's DNS servers).
    - pings to failed. That's the IP of the Comcast gateway assigned to Tomato by DHCP, as displayed on the Status/Overview page. This is the first hop between Tomato and the rest of the internet. If Tomato can't connect to it, it's not going to connect to anything else on the internet.
    - there were no error messages of note in the Tomato logs.

    I was troubleshooting this remotely, thousands of miles away. I tried to log in to Tomato at its public IP address (as displayed on the Status page) on port 443. No response. I tried to open an SSH session to port 2323. No response. I tried pinging its public IP address. It responded!!

    This last finding was extremely troubling. Like most router gateways, Tomato firmware doesn't respond to ping (ICMP traffic) on their WAN interface. I had my brother examine the Tomato firewall settings -- "Respond to ICMP ping" was disabled. Yet the router was happily responding to pings from my remote PC.

    After two hours of troubleshooting trying various things, I was about to give up and tell my brother to go buy an inexpensive wireless router at Best Buy. At this point, he mentioned in passing that the MAC address displayed on the Overview page seemed odd: 00:11:22:33:44:56. I've never observed such a MAC before. It certainly wasn't a legitimate MAC from the range assigned to Motorola. (00-11-22 is assigned to Cimsys, a Korean manufacturer). I had him examine the sticker on the bottom of the WR850G, find the MAC it shipped with, and got him to enter that as an override for the WAN port (in Advanced/MAC address). He saved the Tomato settings, power-cycled the cable modem, then power-cycled the WR850G.

    That's all it took to fix it. When Tomato restarted, it obtained from Comcast a completely different public IP (, and a corresponding (completely different) gateway address. Tomato was now fully on-line: NTP worked, DDNS worked, DNS lookups worked, pings worked, and my brother's LAN was now connected to the internet. Success!!

    My subsequent research on this website and elsewhere indicates that Motorola stored the 'factory' MAC addresses (WAN, LAN and WiFi) for the WR850G in a different location that most other router platforms. I surmise that at boot time, the Tomato firmware goes looking for the vendor's MAC settings, can't find them, and so assigns these defaults: 00:11:22:33:44:55 for LAN interface, …:56 for WAN, and …:57 for WiFi.

    It's a mystery (to me) why Comcast would assign a different public IP address and gateway based on the router's MAC. It's a mystery why the behavior of the Tomato firmware was so totally messed up when the WAN MAC was 00:11:22:33:44:56. The fact that Tomato's WAN port was responding to pings even though the Firewall settings disabled ICMP is extremely odd.

    In any event, the lesson from this is if you ever notice your Tomato WAN interface has a MAC of 00:11:22:33:44:56, something is amiss.

    Solution Part 2:
    In addition to overriding the 'default' WAN MAC through the GUI, I guided my brother to also change the MAC stored in nvram in variable et1macaddr to the legitimate Moto-assigned MAC. Even though he had entered the new MAC through the GUI, I observed that this variable still held 00:11:22:33:44:56. Seemed a good idea to get rid of it completely.
    nvram set et1macaddr=Moto:mac:here

    End of story. Hope this might help someone else someday.
  2. rhester72

    rhester72 Network Guru Member

    The different IP, etc. was originally used by cable companies to force you to a "splash page" of sorts telling you to sign up for service if you did your DHCP from an unrecognized (by them) MAC (assuming you went and bought your own DOCSIS and tried to 'steal' cable Internet on an "unlit" line), hence the whole notion of MAC cloning in the first place. These days, it's just a royal PITA for them and us. :/

  3. Monk E. Boy

    Monk E. Boy Network Guru Member

    Comcast definitely assigns a different IP address based on the MAC address of the DHCP request. Back when I had them if I changed the last octet (last 2 digits) the IP address would barely change, but if I changed the first 3 octets (first 6 digits) then the IP address would be in a wildly different block. I'm guessing this corresponds to some weird track-the-IP-back-to-the-system-after-we've-purged-DHCP-logs system they have in place, since they share their IP address blocks across the entire country it would make sense for them to be able to say "well that's a (insert manufacturer here) system" based on the IP address in a subpoena.

    Actually I think in Tomato's website you can change the WAN MAC, the WLAN MAC, but you can't change the LAN MAC. Good idea to set them all through a shell environment, since its more likely to take. The website is likely having trouble reading & writing to the NVRAM variable(s) so forcing its hand by setting them in a shell environment will likely fix the website.
  4. kyphos

    kyphos Networkin' Nut Member

    It does make sense (sort of ) why Comcast might assign different routers to different subnets. Load balancing for one thing. But assigning the router to a different subnet (different IP range) doesn't explain why it had no internet connectivity, and couldn't even ping the Comcast gateway router (the first hop). The fact that Tomato firmware was responding to ICMP packets on the WAN interface even though its firewall had ICMP disabled is really bizarre. That should have nothing to do with what Comcast subnet it's in.

    @ MonkE -- I don't think the GUI was having trouble reading/writing the NVRAM. Rather, I suspect the et1macaddr variable is where Tomato stores its default MAC for the WAN interface. By inspecting the contents of the NVRAM, I found that the variable the GUI updates with the manually-entered MAC is named wan_hwaddr. If I were subsquently to use the GUI to revert back to the default setting (by clicking the Default button on the MAC Address page), I think the Tomato firmware would pull 00:11:22:33:44:56 out of et1macaddr and put it into wan_hwaddr.
  5. mpegmaster

    mpegmaster Addicted to LI Member

    This works for me... :cool:

    using the... Startup Command... :rolleyes:

    00:14:BF is for Linksys

    nvram set et0macaddr=00:14:BF:xx:xx:EA
    nvram set il0macaddr=00:14:BF:xx:xx:EB
    nvram set wl0macaddr=00:14:BF:xx:xx:EC
    nvram commit

    Just substitute you manufacturer octets for the 00:14:BF and replace the last octets what is on the label of your device.

    CHEERS!!! :D
  6. Monk E. Boy

    Monk E. Boy Network Guru Member

    In Tomato most things like this are stored as NVRAM variables, so maybe Motorola doesn't use the variable Tomato pulls its value from.

    Needless to say, its good information to know, and thanks for putting it out there!
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice