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.
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!
What version of OpenWrt is it based on? Often these vendors are working with a decade old base.. 
Are you sure the carrier isn't filtering the traffic?
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... 
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
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.
DISTRIB_RELEASE="19.07.6"
Is that more helpful?
1 Like
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.
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 ?
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!
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.
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 ?
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
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.
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!
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
Actually, they're either. But not really what we're here to discuss.
See: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
So I read this, and installed the package, but it appears that to get this working I would need to know my ISP's AFTR... Which I don't... Do you know any way to find this? Also, willing to try it (I'll try almost anything at this point) but I don't think this is going to solve my problem.
I would try to sniff DHCPv6 packets and see if AFTR is there.
See also RFC 6334 - DHCPv6 AFTR Discovery - automatic address resolution in DS-Lite (Ipv6)