How does wwan0 get it's IP address, subnet mask and gateway?

Been battling AT&T for weeks now, and they sure don't know the answer.

So here goes:
Bottom line question is, how does my cellular wwan0 interface get it's IP address, Mask?

Have 4 devices all on AT&T FirstNet with a private APN.
3 of the devices get an IP with a /32 and one get's an IP but with a /29.
On the same device, if I just jump on the default firstnet-broadband APN, I get a /32

With a tcpdump of wwan0 I can clearly see a full blown DHCP session with what I thought was with AT&T. Offering me the IP with a mask of /29. They unequivocally deny that it's from them. Assuming it's not them, but with the ModemManager? I've got to believe that AT&T has to play a roll here. Can anyone help me prove my theory?

Can you post the output of uci export network as well as the interesting part of the tcpdump? Preferably with options -evn udp port 67

/29 device uci output

package network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdb3:9dda:00d0::/48'
        option packet_steering '1'

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.113.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ifname 'eth0.1'

config device 'lan_dev'
        option name 'eth0.1'
        option mtu '1340'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 6t'
        option vid '1'

config interface 'wwan'
        option proto 'modemmanager'
        option apn '34044.fn'
        option auth 'none'
        option iptype 'ipv4v6'
        option mtu '1340'
        option device '/sys/devices/platform/1e1c0000.xhci/usb1/1-1'

One of the /32 devices uci output

package network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdb3:9dda:00d0::/48'
        option packet_steering '1'

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.113.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ifname 'eth0.1'

config device 'lan_dev'
        option name 'eth0.1'
        option mtu '1340'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 6t'
        option vid '1'

config interface 'wwan'
        option proto 'modemmanager'
        option apn '34044.fn'
        option auth 'none'
        option iptype 'ipv4v6'
        option mtu '1340'
        option device '/sys/devices/platform/1e1c0000.xhci/usb1/1-1'

You looking for the tcpdump during this DHCP session I see?

ifconfig of the problem child

wwan0     Link encap:Ethernet  HWaddr 22:AF:12:B9:B0:75  
          inet addr:107.90.50.203  Bcast:107.90.50.207  Mask:255.255.255.248
          inet6 addr: fe80::20af:12ff:feb9:b075/64 Scope:Link
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:1340  Metric:1
          RX packets:1174 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1231 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:98036 (95.7 KiB)  TX bytes:101876 (99.4 KiB)

All the 3 other look like this:

wwan0     Link encap:Ethernet  HWaddr DE:34:0F:4C:71:C2  
          inet addr:107.90.50.205  Bcast:107.90.50.207  Mask:255.255.255.252
          inet6 addr: fe80::dc34:fff:fe4c:71c2/64 Scope:Link
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:1340  Metric:1
          RX packets:3601 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3606 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:302908 (295.8 KiB)  TX bytes:303360 (296.2 KiB)

Yes, run the tcpdump and restart the wwan interface to get the new lease.
Although I am very confident that the mistake is from their side. ModemManager doesn't use whatever values, only what it has been sent from the basestation.

It's /30

1 Like

You get IP information from the modem, not from the carrier directly.
You can safely ignore mask and gateway values as your router should use interface-based routing without ARP. As a result you should see no IP address in the default route entry in your routing table:

# ip r
default dev wwan0 proto static scope link metric 10

ya that was a big old typo, /30

Andrew/Trendy, thanks for the confirmation on the source of the IP information, you don't know how long I thought that wasn't the case. But the EE in me needs to why that device is getting the /29. It's got to be AT&T. The devices are just finite state machines, given the same input, they're all return the same output.

One of the AT&T field tech's actually told my device was making it up. I was like lord help me.

So who's the super Linux guru who can help me fulfill my yearning to see what transpires between the SIM and my device. There's something different, and I know it makes no difference cause it works. But the thought of just accepting it is going to eat me alive. I'll keep digging in the meantime. Thanks guys, huge help!

These are the routing tables from the /29 and the other 3 units getting a /30. Very different for sure.

root@AWC-EI:~# ip r
default via 107.90.50.204 dev wwan0  src 107.90.50.203 
107.90.50.200/29 dev wwan0 scope link  src 107.90.50.203 
192.168.113.0/24 dev br-lan scope link  src 192.168.113.1
root@AWC-EI:~# ip r
default via 107.90.50.205 dev wwan0 
107.90.50.204/30 dev wwan0 scope link  src 107.90.50.206 
192.168.113.0/24 dev br-lan scope link  src 192.168.113.1
root@AWC-EI:~# ip r
default via 107.90.50.206 dev wwan0 
107.90.50.204/30 dev wwan0 scope link  src 107.90.50.205 
192.168.113.0/24 dev br-lan scope link  src 192.168.113.1 
root@AWC-EI:~# ip r
default via 107.90.50.202 dev wwan0 
10.3.252.4/30 dev br-lan scope link  src 10.3.252.6 
107.90.50.200/30 dev wwan0 scope link  src 107.90.50.201 

A real mind bend for a 22 year CCIE.

The network assigns a single /32 as others already have said. The point of the fake netmask is to trick the DHCP client into believing it has both an address and a reachable gateway. The required size of this network depends on the assigned address. The fake network address and fake broadcast address must both be dfifferent from the assigned address. I.e

address & netmask != address
address | ~netmask != address

It's easy to see what happens if you write the address, or the last part of it, in binary. The max prefix length will be the number of the first bit different from the LSB.

Some examples (only looking at the last 8 bits here - you may have to look at more bits in some situations):

107.90.50.203 ends in 11001011. LSB is 1. First bit different from LSB is 29.
107.90.50.206 ends in 11001110 . LSB is 0. First bit different from LSB is 30
107.90.50.205 ends in 11001101. LSB is 1.First bit different from LSB is 30
10.3.252.6 ends in 00000110. LSB is 0.First bit different from LSB is 30

1 Like

I just swapped SIM cards between the two units and the wwan0 netmask or /30 followed the SIM. We pulled the SIM from .201 that had /30 and put it in .203 that was getting the /29. So with my darn near zero experience in this cellular world, does that indicate that AT&T has this one SIM programmed differently? The whole point of this was to isolate this problem of .203 not being able to reach several of my other locations, not all but some. After the SIM swap I could reach all of them. I can only conclude this is AT&T programming/something problem? Or am I dead wrong?

@bmork , I've got to try to digest your comment, I'm intrigued the more I read it. Thanks!

The other odd thing I've noticed on the this troubled SIM: It follows the SIM for sure.

`wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:107.90.50.203  P-t-P:107.90.50.203  Mask:255.255.255.248`

vs all the other locations

`wwan0     Link encap:Ethernet  HWaddr 2A:BA:6A:4F:7B:07  
          inet addr:107.90.50.206  Bcast:107.90.50.207  Mask:255.255.255.252`

I am so out of my element. Does it throw up any red flags? Thanks all.

@bmork's reply makes sense. If they allocate /32 addresses and the protocol is not point to point, the mask needs to be adjusted in case the address would be a broadcast.
For example the .203/30 is broadcast, so mask has to be /29.
But there seem to be some differences in the routing table between you and @AndrewZ
However if it works as it is, then you shouldn't worry so much.

No it doesn't work, I can reach .205 and .206, but not .201 from the troubled .203. AT&T is clueless as am I.

.205 & .206 can reach everywhere.

It's crazy, this project has been going on, are you sitting down :slight_smile: 13 months. Only 3 weeks or so ago we had 3 of the 4 sites working. They've completely rebuilt it 3 times, 1st try wasn't on FirstNet network and then some other excuse the next two times. All I get out of them it's my gear, same make, model, firmware. And then the funk follows the SIM on a swap (don't really know what tells me) other than it's not my hardware.

You guys are awesome, if you think of anything else. Hit me up.