WiFi Calling and response to UDP traffic

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello all!

First post here, and I have done days(actually weeks) of searching, but if this is in the wrong place or has already been covered, please let me know and I will be happy to move/read anything relevant.

Before we get into this, I am an IT guy with 20+ years of experience. I ran a pen testing company for years (where I was the lead tech), I own and teach in a post-secondary school that teaches networking and security, and I have a background in operating a myriad of networking systems. I say this to help you understand where I am coming from, and to let you know that you can get as "geeky" as you want with me, and I will understand, or ask if I don't.

OK, going to provide as much info as I can:

I have a ZBT device (WG-1608) running the WiFix firmware, which is OpenWRT with a couple additions.
This device has a Quectel RM502Q-AE installed, and all firmware/drivers/software are up to date. I use this to connect to a T-Mobile signal. I am using MBIM to communicate with the modem.
I also have a MoFi device that connects to the same signal. It works without any issues, except that it doesn't connect to 5G and thus is considerably slower. About 1/3 the speed of the ZBT.
The ZBT device is up the hill from my house, about 1/2 mile and 1400' of elevation and get's line of sight to the tower. It connects to a Point-to-Point link that sends the signal here(to the house), which then connects to a ubiquiti switch and several AP's. All the devices then connect through these AP's.

The issue is this:

WiFi calling will not enable from any phone in the house. I have several T-Mobile phones, an unlocked phone with a T-Mo SIM, an AT&T phone, and 2 Verizon phones. Also, I can not connect with UDP to another server I have setup in another location (I host a Valheim server, and it uses UDP, just in case that's somehow relevant). If I switch to the MoFi everything works flawlessly (albeit a lot slower), so I have isolated the problem to this device. If I connect directly to the ZBT with either WiFi or Ethernet, I experience the same issues, and if I replace the ZBT with the MoFi, everything works, thus ruling out any network issues, although the network setup is VERY basic anyway. I have also replaced the ZBT with another identical device to rule out a hardware issue, and they both have the same problem. Unless they both have the same hardware malfunction, which I find unlikely...

WiFi calling works by setting up an IPSEC tunnel to a remote server, which also uses UDP to establish the connection (ISAKMP+ESP). I have the firewall on the ZBT setup in it's default config, so the stateful setup should be facilitating this, but it apparently isn't. I have played with different settings to try to get this working, including NAT and different firewall rules, but at this point have reset everything back to stock. I also experience intermittent connectivity drops. For example if I watch download traffic, it will download for 1-2 secs, then stop for 1-2 secs then download again for 1-2 secs, then stop for 1-2 secs. This behavior repeats ad-nauseam.

I am completely out of ideas, and this is a last resort to make this post. Hoping someone out there has experienced this, or has a simple and easy solution I just haven't thought of! Any help is appreciated!!

Thanks in advance!

1 Like
2

Look, I don't have neither your level nor your length of experience, so I can't provide you with a step-by-step guide, but if the following is accurate:

shouldn't you be able to login there and trace where the UDP packets are going/why they are not reaching their destination (with tcpdump or whatnot)?

Maybe others will chime in with more practical recommendations. Good luck!

1 Like
3

what are these additions?

4

One is a ping test that will cause the modem to automatically reboot after 10 mins of down time, and I believe the other is a skin, although that may not be from them directly. Nothing that would cause interference with NAT-ing or firewalling.

5

Good idea, and I have done this to the extent possible. But once the traffic leaves your network there is no way to record that. Also, just for clarity, I can see the outbound connection attempting to establish, but there is never a reply... This is tricky terminology with UDP, given that it's connectionless, but it's the easiest way to describe it.

Thanks for the reply, and the good luck!

6

What version of OpenWrt is it based on? Often these vendors are working with a decade old base.. :pensive:

7

Are you sure the carrier isn't filtering the traffic?

8

Yes, there is another device (MoFi) connected to the same service that does not experience any issues. I wrote this above as well, but there's a lot to unpack up there... :slight_smile:

9

Good question, I hadn't looked into this. Here is the version, going to research this also and see how old it is.

From the Kernel log: OpenWrt GCC 7.5.0 r11278-8055e38794

10

can you try

cat /etc/openwrt_release

It's not clear to me what GCC 7.5.0 r11... means, I think it's about the version of GCC used to compile.

11

DISTRIB_RELEASE="19.07.6"
Is that more helpful?

1 Like
12

Yes, that means it's quite recent compared to what I feared (like it might be based on 2010 software). That's more or less the last stable release, the new stable release will be out any moment now.

13

Have you tried Quectel RM502Q-AE in LTE mode instead of 5G ?
What does tcpdump on both sides (Valheim server and WG-1608) show when trying to send UDP traffic between them ?

14

I hadn't tried switching to LTE mode, but I just did, and no change. I will setup a pcap on both sides later today and let you know. Although I suspect I will see the traffic go out, hit the server, reply, and then not get back through the firewall/NAT. Great ideas, though! I will post what I find later today.

Thanks!

15

OK, here is what the tcpdump shows from the router on my WWAN interface:
IP 192.0.0.2.64586 > valheimserver:port: UDP, length 512

This 192.0.0.2 address is NOT my public IP... which means to me there may be a NAT issue here (which is what I have suspected all along). Going to try some other things, will post any relevant results.

The Valheim server doesn't seem to be receiving the traffic at all! Trying to get in to the firewall on the Valheim server side to check that out(can't remember the creds), but when I test this through a VPN connection the traffic makes it just fine, and I am able to connect. Not sure what conclusions to draw from this yet. Will post more later after I have had time to think about it.

16

Where does the 192.0.0.2 IP address come from ?
Do you have NAT enabled
option masq '1'
in /etc/config/firewall for the zone where the wwan interface resides ?

17

That is the indication of Dual-Stack Lite, rfc6333
Here is more user-friendly description along with the diagram https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_(DS-Lite)

2 Likes
18

I do, and what's interesting is that other UDP based traffic destined for the web (443 or 80) seems to work without any issue.

19

Thank you for this!

Is there any way to turn this off? I mean... I love IPv6, but if it's going to cause me problems dual-stacking it, I certainly don't need it!

20

I don't think so. This is what ISPs are implementing globally across the network.
Maybe you need to install a package and make some configuration?
See https://openwrt.org/docs/guide-user/network/ipv6_ipv4_transitioning#dual-stack_lite_tunnel_ds-lite_ipv4_in_ipv6

Those ports are TCP, not UDP.

1 Like