[SOLVED] Some webpages/terminal connectivity works but not others.

archuser38013 · 2024-07-19 12:15:29

Previous title was: Not receiving ipv6 addresses for any interface all of a sudden.

I since found out that is not the issue and updated the title and so you can skip to the latest reply.

Not sure why this is happening.

I have a wifi connection which is ipv4 and ipv6 both, usually and this is my main connection. Internet still working normally via v4 route. I have 2 mobile dongles, the 3g one is still working fine but all of a sudden the 4g one will not make an internet connection and no IP is issued.

Only thing I can think of that I changed lately is setting /etc/resolv.conf to unmanaged in NetworkManager and set quad9 manually in the file.

As I write that, I am thinking this may be related to the issue? I put in there an ipv4 address 9.9.9.9 and an ipv6 address 2620:fe::fe.

As it happens the 4g dongle only issues ipv6 addresses however now it does not issue any ipv6 address. Not only that interface but my main wifi interface, which iirc correctly, used to issue both an ipv4 and an ipv6 now only issues the ipv4. In ip link for the 4g dongle it just says 'link/none' but ip -6 r shows a route of some kind but not working apparently.

So no ipv6 addresses issued for any interface that I can see.

I am unable to 'ping -6 X' for any address no matter the interface, be it 4g or wifi. So something up with all ipv6 routing it seems.

Is it because maybe the ip6 server in resolv.conf is dead? As above, I was unable to test this since I cannot ping -6 any address!

Also to note the 4g dongle does make the green flashing indicating it is connected and also with 'mmcli -m X' it shows a connection has been made. I am even able to 'ping archlinux.org' but loading a webpage or 'speedtest' report 'server not found' and 'network is unreachable' respectively.

It may be nothing to do with the resolv.conf change and I can't think how that would affect it not issuing ipv6 addresses. I did update a week or two ago so maybe that broke something and I just didn't notice until now since I was using the ipv4 route, which was unaffected, as my main connection.

Any more ideas how to diagnose and fix please?

Last edited by archuser38013 (2024-07-31 07:49:11)

archuser38013 · 2024-07-20 07:37:02

It appears after doing 'ip a' that in fact I do have an ip address.

I tested some connectivity again and some things work but not others.

'ping archlinux.org' works. 'wget archlinux.org' works. 'wget duckduckgo.com' doesn't work.

Also I am able to now ping ipv6 dns ips and they ping fine.

I can use pacman package manager fine from the terminal.

I just tried loading a webpage in firefox and it seems the issue is limited to certain sites, like with wget. I can load archlinux.org and browse around fine there. I was also able to load cloudflare.com.

So it seems the issue is limited to some blockage related to resolution somewhere along the line for those particular sites.

How to drill down the issue?

Last edited by archuser38013 (2024-07-20 07:38:17)

seth · 2024-07-20 11:15:37

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Chances are your IPv6 is link local or there's an issue w/ yoru IPv4 lease and you can only connect via IPv6 or whatnot.
So let's see what's actually the problem:

ip a; ip r
dig @8.8.8.8 duckduckgo.com
dig duckduckgo.com
ping -c3 duckduckgo.com
ping -c3 archlinux.org
ping -c3 8.8.8.8
ping -c3 2001:4860:4860::8888 # the last two are google DNS on IPv4 and IPv6

archuser38013 · 2024-07-20 14:04:17

seth wrote:

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Chances are your IPv6 is link local or there's an issue w/ yoru IPv4 lease and you can only connect via IPv6 or whatnot.
So let's see what's actually the problem:
ip a; ip r
dig @8.8.8.8 duckduckgo.com
dig duckduckgo.com
ping -c3 duckduckgo.com
ping -c3 archlinux.org
ping -c3 8.8.8.8
ping -c3 2001:4860:4860::8888 # the last two are google DNS on IPv4 and IPv6

Ip a:

2: wxxxxxxxxxxxxxx: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/none 
    inet6 2xxx:2xxx:1xxx:6xxx:4xxx:2xxx:dxxx:cxxx/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever

I have drill installed which does the same doesn't it? There is no 'ip r' route at all so as expected it doesn't complete:

$ drill @9.9.9.9 duckduckgo.com
Error: error sending query: Error creating socket

$ drill duckduckgo.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 59070
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; duckduckgo.com.	IN	A

;; ANSWER SECTION:
duckduckgo.com.	71	IN	A	xx.xxx.xxx.xxx

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 80 msec
;; SERVER: 2606:4700:4700::1112
;; WHEN: Sat Jul 20 14:07:43 2024
;; MSG SIZE  rcvd: 48

Something else to note is that I do remember before I wasn't having issues with accessing duckduckgo.com and I expect other ipv4 sites either. This is on my mobile device and it only issues ipv6. I have been informed it is resolved by cgnat.

What changed though is I recently set NetworkManager settings to unamanged for dns so that I could put different nameservers for privacy respecting ones, using quad9 and its respective ipv6 address in '/etc/resolve.conf'. Could this be the root of the issue? Before that NM had it set as '192.168.1.1'. Not sure how ipv6 would have been managed then though? Can ipv6 still access that address locally or what?

Also another point is that the ISP support advisor mentioned the other week they use cgnat and someone in another reply mentioned that you must use their own DNS in order for cgnat to work. I have no idea how that was working previously since I never set that explicitly but it seemed to work when it was set to the above local ip '192.168.1.1' in NM previously.

Last edited by archuser38013 (2024-07-20 14:25:50)

seth · 2024-07-20 15:43:36

Could this be the root of the issue?

Yes, you don't have an IPv4 lease at all. And no route.
https://wiki.archlinux.org/title/Networ … NS_servers

Ftr, there's absolutely no point in conceiling your interface name or the IPv4 of DDG

the ISP support advisor mentioned

At this point the problem has nothing to do w/ your ISP nor DNS

archuser38013 · 2024-07-21 08:22:42

seth wrote:

the ISP support advisor mentioned
At this point the problem has nothing to do w/ your ISP nor DNS

Well not necessarily because, as I mentioned, it worked the other day to load webpages without interruption until making these recent changes myself. Also had no ipv4 route or ipv4 then either, so the only thing that has changed is either from a recent system update and/or changing the nameservers/some other unspecified change to the system.

The cgnat thing is not a new change and would have been the case the whole time I have used this connection both while working and after it stopped working correctly.

For setting NM to use global custom nameservers should I then change the nameservers back to be managed by NM rather than unmanaged and via /etc/resolv.conf? So an either/or thing?

Last edited by archuser38013 (2024-07-21 08:29:17)

seth · 2024-07-21 08:36:09

Well not necessarily because

YOU DO NOT HAVE AN IPv4 LEASE. Period.

Whether there exists any problem beyond that remains to be seen - usually you'd get those via dhcp. Idk what you configured there wrt NM but if you want to set custom DNS the wiki explains how to do that and you're supposed to follow that approach and I suggest to undo whatever you did before.

If that doesn't fix it, we'll have to see a complete system journal (don't screw around in that, you can obfuscate public IPv6 addresses but don't just replace every number you're not usre what it is w/ "xxx" - the journal isn't supposed to contain sensitive data and afair NM even obfuscates IPv6 itself)

archuser38013 · 2024-07-21 08:43:40

seth wrote:

Well not necessarily because
YOU DO NOT HAVE AN IPv4 LEASE. Period.
Whether there exists any problem beyond that remains to be seen - usually you'd get those via dhcp. Idk what you configured there wrt NM but if you want to set custom DNS the wiki explains how to do that and you're supposed to follow that approach and I suggest to undo whatever you did before.
If that doesn't fix it, we'll have to see a complete system journal (don't screw around in that, you can obfuscate public IPv6 addresses but don't just replace every number you're not usre what it is w/ "xxx" - the journal isn't supposed to contain sensitive data and afair NM even obfuscates IPv6 itself)

Yea I know I don't have an ipv4 but that is the purpose of cgnat from what I have read isn't it? It translates ipv6 only addresses to ipv4.

I have managed to get the previous functionality back by removing the unmanaged DNS setting in NM and reloading and now /etc/resolv.conf states 192.168.1.1 as nameserver with the file having been edited by NM. So no idea how that has made it wor as in I don't know how that would allow this ipv6 to suddenly resolve ipv4s? Maybe isp will only accept that address to communicate with cgnat?

seth · 2024-07-21 08:47:11

That's not how this works, CGNAT is done by your ISP.
Your system doesn't even know where to send the IPv4 packages.

This also has nothing to do w/ the DNS resolver, try "drill @9.9.9.9 google.com"
As for configuring that, post the exact changes you made as well as the output of "resolvectl status"

archuser38013 · 2024-07-21 09:31:22

seth wrote:

That's not how this works, CGNAT is done by your ISP.
Your system doesn't even know where to send the IPv4 packages.
This also has nothing to do w/ the DNS resolver, try "drill @9.9.9.9 google.com"
As for configuring that, post the exact changes you made as well as the output of "resolvectl status"

I know it is done by the ISP but I was told by someone else that it might only work if using their nameservers and 192.168.1.1 is the router dns isn't it? So for the mobile dongle the 'router' would just send it to the ISP to resolve via cgnat no? I am just repeating what someone elsewhere wrote and that seems to be the behavior of not working to working seems to have followed that pattern, in line with the edit I made from unmanaged by NM and custom DNS, back to managed and default DNS.

sudo resolvectl status
Failed to get global data: Could not activate remote peer org.freedesktop.resolve1: activation request failed: unknown unit

$ drill @9.9.9.9 archlinux.org
Error: error sending query: Error creating socket

Last edited by archuser38013 (2024-07-21 09:34:03)

seth · 2024-07-21 14:02:33

Your DNS/resolvectl is broken.
Read https://wiki.archlinux.org/title/Networ … management and https://wiki.archlinux.org/title/Systemd-resolved and post the output of

stat /etc/resolv.conf
cat /etc/resolv.conf
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
systemctl status systemd-resolved
ps aux | grep resolv

Also please dont randomly sudo stuff (unless you're facing an explicit permission error)

archuser38013 · 2024-07-21 18:02:41

seth wrote:

Your DNS/resolvectl is broken.
Read https://wiki.archlinux.org/title/Networ … management and https://wiki.archlinux.org/title/Systemd-resolved and post the output of
stat /etc/resolv.conf
cat /etc/resolv.conf
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
systemctl status systemd-resolved
ps aux | grep resolv
Also please dont randomly sudo stuff (unless you're facing an explicit permission error)

Thanks for your patience. Commands in their respective order.

  File: /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
  Size: 39        	Blocks: 0          IO Block: 4096   symbolic link
Device: 179,2	Inode: 2098578     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-07-21 17:47:57.253385051 +0000
Modify: 2024-07-21 17:47:49.866717985 +0000
Change: 2024-07-21 17:47:49.866717985 +0000
 Birth: 2024-07-21 17:47:49.866717985 +0000
---
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .
---
dbus-fi.w1.wpa_supplicant1.service       | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.resolve1.service    | system
getty@tty1.service                       | getty.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
NetworkManager.service                   | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
systemd-resolved.service                 | sysinit.target.wants
systemd-userdbd.socket                   | sockets.target.wants
ufw.service                              | multi-user.target.wants
wpa_supplicant.service                   | multi-user.target.wants
---
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-07-21 17:35:44 UTC; 22min ago
 Invocation: a3b654ed3ca0477ab20a2e53f4f3d091
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
             https://systemd.io/WRITING_RESOLVER_CLIENTS
   Main PID: 8343 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 6899)
     Memory: 4.3M (peak: 4.9M)
        CPU: 301ms
     CGroup: /system.slice/systemd-resolved.service
             └─8343 /usr/lib/systemd/systemd-resolved
---
systemd+    8343  0.0  0.2  21388 12928 ?        Ss   17:35   0:00 /usr/lib/systemd/systemd-resolved
user        9356  0.0  0.0   3908  1920 pts/2    S+   17:58   0:00 grep --color=auto resolv

Last edited by archuser38013 (2024-07-21 18:03:31)

archuser38013 · 2024-07-21 18:12:37

Also:

$ drill @9.9.9.9 duckduckgo.com
Error: error sending query: Error creating socket
$ drill duckduckgo.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 53440
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; duckduckgo.com.      IN      A

;; ANSWER SECTION:
duckduckgo.com. 26      IN      A       52.142.124.215

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 34 msec
;; SERVER: 127.0.0.53
;; WHEN: Sun Jul 21 18:07:35 2024
;; MSG SIZE  rcvd: 48
$ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
  Current DNS Server: 2a00:23ee:0:8000::15
         DNS Servers: 2a00:23ee:0:8000::15 2a00:23ee:0:8000::16
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google
                      2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net
                      2001:4860:4860::8888#dns.google

Link 3 (wlp0s21f0u7i2)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (wwp0s21f0u2u3i4)
    Current Scopes: DNS LLMNR/IPv6 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 2a00:23ee:0:8000::15
       DNS Servers: 2a00:23ee:0:8000::15 2a00:23ee:0:8000::16

seth · 2024-07-21 20:36:37

So resolved is up, running and controls resolv.conf - but

resolvectl status

still casts an error??
The DNS is 127.0.0.53 where resolved is listening and it resolves from 2a00:23ee:0:8000::15 (British Telecommunications PLC, I guess your ISP)

resolvectl status
ip a; ip r # you can obfuscate your IPv6, but otherwise post all output
ip r get 9.9.9.9
ping -c3 9.9.9.9

archuser38013 · 2024-07-22 08:15:44

seth wrote:

So resolved is up, running and controls resolv.conf - but
resolvectl status
still casts an error??
The DNS is 127.0.0.53 where resolved is listening and it resolves from 2a00:23ee:0:8000::15 (British Telecommunications PLC, I guess your ISP)
resolvectl status
ip a; ip r # you can obfuscate your IPv6, but otherwise post all output
ip r get 9.9.9.9
ping -c3 9.9.9.9

No, resolved is working. I posted the output of 'resolvectl status' in the code block of the last reply.

$ ip a; ip r # you can obfuscate your IPv6, but otherwise post all output
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
10: wwp0s21f0u2u3i4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/none
    inet6 2xxx:2xxx:1xxx:7xxx:exxx:bxxx:2xxx:7xxx/64 scope global noprefixroute
       valid_lft forever preferred_lft forever

There is no output at all from 'ip r' just as always. Only 'ip -6 r'

$ ip r get 9.9.9.9
RTNETLINK answers: Network is unreachable
$ ping -c3 9.9.9.9
ping: connect: Network is unreachable

However check this out:

$ drill @9.9.9.9 duckduckgo.com
Error: error sending query: Error creating socket
$ drill duckduckgo.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 59341
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; duckduckgo.com.      IN      A

;; ANSWER SECTION:
duckduckgo.com. 171     IN      A       52.142.124.215

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 293 msec
;; SERVER: 127.0.0.53
;; WHEN: Mon Jul 22 08:18:26 2024
;; MSG SIZE  rcvd: 48

Doesn't that indicate that ipv4 resolution is being handled by the ISP, presumably with CGNAT?

Last edited by archuser38013 (2024-07-22 08:22:15)

-thc · 2024-07-22 13:40:55

archuser38013 wrote:

Doesn't that indicate that ipv4 resolution is being handled by the ISP, presumably with CGNAT?

No - it shows that systemd-resolved can resolve IPv4 records (A) using DNSv6 as the transport protocol.

seth · 2024-07-22 14:26:39

You still dont't have a IPv4 lease.
Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

archuser38013 · 2024-07-23 09:43:28

seth wrote:

You still dont't have a IPv4 lease.
Please post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st

Indeed. I was aware. The question is why and how it can still load ipv4 pages despite not having an ipv4 route.

This device is not plugged in on boot though so your suggested journactl command won't show anything will it?

I have ipv4 for all other devices, including the 3g dongle which uses ppp connection, except this 4g device.

I should plug it in and then run the journalctl command even if already booted?

Last edited by archuser38013 (2024-07-23 12:09:34)

seth · 2024-07-23 14:08:45

I should plug it in and then run the journalctl command even if already booted?

Yes.

archuser38013 · 2024-07-25 14:06:43

seth wrote:

I should plug it in and then run the journalctl command even if already booted?
Yes.

Without having to post all that output I can confirm that from the section below it says only ipv6 is allowed:

Jul 25 12:58:13 machine ModemManager[636]: <msg> [modem0] state changed (registered -> connecting)
Jul 25 12:58:14 machine ModemManager[636]: <msg> [modem0/bearer1] couldn't start IPv4 network: QMI protocol error (14): 'CallFailed'
Jul 25 12:58:14 machine ModemManager[636]: <msg> [modem0/bearer1]   verbose call end reason (6,51): [3gpp] ipv6-only-allowed
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0/bearer1] couldn't start IPv6 network: QMI protocol error (14): 'CallFailed'
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0/bearer1]   verbose call end reason (6,38): [3gpp] network-failure
Jul 25 12:58:15 machine ModemManager[636]: <wrn> [modem0/bearer1] connection attempt #1 failed: IPv6 only allowed
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] state changed (connecting -> registered)
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0/bearer1] connection #1 finished: duration 0s
Jul 25 12:58:15 machine ModemManager[636]: <wrn> [modem0] couldn't connect bearer: IPv6 only allowed
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect started...
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect state (6/10): register
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect state (7/10): wait to get packet service state attached
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect state (8/10): bearer
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect state (9/10): connect
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] state changed (registered -> connecting)
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0/bearer2] couldn't start IPv4 network: QMI protocol error (14): 'CallFailed'
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0/bearer2]   verbose call end reason (6,51): [3gpp] ipv6-only-allowed
Jul 25 12:58:15 machine ModemManager[636]: <wrn> [modem0/bearer2] connection attempt #1 failed: IPv6 only allowed
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] state changed (connecting -> registered)
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0/bearer2] connection #1 finished: duration 0s
Jul 25 12:58:15 machine ModemManager[636]: <wrn> [modem0] couldn't connect bearer: IPv6 only allowed
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect started...
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect state (6/10): register
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect state (7/10): wait to get packet service state attached
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect state (8/10): bearer
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] simple connect state (9/10): connect
Jul 25 12:58:15 machine ModemManager[636]: <msg> [modem0] state changed (registered -> connecting)
Jul 25 12:58:19 machine ModemManager[636]: <msg> [modem0/bearer3] QMI IPv6 Settings:
Jul 25 12:58:19 machine ModemManager[636]: <msg> [modem0/bearer3]     address: 2xxx:2xxx:1xxx:6xxx:axxx:2xxx:exxx:1xxx/64
Jul 25 12:58:19 machine ModemManager[636]: <msg> [modem0/bearer3]     gateway: 2xxx:2xxx:1xxx:6xxx:cxxx:1xxx:2xxx:2xxx/64
Jul 25 12:58:19 machine ModemManager[636]: <msg> [modem0/bearer3]     DNS #1: 2a00:23ee:0:8000::15
Jul 25 12:58:19 machine ModemManager[636]: <msg> [modem0/bearer3]     DNS #2: 2a00:23ee:0:8000::16
Jul 25 12:58:19 machine ModemManager[636]: <msg> [modem0/bearer3]        MTU: 1500
Jul 25 12:58:19 machine ModemManager[636]: <msg> [modem0] state changed (connecting -> connected)
Jul 25 12:58:19 machine ModemManager[636]: <msg> [modem0] simple connect state (10/10): all done
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2054] device (cdc-wdm0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2062] device (cdc-wdm0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jul 25 12:58:19 machine NetworkManager[471]: <warn>  [1721912299.2075] device (cdc-wdm0): retrieving IP configuration failed: modem IP method unsupported
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2076] modem-broadband[cdc-wdm0]: IPv6 base configuration:
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2076] modem-broadband[cdc-wdm0]:   address 2xxx:2xxx:1xxx:6xxx:axxx:2xxx:exxx:1xxx/64 lft forever pref forever lifetime 206-0[0,0] src unknown
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2077] modem-broadband[cdc-wdm0]:   slaac disabled
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2077] modem-broadband[cdc-wdm0]:   gateway 2xxx:2xxx:1xxx:6xxx:cxxx:1xxx:2xxx:2xxx
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2077] modem-broadband[cdc-wdm0]:   DNS 2a00:23ee:0:8000::15
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2077] modem-broadband[cdc-wdm0]:   DNS 2a00:23ee:0:8000::16
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2080] policy: set 'now-mob' (wwp0s21f0u2u3i4) as default for IPv6 routing and DNS
Jul 25 12:58:19 machine systemd-resolved[444]: wwp0s21f0u2u3i4: Bus client set default route setting: yes
Jul 25 12:58:19 machine systemd-resolved[444]: wwp0s21f0u2u3i4: Bus client set DNS server list to: 2a00:23ee:0:8000::15, 2a00:23ee:0:8000::16
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2140] device (cdc-wdm0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Jul 25 12:58:19 machine systemd[1]: Starting Network Manager Script Dispatcher Service...
Jul 25 12:58:19 machine systemd[1]: Started Network Manager Script Dispatcher Service.
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2637] device (cdc-wdm0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2640] device (cdc-wdm0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2646] manager: NetworkManager state is now CONNECTED_SITE
Jul 25 12:58:19 machine NetworkManager[471]: <info>  [1721912299.2651] device (cdc-wdm0): Activation: successful, device activated.

xxxxxxxxxxxxxxxxxxxxxxxx

$ sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="apn='<APN>',ip-type=4" --client-no-release-cid
error: couldn't start network: QMI protocol error (14): 'CallFailed'
call end reason (1): generic-unspecified
verbose call end reason (6,51): [3gpp] ipv6-only-allowed
[/dev/cdc-wdm0] Client ID not released:
        Service: 'wds'
            CID: '32'

Last edited by archuser38013 (2024-07-25 14:09:26)

seth · 2024-07-25 17:09:28

Hold on, you're not in a LAN - you're connecting to your ISP via an (LTE?) modem??
(Ok, the OP WoT actually mentions a 4g dongle)

https://wiki.archlinux.org/title/Mobile … IP_address
Otherwise you'll need some https://en.wikipedia.org/wiki/IPv6_transition_mechanism eg. https://wiki.archlinux.org/title/IPv6_t … oker_setup

Do yo get an IPv4 lease on other OS, eg some live distro?
What happens if you completely disable the IPv6 stack?

archuser38013 · 2024-07-26 14:10:45

seth wrote:

Hold on, you're not in a LAN - you're connecting to your ISP via an (LTE?) modem??
(Ok, the OP WoT actually mentions a 4g dongle)
https://wiki.archlinux.org/title/Mobile … IP_address
Otherwise you'll need some https://en.wikipedia.org/wiki/IPv6_transition_mechanism eg. https://wiki.archlinux.org/title/IPv6_t … oker_setup
Do yo get an IPv4 lease on other OS, eg some live distro?
What happens if you completely disable the IPv6 stack?

I haven't checked the other things but the modemmanager wiki troubleshooting point sounds like it might well be the issue. I am unable to update the firmware though as I specifically bought this older firmware version as in the more recent versions they totally change the functionality of the dongle to RDNIS meaning GSM connection is no longer possible.

When I do 'mmcli -m X -b 1' it shows the method as static rather than dhcp that the wiki suggests but it does show as GSM in nmcli and sms works as I would want.

I found that out first by having bought the same device new and coming up against that issue, and wasn't able to flash down to the lower version, which caused me to return it and look on the second hand market for one one older firmware which allowed GSM connection.

I want GSM capability to be able to use text functionality via the command line.

What do you mean by completely disabling the ipv6 stack? More than just setting the connection to down?

Also how do you surmise that ipv4 is able to be communicated with currently, with no ipv4 route, as has been discussed earlier?

Although I can access webpages it is still limiting for some things programs which expect and only work with v4 routing.

The tunnel broker seems to be from ipv4 to 6, not the other way round, from 6 to 4, which is what I want in my case.

Last edited by archuser38013 (2024-07-26 14:17:45)

seth · 2024-07-26 18:10:05

https://wiki.archlinux.org/title/IPv6#D … ctionality

Also how do you surmise that ipv4 is able to be communicated with currently, with no ipv4 route, as has been discussed earlier?

Do I? Is it? How? Where? Can you actually "ping 8.8.8.8"?
The question was whether you ISP and that dongle get you IPv4 access on any (other) system.

The tunnel broker seems to be from ipv4 to 6

Indeed, sorry - you're looking for sth. like https://en.wikipedia.org/wiki/4in6 or https://en.wikipedia.org/wiki/NAT64

archuser38013 · 2024-07-27 10:19:08

seth wrote:

https://wiki.archlinux.org/title/IPv6#D … ctionality
Also how do you surmise that ipv4 is able to be communicated with currently, with no ipv4 route, as has been discussed earlier?
Do I? Is it? How? Where? Can you actually "ping 8.8.8.8"?
The question was whether you ISP and that dongle get you IPv4 access on any (other) system.
The tunnel broker seems to be from ipv4 to 6
Indeed, sorry - you're looking for sth. like https://en.wikipedia.org/wiki/4in6 or https://en.wikipedia.org/wiki/NAT64

I can load ipv4 pages in the browser.

I can also ping ipv4 domain names in the terminal but pinging the ipv4 ips gives network is unreachable.

ping duckduckgo.com

Works.

ping 52.142.124.215

This one fails with network is unreachable.

As I said earlier in the thread this only became possible when I either set /etc/resolve.conf nameserver to 192.168.1.1 or when I later set NetworkManager back to managed and the nameserver now being 127.0.0.53. If I try to use any other nameservers than those two no connection to ipv4 addresses can be made. Doesn't this point to the isp resolving the ipv4? As I mentioned, having asked the isp support about something related but not specifically this at the time they happened to mention that ipv4 is resolved using cgnat.

Just reading about nat64 on the wiki. Would that then give me an ipv4 route locally? In most cases however it is working now to resolve ipv4 is fine for general browsing but some cases, like qemu bridges it expect ipv4 routing for certain vms. Also it would then let me change nameservers presumably once an ipv4 route was available as that is the only route which isn't working when using custom nameservers currently.

Last edited by archuser38013 (2024-07-27 10:32:12)

seth · 2024-07-27 12:01:16

ping duckduckgo.com

What's the output for that? You might be using https://en.wikipedia.org/wiki/IPv6_tran … nism#DNS64

Arch Linux

#1 2024-07-19 12:15:29

[SOLVED] Some webpages/terminal connectivity works but not others.

#2 2024-07-20 07:37:02

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#3 2024-07-20 11:15:37

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#4 2024-07-20 14:04:17

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#5 2024-07-20 15:43:36

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#6 2024-07-21 08:22:42

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#7 2024-07-21 08:36:09

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#8 2024-07-21 08:43:40

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#9 2024-07-21 08:47:11

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#10 2024-07-21 09:31:22

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#11 2024-07-21 14:02:33

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#12 2024-07-21 18:02:41

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#13 2024-07-21 18:12:37

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#14 2024-07-21 20:36:37

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#15 2024-07-22 08:15:44

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#16 2024-07-22 13:40:55

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#17 2024-07-22 14:26:39

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#18 2024-07-23 09:43:28

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#19 2024-07-23 14:08:45

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#20 2024-07-25 14:06:43

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#21 2024-07-25 17:09:28

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#22 2024-07-26 14:10:45

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#23 2024-07-26 18:10:05

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#24 2024-07-27 10:19:08

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#25 2024-07-27 12:01:16

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

Board footer