Also after a restart, the 4G interface is not coming up since we saved the APN in the modem as well. I also do not find a real error in the system log. For me it looks like it's not able to get a IPv4 adress anymore.
Wed Oct 18 18:33:07 2023 daemon.notice netifd: Interface '4G' is setting up now
Wed Oct 18 18:33:07 2023 daemon.notice netifd: Interface 'loopback' is enabled
Wed Oct 18 18:33:07 2023 daemon.notice netifd: Interface 'loopback' is setting up now
Wed Oct 18 18:33:07 2023 daemon.notice netifd: Interface 'loopback' is now up
Wed Oct 18 18:33:07 2023 daemon.notice netifd: Network device 'eth0' link is up
Wed Oct 18 18:33:07 2023 daemon.notice netifd: Network device 'lo' link is up
Wed Oct 18 18:33:07 2023 daemon.notice netifd: Interface 'loopback' has link connectivity
Wed Oct 18 18:33:07 2023 daemon.notice netifd: 4G (1858): Waiting for SIM initialization
Wed Oct 18 18:33:08 2023 kern.info kernel: [ 40.659677] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
Wed Oct 18 18:33:09 2023 daemon.info procd: - init complete -
Wed Oct 18 18:33:09 2023 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Wed Oct 18 18:33:11 2023 daemon.notice netifd: 4G (1858): Failed to parse message data
Wed Oct 18 18:33:12 2023 daemon.notice netifd: 4G (1858): Device does not support 802.3 mode. Informing driver of raw-ip only for wwan0 ..
Wed Oct 18 18:33:12 2023 daemon.notice netifd: 4G (1858): Waiting for network registration
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: exiting on receipt of SIGTERM
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: started, version 2.89 cachesize 1000
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: DNS service limited to local subnets
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: UBus support enabled: connected to system bus
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq-dhcp[1]: DHCP, IP range 192.168.8.100 -- 192.168.8.249, lease time 12h
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: using only locally-known addresses for test
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: using only locally-known addresses for local
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Wed Oct 18 18:33:14 2023 daemon.warn dnsmasq[1]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 4 names
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Wed Oct 18 18:33:14 2023 daemon.notice netifd: 4G (1858): Starting network 4G
Wed Oct 18 18:33:14 2023 daemon.notice netifd: 4G (1858): Unable to connect IPv4
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.8.244 cc:96:xx:xx:xx:xx
Wed Oct 18 18:33:14 2023 daemon.warn dnsmasq-dhcp[1]: Ignoring domain some-domain.net for DHCP host name some-host
Wed Oct 18 18:33:14 2023 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.8.244 cc:96:xx:xx:xx:xx some-host
Wed Oct 18 18:33:15 2023 daemon.notice netifd: 4G (2278): Stopping network 4G
Wed Oct 18 18:33:15 2023 daemon.notice netifd: 4G (2278): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "4G" } (Permission denied)
Wed Oct 18 18:33:15 2023 daemon.notice netifd: Interface '4G' is now down
It fails one step before the address is obtained, the modem cannot bring an IPv4 connection up.
Can you check on the phone which addresses are obtained (v4, v6) and which APN is used?
These are the APN settings used when I put the sim card into my phone:
Name: Internet
APN: internet v6 telekom
Proxy: Not set
Port: Not set
Username: telekom
Password: ******
Server: Not set
MMSC: Not set
MMS proxy: Not set
MMS port: Not set
MCC: 262
MNC: 01
Authentication type: PAP
APN type: default.supl
APN protocol: IPv4/IPv6
APN roaming protocol: IPv4
Enable/disable APN: APN enabled.
Bearer: Unspecified
Mobile virtual network operator type: None
Mobile virtual network operator value: Not set
According to my mobile that are my IP addresses:
IP address
2a01 599 619.7f5d ec27:1b96:54fe49c7
192.0.0.4
Obviously, my IP4 address isn't public on my phone
Is it possible that the lack of a public IPv4 address is a possible reason for the problems? But as far as I know that is common nowadays.
There seems to be a historical APN (internet.t-d1.de) which is not officially supported anymore but that gives users a public IPv4 address only. I tried it on my phone and it worked fine there. Maybe it's worth a try but I would need to set it in the modem and in the settings now, right?
Well, then it is IPv6 only and you need to change IPV4V6 to IPV6, on the modem itself and in the interface configuration.
Then you will need to install 464xlat package for IPv4 support.
I changed the settings in on the interface and within the modem:
root@TL-MR6400:~# echo "05c6 9025 ff" > /sys/bus/usb-serial/drivers/option1/new_id
root@TL-MR6400:~# picocom /dev/ttyUSB2
picocom v3.1
port is : /dev/ttyUSB2
flowcontrol : none
baudrate is : 9600
parity is : none
databits are : 8
stopbits are : 1
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
hangup is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv -E
imap is :
omap is :
emap is : crcrlf,delbs,
logfile is : none
initstring : none
exit_after is : not set
exit is : no
Type [C-a] [C-h] to see available commands
Terminal ready
AT+CGDCONT?
+CGDCONT: 1,"IPV4V6","internet.v6.telekom","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0
OK
AT+CGDCONT=1,"IPV6","internet.v6.telekom"
OK
AT+CGDCONT?
+CGDCONT: 1,"IPV6","internet.v6.telekom","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0
OK
Terminating...
Thanks for using picocom
Now I got IPv6 connectivity
root@TL-MR6400:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
ping: sendto: Network unreachable
root@TL-MR6400:~# nslookup openwrt.org
Server: 127.0.0.1
Address: 127.0.0.1:53
Non-authoritative answer:
Name: openwrt.org
Address: 2a03:b0c0:3:d0::1af1:1
Non-authoritative answer:
Name: openwrt.org
Address: 139.59.209.225
root@TL-MR6400:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
ping: sendto: Network unreachable
root@TL-MR6400:~# ping google.com
PING google.com (2a00:1450:4016:80c::200e): 56 data bytes
64 bytes from 2a00:1450:4016:80c::200e: seq=0 ttl=115 time=40.051 ms
64 bytes from 2a00:1450:4016:80c::200e: seq=1 ttl=115 time=24.583 ms
64 bytes from 2a00:1450:4016:80c::200e: seq=2 ttl=115 time=24.226 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 24.226/29.620/40.051 ms
root@TL-MR6400:~# ping n-tv.de
PING n-tv.de (2600:9000:2057:4800:a:8b4a:4700:93a1): 56 data bytes
64 bytes from 2600:9000:2057:4800:a:8b4a:4700:93a1: seq=0 ttl=53 time=34.173 ms
64 bytes from 2600:9000:2057:4800:a:8b4a:4700:93a1: seq=1 ttl=53 time=23.137 ms
64 bytes from 2600:9000:2057:4800:a:8b4a:4700:93a1: seq=2 ttl=53 time=20.784 ms
^C
--- n-tv.de ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 20.784/26.031/34.173 ms
But IPv4 seems still to be a problem. I can't open web pages within my browser and I can't ping IPv4 addresses on the internet. I installed the 464xlat package and I rebooted the device. Is there anything else I need to configure to get this work?
For whatever reason DNS64 is not working as well as discovery of Pref64 that is needed for 464xlat to work.
Do you use any custom DNS in your setup?
What are the addresses of your DNS servers that are received from the carrier?
If you will repeat the previous test using google's DNS64 you should get different results:
The last one should provide you a synthetic IPv6 address for this IPv4-only host, that address should be pingable.
You can add option ip6prefix '64:ff9b::/96' to your CLAT interface configuration, this should allow the interface to work (assuming your provider is using this standard prefix).
I use T-Mobile USA and it looks like the situation is basically the same. The important thing is that every packet going into the modem and over the air must be v6. The 192.0.0.4 interface that you saw on the phone is a local 464xlat within the phone OS. That needs to be recreated in OpenWrt.
Check your v4 routing table. A default route must of course exist, and be through the 464 device.
option iface_464xlat 'name' may need to be added to the wan6 configuration. I'm not sure how that works with a directly connected qmi LTE modem.
Regarding DNS64, in my understanding, it is optional - CLAT will translate any outgoing TCP connections from IPv4 to IPv6. DNS64 is needed in the (broken) situation when CLAT does not exist, to convince applications to connect via IPv6 in the first place.
I would recommend installing tcpdump and capturing the traffic while redoing the google.com experiments:
tcpdump -vpni wwan0
and the same for the CLAT interface. Terminate tcpdump with Ctrl+C after testing the Google connection attempt.
Or even better, save the traffic into a file and share it (if you don't care that your router's IPv6 address becomes known to the forum readers):
On paper, you are right. However, I had two cases where I had to work around the A → AAAA translation or its limitations in an IPv6-only network with NAT64. No OpenWrt was involved, just a Linux laptop, but still, let me present them.
Case 1: I needed to connect to an IKEv2 VPN that only had an IPv4 endpoint and, helpfully, a DNS name pointing to it and mentioned in the certificate. The problem is that, behind the NAT, ESP must be encapsulated into UDP (and therefore, UDP packets on port 4500 must be sent to the IPv4 address of the VPN server, which then, due to DNS64, translates into the need to send such UDP packets to 64:ff9b::something), but, at that time, Linux refused to do such ESP-in-UDP encapsulation for IPv6. Solution: a third-party DNS without DNS64 translation + clatd.
Case 2: Browsers, increasingly, try to promote private DNS in general and DNS over HTTPS in particular, to the point that they no longer use the system DNS resolver. So, no DNS64 for them. Solutions: either disabling private DNS while in this network, or running clatd so that they are happy with connecting to IPv4 addresses obtained from DoH.
CLAT / 464 requires DNS64 available through its host during its startup while it probes for the NAT64 prefix needed. During usage the DNS can be v4 only since the purpose is to support v4 only applications.
464xlat is not well documented in how it is configured or how it sets itself up. In my setup it for the most part "just worked", but 464 stops working every time the LTE connection drops and comes back with a different /64 prefix.
Yes, @Tobias has named it "4G" but my suggestion still applies.
I'm not creating any rule, this is about configuring the existing wan zone. This seems to be needed to allow 464xlat to work properly.
I can reproduce Tobias' current issue without this setting on my own TL-MR6400.
Thank you very much to everyone that tries to help me. I really appreciate your help and I will reply soon. I am just not close to the device at the moment but expect that I can continue working on it tomorrow
