CLIs and certain applications do not receive internet connection through ethernet

I have a rather weird issue. Any application run through the terminal, be it ping, traceroute, java, etc. are unable to connect to the internet despite my ethernet connection. They work fine after connecting to a mobile hotspot through WiFi and are also able to connect after leaving the WiFi connection for a brief period, then proceed to be unable to connect. Most GUI applications (such as firefox and steam) are able to use my ethernet as normal.

In regards to the connection working after leaving WiFi, it is a little bit peculiar. I must disconnect from my ethernet connection, connect to wireless, then reconnect to ethernet and disconnect from wireless. Afterwards, everything works as normal for about a minute. I have no idea why.

inxi -Fazy                                                                                                                                                                                  
  Kernel: 6.1.41-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 13.1.1
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1-x86_64
    root=UUID=789b946b-49c3-4fa8-9664-a4df465487ab rw quiet splash
  Desktop: KDE Plasma v: 5.27.6 tk: Qt v: 5.15.10 wm: kwin_x11 vt: 2 dm: SDDM
    Distro: Manjaro Linux base: Arch Linux
  Type: Desktop System: Micro-Star product: MS-7B22 v: 2.0
    serial: <superuser required>
  Mobo: Micro-Star model: B360 GAMING PLUS (MS-7B22) v: 2.0
    serial: <superuser required> UEFI: American Megatrends v: 2.20
    date: 04/09/2018
  Info: model: Intel Core i7-8700K bits: 64 type: MT MCP arch: Coffee Lake
    gen: core 8 level: v3 note: check built: 2018 process: Intel 14nm family: 6
    model-id: 0x9E (158) stepping: 0xA (10) microcode: 0xF2
  Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache:
    L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 1.5 MiB desc: 6x256 KiB
    L3: 12 MiB desc: 1x12 MiB
  Speed (MHz): avg: 4377 high: 4393 min/max: 800/4700 scaling:
    driver: intel_pstate governor: powersave cores: 1: 4384 2: 4385 3: 4344
    4: 4386 5: 4390 6: 4393 7: 4384 8: 4382 9: 4371 10: 4364 11: 4376 12: 4374
    bogomips: 88824
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable
  Type: retbleed mitigation: IBRS
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
  Type: spectre_v2 mitigation: IBRS, IBPB: conditional, STIBP: conditional,
    RSB filling, PBRSB-eIBRS: Not affected
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort mitigation: TSX disabled
  Device-1: NVIDIA TU106 [GeForce RTX 2070 Rev. A] vendor:
    driver: nvidia v: 535.86.05 alternate: nouveau,nvidia_drm non-free: 535.xx+
    status: current (as of 2023-07) arch: Turing code: TUxxx
    process: TSMC 12nm FF built: 2018-22 pcie: gen: 3 speed: 8 GT/s lanes: 16
    bus-ID: 01:00.0 chip-ID: 10de:1f07 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.1.2
    compositor: kwin_x11 driver: X: loaded: nvidia gpu: nvidia display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 2560x1440 s-dpi: 110 s-size: 591x352mm (23.27x13.86")
    s-diag: 688mm (27.08")
  Monitor-1: DP-0 res: 2560x1440 dpi: 109 size: 598x336mm (23.54x13.23")
    diag: 686mm (27.01") modes: N/A
  API: OpenGL v: 4.6.0 NVIDIA 535.86.05 renderer: NVIDIA GeForce RTX
    2070/PCIe/SSE2 direct-render: Yes
  Device-1: Intel Cannon Lake PCH cAVS vendor: Micro-Star MSI
    driver: snd_hda_intel v: kernel alternate: snd_soc_skl,snd_sof_pci_intel_cnl
    bus-ID: 00:1f.3 chip-ID: 8086:a348 class-ID: 0403
  Device-2: NVIDIA TU106 High Definition Audio vendor:
    driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16
    bus-ID: 01:00.1 chip-ID: 10de:10f9 class-ID: 0403
  Device-3: Logitech Yeti Nano driver: hid-generic,snd-usb-audio,usbhid
    type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 1-11:5
    chip-ID: 046d:0ab1 class-ID: 0300 serial: <filter>
  Device-4: Logitech G733 Gaming Headset
    driver: hid-generic,snd-usb-audio,usbhid type: USB rev: 1.1 speed: 12 Mb/s
    lanes: 1 mode: 1.1 bus-ID: 1-14:7 chip-ID: 046d:0ab5 class-ID: 0300
  API: ALSA v: k6.1.41-1-MANJARO status: kernel-api with: aoss
    type: oss-emulator tools: alsactl,alsamixer,amixer
  Server-1: sndiod v: N/A status: off tools: aucat,midicat,sndioctl
  Server-2: JACK v: 1.9.22 status: off tools: N/A
  Server-3: PipeWire v: 0.3.75 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
  Device-1: Intel Ethernet I219-V vendor: Micro-Star MSI driver: e1000e
    v: kernel port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15bc class-ID: 0200
  IF: eno1 state: up speed: 100 Mbps duplex: full mac: <filter>
  Device-2: Qualcomm Atheros AR93xx Wireless Network Adapter vendor: Fujitsu
    driver: ath9k v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 bus-ID: 03:00.0
    chip-ID: 168c:0030 class-ID: 0280
  IF: wlp3s0 state: down mac: <filter>
  IF-ID-1: virbr0 state: down mac: <filter>
  Local Storage: total: 931.51 GiB used: 501.15 GiB (53.8%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: SSD 980 PRO 1TB
    size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 63.2 Gb/s
    lanes: 4 tech: SSD serial: <filter> fw-rev: 3B2QGXA7 temp: 50.9 C
    scheme: GPT
  ID-1: / raw-size: 614.47 GiB size: 603.75 GiB (98.26%)
    used: 499.34 GiB (82.7%) fs: ext4 dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-2: /boot/efi raw-size: 350 MiB size: 349.3 MiB (99.80%)
    used: 292 KiB (0.1%) fs: vfat dev: /dev/nvme0n1p2 maj-min: 259:2
  Kernel: swappiness: 60 (default) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 9.77 GiB used: 1.82 GiB (18.6%)
    priority: -2 dev: /dev/nvme0n1p7 maj-min: 259:7
  System Temperatures: cpu: 53.0 C pch: 55.0 C mobo: N/A gpu: nvidia temp: 64 C
  Fan Speeds (RPM): N/A gpu: nvidia fan: 49%
  Processes: 326 Uptime: 5d 17h 5m wakeups: 1 Memory: total: 32 GiB
  available: 31.29 GiB used: 6.68 GiB (21.4%) Init: systemd v: 253
  default: graphical tool: systemctl Compilers: gcc: 13.1.1 clang: 15.0.7
  Packages: 1630 pm: pacman pkgs: 1607 libs: 512 tools: pamac pm: flatpak
  pkgs: 23 Shell: Zsh v: 5.9 default: Bash v: 5.1.16 running-in: yakuake
  inxi: 3.3.28
inxi -N                                                                                                                                                                                     
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Qualcomm Atheros AR93xx Wireless Network Adapter driver: ath9k

Any help would be greatly appreciated!

Hi @mahso,

Please provide the output of:



ip route


Do you or have you perhaps connected to a VPN?

Here are the outputs:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway         UG    100    0        0 eno1   U     100    0        0 eno1
ip route                                                                                                                                                                                    
default via dev eno1 proto dhcp src metric 100 dev eno1 proto kernel scope link src metric 100 

I do use a VPN, however it is not active all the time. It being enabled or disabled has not changed the outcome of the connectivity, as it will still work only on wireless even with the VPN enabled.

This sounds like an xy problem.

You will have to power up the DeLorean and go back in time to the point where it actually work - then slowly forward the changes you have made until you hit the culprit.

That would be a likely explanation. Check your resolver config /etc/resolv.conf as it may not be reset correct when disconnecting from VPN.

I believe I actually have the point in time where it stopped working correctly!

My internet went out (ISP’s issue) and as such, I had to connect to my mobile hotspot in order to actually connect to the internet. VPN was not on, and wasn’t that entire day.

When the ISP fixed their internet, I was able to disconnect from the hotspot and continue using my ethernet. I hadn’t realized the CLI issue until I needed to run traceroute. That is when all the issues began.

I use IVPN, which creates a backup of the /etc/resolv.conf while it is active and swaps it back when the tunnel is disconnected. It resets to my normal resolv.conf afterwards, and the nameservers are correct for both.

That being said, even with the VPN enabled it does not allow CLIs to connect. It is only through my mobile hotspot that I’m able to connect at all.

The thing is - the network is up and functional or it is not.

I do however think your issue is DNS related.

Firefox can work around a dysfunctional DNS on its own - using DNS over HTTP to connect to OpenDNS.

Steam may be using IP adderesses or perhaps something like Firefox to query their own servers.

Perhaps you are using some kind of sandboxing - or you have used e.g. OpenSnitch or Portmaster to block outgoing ICMP traffic.

As you correctly address it is not normal - but it has nothing with Manjaro as OS - and I have no idea what configuration you may applied to achieve this :slight_smile:

I am not using any sort of sandboxing nor specific firewall rules that would block outgoing traffic, though I believe I do have some things to add that may help:

ping -c 3                                                                                                                                                                  
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=117 time=23.9 ms
64 bytes from icmp_seq=2 ttl=117 time=23.2 ms
64 bytes from icmp_seq=3 ttl=117 time=23.8 ms

--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 23.229/23.638/23.894/0.292 ms
ping -c 3                                                                                                                                                                         
PING (2001:470:142:5::116)) 56 data bytes

--- ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2035ms

It must be a DNS issue, though I have no idea what on earth would have caused it. So it is not directly a CLI only issue?

I agree with @linux-aarhus that this is probably an XY problem. Especially since,

…your routing looks fine to me. I also agree that it looks like a DNS problem. But since you said:

…so make sure it’s not conflicting between DNS resolvers.

I suggest you do a power cycle on your ISP router. At least 60s off - then power up.

1 Like

I have tried that already, to no avail.

They are both not conflicting, as they are both two separate nameservers.

ping -4 -c 3                                                                                                                                                              
PING  ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=48 time=48.4 ms
64 bytes from ( icmp_seq=2 ttl=48 time=50.7 ms
64 bytes from ( icmp_seq=3 ttl=48 time=49.2 ms

---  ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 48.379/49.409/50.665/0.946 ms
ping -6 -c 3                                                                                                                                                                        
PING (2001:470:142:5::116)) 56 data bytes

--- ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2019ms

So the IPv4 DNS works yet IPv6 does not? This has to be a DNS issue, but I have no idea why it would solely be affecting IPv6.

This does however make a fair bit of sense, as IVPN only uses IPv4 for its hostname resolution.

Me as well. And neither do I know anything to do with IPv6.

So I’m out. Sorry.


When you have issues related to IPv6 - I suggest you try disabling to see how it behave. Read more at IPv6 - ArchWiki.

Honestly, I completely understand. IPv6 is the IT boogeyman, you do not say its name unless you are dealing with issues not even the greatest tech wizards know how to fix …

Disabling IPv6 has, in fact, worked. Checking back on the original issue, the reason why connecting to wifi fixed these issues is because it forced the system to only use IPv4.

Cheers for helping with all this you two, have a great rest of your day :smiley:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.