Pixel 6 unable to register to mobile network behind OpenWrt

I've got a confusing problem here and would love some assistance.

Yesterday I refreshed my network and have since lost WiFi calling / Phone registration for my Mint Mobile (T-Mobile) phone. I live in a remote area and require WiFi calling to function.

Previously I had a WG1608 w/LTE running with ROOter GoldenOrb_2022-10-21 (OpenWrt 21.02-SNAPSHOT)
This served an SSID my WiFi6 router (AX3600, stock firmware) would repeat, in wireless repeater mode.

This configuration permitted WiFi calling when connecting to the AX3600 SSID. If my phone connected directly to the WG1608 SSID, the phone would not register and WiFi calling would not function.

GOOD: [WG1608]<WiFi>[AX3600]<WiFi>[Phone]
BAD: [WG1608]<WiFi>[Phone]

I have refreshed this configuration:
I now have a Proxmox VM x86 router running OpenWRT 22.03.2 and the same AX3600 is connected now via ethernet because the platform I've built on has no wireless. The AX3600's mode was changed from Wireless Repeater AP to Wired AP mode.

[x86 Router]<Wired>[AX3600]<WiFi>[Phone]

With this topography/sw stack I can not get my phone to register on the service, so WiFi calling does not function.

I'm not clear what configs or logs would be desirable to see, but I'm highly motivated so, please, let me know!

/edit: Just Checked [x86 Router]<Wired>[Phone] with a USB C Dock and was unable to register/perform calling.
/edit2: Attempted to use a VPN app on my phone to encapsulate the traffic. No dice, but it was a freeware VPN utility so I'm not sure that's conclusive.
/edit3: I've enabled logging on the Firewall rules and am not seeing any clearly relevant blocking events

[ 9932.972341] reject wan in: IN=wwan0 OUT= MAC=f2:a3:ca:7c:b4:7d:00:00:00:00:00:00:08:00 SRC=142.251.35.195 DST=10.166.226.114 LEN=198 TOS=0x08 PREC=0x40 TTL=61 ID=10279 PROTO=TCP SPT=80 DPT=39578 WINDOW=172 RES=0x00 ACK PSH FIN URGP=0 MARK=0x3e00 
[10086.564200] reject wan in: IN=wwan0 OUT= MAC=f2:a3:ca:7c:b4:7d:00:00:00:00:00:00:08:00 SRC=142.250.68.170 DST=10.166.226.114 LEN=181 TOS=0x08 PREC=0x40 TTL=61 ID=40707 PROTO=TCP SPT=443 DPT=60220 WINDOW=172 RES=0x00 ACK PSH FIN URGP=0 MARK=0x3e00

I'm going to guess it has something to do with IPv6. T-Mobile really likes IPv6. If your ISP doesn't offer IPv6, you need to make sure OpenWrt is only showing the phone an IPv4 address and V6 is completely shut down. If your ISP does offer IPv6, the router needs to be properly configured to pass it to the phone.

Proxmox is a Debian-based server for virtualization.
Are you sure that the underlying hypervisor is not blocking any network traffic required for Wifi call?

No I'm not certain. I'll move my tcpdump up a layer to see if there might be more to follow on the Hypervisor.

@mk24
I have been on an IPv6 chase with this as you have suggested. Workstations on the network fail the ipv6-test.com large packet test. I do appear to have IPv6 from the ISP and playing with IPv6 delegation/RA settings impacts my ipv6-test.com results. I'm hoping once I get that test to 10/10 I'll be calling once again.

try ipv6 relay, if prefix delegation fails.

if you want to test with/without Proxmox, you could install OpenWRT on USB stick and boot your VM server from USB stick

I may go the USB stick route here in a few moments.

The vm-router is able to ping6 to ipv6.google.com, but the Proxmox host is not able.

After disabling delegation and converting to relay mode, I retain some IPv6 functionality according to test-ipv6.com but I'm still 1/10- would you mind running that test as a sanity check for me? Maybe it's not useful.

/edit: after you run tests, click on 'Tests Run' - I can not succeed in the Large IPv6 Packet Test
/edit2: sample output from ipv6test

|Test with IPv4 DNS record||ok (0.572s) using ipv4|
| --- | --- | --- |
|Test with IPv6 DNS record||ok (0.576s) using ipv6|
|Test with Dual Stack DNS record||ok (0.575s) using ipv6|
|Test for Dual Stack DNS and large packet||ok (0.567s) using ipv6|
|Test IPv6 large packet||timeout (15.015s)|
|Test if your ISP's DNS server uses IPv6||ok (0.738s) using ipv6|
|Find IPv4 Service Provider||ok (0.837s) using ipv4 ASN 20057|
|Find IPv6 Service Provider||ok (0.477s) using ipv6 ASN 20057|

I use relay as well on a non-virtualized x86 OpenWRT 22.03.2 behind a cable router
10/10.
all ipv6 tests ok for me.
large packet test ok.
all targets except test-ipv6.arauc.br work.

Thank you Pico. I mentioned before, but I have a LTE/modem connection from OpenWRT to the internet, so interfaces wan and wan6 are not used, instead I have a ModemManager interface which controls the modem and sets up the tcp. Do I need to add an entry into the DHCP config for the modemmanager interface or are the wan and lan designations here firewall zones?

/edit: you may notice my ipv6 mtu @ 1280, this was a recommendation I came across last night. There has been no material effect in changing the mtu I've observed

/etc/config/dhcp


config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'
        option authoritative '1'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option leasetime '12h'
        option dhcpv4 'server'
        option limit '254'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config host
        option name 'miwifi'
        option dns '1'
        option mac '8C:53:C3:B4:7E:23'
        option ip '192.168.13.2'

config host
        option dns '1'
        option mac 'F8:5E:3C:30:EC:EE'
        option ip '192.168.13.249'
        option name 'rooter'

config host
        option name 'clplexsrv01'
        option dns '1'
        option mac '92:A3:7C:32:18:56'
        option ip '192.168.13.10'

/etc/config/network


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

config globals 'globals'
        option ula_prefix 'fd5d:b54f:c504::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.13.1'

config device
        option name 'wwan0'
        option mtu '1500'
        option mtu6 '1280'

config interface 'Broadband'
        option proto 'modemmanager'
        option device '/sys/devices/pci0000:00/0000:00:1e.0/0000:01:1b.0/usb3/3-1'
        option apn 'firstnet-broadband'
        option auth 'none'
        option iptype 'ipv4v6'
        option mtu '1500'
        option ip6weight '0'
        option delegate '0'

config device
        option name 'eth0'
        option mtu6 '1280'

If I fudge with the url for the large packet test and reduce the payload length, it does succeed.

Removed a lot of x's here and still fails:

https://mtu1280.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&testdomain=test-ipv6.com&testname=test_v6mtu

Removed basically all x's here and success!

https://mtu1280.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxxxxxxxxxxx&testdomain=test-ipv6.com&testname=test_v6mtu

/edit: I use the same LTE module and carrier as was used prior to transitioning to the new platform.

I usually suck at properly reading config files.

  • So instead of default „wan“ interface, you seem to have „broadband“ as WAN interface.
  • so you are using an LTE modem for WAN connection. I did not get that from reading the initial post.

yes for proper ipv6 relay.
And I seem to miss the second part of the relay, instead of „wan“ on „Broadband“, like this:

config dhcp Broadband
option dhcpv6 relay
option ra relay
option ndp relay
option master 1

config dhcp lan
option dhcpv6 relay
option ra relay
option ndp relay

i am though not gifted with extra ipv6 config for lte sticks, I kind of miss a correspondig config for your broadband. At least thats what wan6 is doing for on the default wan interface.

never had that before.
So far, I dont know, why your connection partly works.
But your Broadband config seems to have a MTU value, I would try 1300 and if that works, try to bisect the largest working value.

Ok. Added the DHCP config to the Broadband interface, configured as you have indicated. Now my clients aren't getting IPv6 leases per the Status page and the ipv6test fails detecting no ipv6 address

the ignore '1' you see is relevant to DHCP4

/etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'
        option authoritative '1'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option leasetime '12h'
        option dhcpv4 'server'
        option limit '254'
        option ndp 'relay'
        option ra 'hybrid'
        option dhcpv6 'hybrid'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config dhcp 'Broadband'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'
        option interface 'Broadband'
        option ignore '1'
        option master '1'

config host
        option name 'miwifi'
        option dns '1'
        option mac '8C:53:C3:B4:7E:23'
        option ip '192.168.13.2'

config host
        option dns '1'
        option mac 'F8:5E:3C:30:EC:EE'
        option ip '192.168.13.249'
        option name 'rooter'

config host
        option name 'clplexsrv01'
        option dns '1'
        option mac '92:A3:7C:32:18:56'
        option ip '192.168.13.10'

Snagged a tcpdump attempting to pull the failing ipv6 large packet test and see something interesting- bad udp checksum

15:54:36.047675 IP (tos 0x0, ttl 128, id 1597, offset 0, flags [none], proto UDP (17), length 71)
    STRIDER.lan.65357 > jbwrt.lan.53: [udp sum ok] 56696+ A? mtu1280.vm3.test-ipv6.com. (43)
15:54:36.047821 IP (tos 0x0, ttl 64, id 26930, offset 0, flags [DF], proto UDP (17), length 71)
    jbwrt.lan.53 > STRIDER.lan.65357: [bad udp cksum 0x9c56 -> 0x777e!] 56696 q: A? mtu1280.vm3.test-ipv6.com. 0/0/0 (43)
15:54:36.090836 IP (tos 0x0, ttl 1, id 31436, offset 0, flags [none], proto UDP (17), length 198)
    STRIDER.lan.58212 > 239.255.255.250.1900: [udp sum ok] UDP, length 170

Following the trail of bad UDP checksum I grepped a few tcpdumps:

grep bad *

ip6.out:    jbwrt.lan.67 > jPhone.lan.68: [bad udp cksum 0x9d6d -> 0x6d0d!] BOOTP/DHCP, Reply, length 300, xid 0x6ad5b01, Flags [none] (0x0000)
ip6.out:    jbwrt.lan.67 > jPhone.lan.68: [bad udp cksum 0x9d6d -> 0x6a0d!] BOOTP/DHCP, Reply, length 300, xid 0x6ad5b01, Flags [none] (0x0000)
ip6.out:    jbwrt.lan.53 > jPhone.lan.37899: [bad udp cksum 0x9c80 -> 0xd590!] 64290 q: A? connectivitycheck.gstatic.com. 1/0/0 connectivitycheck.gstatic.com. A 142.251.35.195 (63)
ip6.out:    jbwrt.lan.53 > jPhone.lan.45787: [bad udp cksum 0x9cc9 -> 0x638d!] 15680 q: A? epdg.epc.mnc260.mcc310.pub.3gppnetwork.org. 2/0/0 epdg.epc.mnc260.mcc310.pub.3gppnetwork.org. CNAME epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org., epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org. A 208.54.2.99 (136)
ip6.out:    jbwrt.lan.53 > jPhone.lan.15354: [bad udp cksum 0x9c71 -> 0xcba7!] 56388 q: A? www.google.com. 1/0/0 www.google.com. A 142.251.32.228 (48)
ip6.out:    jbwrt.lan.53 > jPhone.lan.22755: [bad udp cksum 0x9cc9 -> 0x75a4!] 55602 q: A? epdg.epc.mnc240.mcc310.pub.3gppnetwork.org. 2/0/0 epdg.epc.mnc240.mcc310.pub.3gppnetwork.org. CNAME epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org., epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org. A 208.54.2.99 (136)
ip6.out:    jbwrt.lan.53 > jPhone.lan.1210: [bad udp cksum 0x9c81 -> 0xe927!] 123 NXDomain q: A? sos.epdg.epc.mnc240.mcc310.pub.3gppnetwork.org. 0/0/0 (64)
ip6.out:    jbwrt.lan.53 > jPhone.lan.22911: [bad udp cksum 0x9c81 -> 0xeba9!] 43315 NXDomain q: A? sos.epdg.epc.mnc240.mcc310.pub.3gppnetwork.org. 0/0/0 (64)
ip6.out:    jbwrt.lan.53 > jPhone.lan.61462: [bad udp cksum 0x9c81 -> 0x1901!] 58180 NXDomain q: A? sos.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org. 0/0/0 (64)
ip6.out:    jbwrt.lan.53 > jPhone.lan.30455: [bad udp cksum 0x9c81 -> 0xeb43!] 35361 NXDomain q: A? sos.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org. 0/0/0 (64)
ip6.out:    jbwrt.lan.53 > jPhone.lan.60984: [bad udp cksum 0x9c9a -> 0xec87!] 44042 q: A? mtalk.google.com. 2/0/0 mtalk.google.com. CNAME mobile-gtalk.l.google.com., mobile-gtalk.l.google.com. A 142.250.114.188 (89)
ip6.out:    jbwrt.lan.53 > jPhone.lan.60866: [bad udp cksum 0x9c94 -> 0x7dd0!] 53342 q: A? g.whatsapp.net. 2/0/0 g.whatsapp.net. CNAME chat.cdn.whatsapp.net., chat.cdn.whatsapp.net. A 157.240.19.54 (83)
strider6.out:    jbwrt.lan.53 > STRIDER.lan.65357: [bad udp cksum 0x9c56 -> 0x777e!] 56696 q: A? mtu1280.vm3.test-ipv6.com. 0/0/0 (43)
tmocalling.out:    jbwrt.lan.67 > jPhone.lan.68: [bad udp cksum 0x9d6d -> 0x0b21!] BOOTP/DHCP, Reply, length 300, xid 0xe5e4ddb5, Flags [none] (0x0000)
tmocalling.out:    jbwrt.lan.67 > jPhone.lan.68: [bad udp cksum 0x9d6d -> 0x0821!] BOOTP/DHCP, Reply, length 300, xid 0xe5e4ddb5, Flags [none] (0x0000)
tmocalling.out:    jbwrt.lan.53 > jPhone.lan.46252: [bad udp cksum 0x9c80 -> 0x7281!] 64400 q: A? connectivitycheck.gstatic.com. 1/0/0 connectivitycheck.gstatic.com. A 142.251.35.195 (63)
tmocalling.out:    jbwrt.lan.53 > jPhone.lan.45767: [bad udp cksum 0x9c71 -> 0x6bc5!] 50292 q: A? www.google.com. 1/0/0 www.google.com. A 142.251.32.228 (48)
tmocalling.out:    jbwrt.lan.53 > jPhone.lan.62191: [bad udp cksum 0x9c9a -> 0xe758!] 421 q: A? mtalk.google.com. 2/0/0 mtalk.google.com. CNAME mobile-gtalk.l.google.com., mobile-gtalk.l.google.com. A 142.250.115.188 (89)
tmocalling.out:    jbwrt.lan.53 > jPhone.lan.54301: [bad udp cksum 0x9c94 -> 0x6e0c!] 57582 q: A? g.whatsapp.net. 2/0/0 g.whatsapp.net. CNAME chat.cdn.whatsapp.net., chat.cdn.whatsapp.net. A 157.240.19.54 (83)

could this be the same case of your UDP checksum errors?

2 Likes

Attempted to apply the iptables config to resolve, but still seeing checksum/length errors and not succeeding with the ipv6 test.

/edit: The link suggests that the error was being registered because packets were being generated on the interface where the capture occurred. I have some bad checksums getting thrown for packets originating on the internet in addition to those generated on the router interface, such as DHCP.

The result of the link was that the OP realized there was no problem actually.

Just replicated the Wireless bridge configuration mentioned in the first post by adding a USB wifi adapter. Still no registration / wifi calling

[x86 Router]<WiFi>[AX3600]<WiFi>[Phone]

Don't have a clue why this isn't working for you; however, thought it might help to let you know that the following works for me.

[x86 Router]<wire (2 vlans)>[openwrt AP (22.03)]<wifi>[android device with custom rom, tmobile, wifi calling working]

I don't think the udp checksum is an issue, but it is apparently possible to set up a nft firewall rule to set the udp checksum to 0 which results in the checksum not being checked (i'm guessing your firewall is on the x86 router, my openwrt AP firewall is off). Link - you likely will have to adapt this to your firewall.

I've had issues in the past with tmobile and visual voice mail. Mysteriously, visual voice mail now works for me. This is probably related to the android device, updates to it's custom rom and I suspect also changes with tmobile. That said, if you have updates to your device recently you might also want to look there.

Are you removing your sim card from the tmobile device when attempting wifi calling? (i.e. using the sim card for your router? sorry it's not clear to me from your first post). Is the tmobile device ipv6 address different in the non working senarious but always the same when wifi calling works? I don't think a different ipv6 address should matter, but if your removing your sim and the ipv6 address changes, I wonder if Tmobile might become unhappy and refuse the connection.

Sorry, that's all i got.

thanks @nmrh I'm also skeptical it's the UDP Checksum because I have a lot of other traffic successfully traversing the path that's getting checksum errors. The only utilities I know at this point which do not work are test-ipv6 and phone registration / wifi calling.

Yes the firewall is running on the router. The router actually uses another carrier called FirstNet, it uses its own SIM and modem to connect. I was using that same modem and SIM on the previous router.

I don't have a network I can connect to at the moment to give me IPv6 address infos, but a trip into town will help with that. I'm headed that way tonight and can do some looking. With the configuration I have in place at the moment, my phone has 5 IPv6 addresses when I look at my wireless connection. I guess I've got a lot to learn about IPv6 cause that is confusing.

I assume you've contacted the Gov't/Law Enforcement Agency that issued the SIM about your service, correct?

(BTW, that's an MVNO of AT&T.)

I'm an individual subscriber. The organization I work for qualifies but does not have an enterprise account with FirstNet so I manage my own account individually. I have not yet been in touch with FirstNet but have found their IPv6 MTU advice and applied that to interfaces in the stream.

https://iotdevices.att.com/att-iot/FirstNetMTU.aspx

1 Like