troubleshooting no WAN IP

If your problem doesn't fall into one of the other categories, report it here.

Moderator: Moderators

oliver
Posts: 48
Joined: Wed Jun 04, 2014 7:30 pm

Re: troubleshooting no WAN IP

Post by oliver »

pythonic wrote:
Sat Jul 30, 2022 11:10 pm
Did you notice whether your WAN MAC address changed between the different installations at all?
Can't say I did. I just checked now though and my modems known CPE MAC ends in 1C

If I run an ifconfig on gargoyle it shows
eth0: ......1C
wlan0: ....1D
wlan1: ....1E

I have no idea how the VLANs or whatever it is work on this thing but WAN and LAN are both on eth0 as virtual interfaces (LAN is eth0.1 and WAN is eth0.2 but there is also br-lan where the local IPs are plumbed.)

Can these come up in random order after a reboot/restart?
Is it generally a good idea to use a custom MAC?

pythonic
Posts: 230
Joined: Mon Mar 11, 2019 5:47 am
Location: Australia

Re: troubleshooting no WAN IP

Post by pythonic »

oliver wrote:
Sun Jul 31, 2022 7:12 am
pythonic wrote:
Sat Jul 30, 2022 11:10 pm
Did you notice whether your WAN MAC address changed between the different installations at all?
Can't say I did. I just checked now though and my modems known CPE MAC ends in 1C

If I run an ifconfig on gargoyle it shows
eth0: ......1C
wlan0: ....1D
wlan1: ....1E

I have no idea how the VLANs or whatever it is work on this thing but WAN and LAN are both on eth0 as virtual interfaces (LAN is eth0.1 and WAN is eth0.2 but there is also br-lan where the local IPs are plumbed.)

Can these come up in random order after a reboot/restart?
They shouldn't! However over time I've noticed various tweaks to OpenWrt device build recipes to resolve issues with extracting MAC addresses from the device's flash and I just wondered if your ISP's IP address allocation changing may be due to the device offering different WAN MAC addresses in the different firmware versions as a consequence of such version specific tweaks, though with a device such as yours with the WAN being a VLAN rather than a separate interface this seems unlikely. Of course your ISP's IP address allocation changing could have been due to something totally unrelated too...
oliver wrote:
Sun Jul 31, 2022 7:12 am
Is it generally a good idea to use a custom MAC?
Not normally, though sometimes people need to use the MAC address from another device (such as an ISP supplied modem/router) in order to connect with different equipment.

oliver
Posts: 48
Joined: Wed Jun 04, 2014 7:30 pm

Re: troubleshooting no WAN IP

Post by oliver »

pythonic wrote:
Sun Jul 31, 2022 9:58 am
However over time I've noticed various tweaks to OpenWrt device build recipes to resolve issues with extracting MAC addresses from the device's flash and I just wondered if your ISP's IP address allocation changing may be due to the device offering different WAN MAC addresses in the different firmware versions as a consequence of such version specific tweaks, though with a device such as yours with the WAN being a VLAN rather than a separate interface this seems unlikely. Of course your ISP's IP address allocation changing could have been due to something totally unrelated too...
I assumed the change of IP allocation was due to Xfinity having a 6 to 8 hour outage and maybe something was still down but I think you're onto something with the MAC address stuff.

Earlier today I made some notes and flashed 1.1.13.

On 1.1.12, my MACs were:

Code: Select all

# ifconfig -a|grep HWaddr|grep -E "(eth|wlan)"
eth0      Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1C  
eth0.1    Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1C  
eth0.2    Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1C  
wlan0     Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1D  
wlan1     Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1E  
On 1.1.13, they were:

Code: Select all

# ifconfig -a|grep HWaddr|grep -E "(eth|wlan)"
eth0      Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1E  
eth0.1    Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1E  
eth0.2    Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1F  
wlan0     Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1D  
wlan1     Link encap:Ethernet  HWaddr 64:66:xx:xx:xx:1E 
To my layman eyes it seems odd that eth0 and wlan1 have the same MAC. The 1.1.12 'layout' just seems more logical (if that's the right word)

The other main difference which I probably should have noticed is that 1.1.12 is ar71 and 1.1.13 is ath79.

When on ath79, I can't get anything more than ~10Mbit/s but on ar71 it's ~60 so I think my old WDR3600 needs to stay on ar71

After forcing a downgrade back to 1.1.12, my MACs reverted to that same scheme they had before.

pythonic
Posts: 230
Joined: Mon Mar 11, 2019 5:47 am
Location: Australia

Re: troubleshooting no WAN IP

Post by pythonic »

As best I can tell the MAC address difference you found is directly attributable to the transition from ar71xx to ath79: ar71xx seems to get them from the art partition while ath79 seems to get them from the uboot (bootloader) partition.

I'm wondering if you were to set the Use Custom MAC Address connection option to the 1C MAC address in the 1.13 build whether you would get the same WAN IP address range as with the 1.12 build and whether your WAN performance may be affected by the WAN IP address range allocated?

oliver
Posts: 48
Joined: Wed Jun 04, 2014 7:30 pm

Re: troubleshooting no WAN IP

Post by oliver »

pythonic wrote:
Mon Aug 01, 2022 1:00 am
As best I can tell the MAC address difference you found is directly attributable to the transition from ar71xx to ath79: ar71xx seems to get them from the art partition while ath79 seems to get them from the uboot (bootloader) partition.

I'm wondering if you were to set the Use Custom MAC Address connection option to the 1C MAC address in the 1.13 build whether you would get the same WAN IP address range as with the 1.12 build and whether your WAN performance may be affected by the WAN IP address range allocated?
I didn't set the custom MAC but I was kind of watching my WAN IP on both 1.1.12 and 1.1.13 and on both builds I received an IP in the 73.x.x.x range. May have been the same one both times but definitely not the 104.x.x.x one

Post Reply