Networking issue with Connman (can't access websites, can't ping)

Happy New Year to everyone!

Unfortunately my Satelite with manjaro installed is testing my patience these days,so not a good New Year so far for me :frowning:

So long story short i had the "limited connectivity" issues for about couple of months now and i decided to follow this very detailed tutorial: Replace Network Manager with ConnMan by @tbg . However thing started to go bad again ,this time with Connman . At random times i cant access websites,cant ping anything,and only a reboot solves the problem until it reoccurs. Any help is much appreciated,thank you for your time!

inxi -Fxxxz

System:    Host: manjaro Kernel: 5.5.0-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 Desktop: KDE Plasma 5.17.4 
           tk: Qt 5.14.0 wm: kwin_x11 dm: SDDM Distro: Manjaro Linux 
Machine:   Type: Laptop System: TOSHIBA product: SATELLITE S50-B v: PSPQEE-002005GE serial: <filter> 
           Mobo: Type2 - Board Vendor Name1 model: Type2 - Board Product Name1 v: Type2 - Board Version serial: <filter> 
           UEFI: INSYDE v: 2.00 date: 12/02/2014 
Battery:   ID-1: BAT1 charge: 17.8 Wh condition: 23.5/44.1 Wh (53%) volts: 16.6/14.8 model: Panasonic PA5195U-1BRS 
           type: Li-ion serial: <filter> status: Charging cycles: 697 
           Device-1: hidpp_battery_0 model: Logitech Marathon Mouse/Performance Plus M705 serial: <filter> 
           charge: 100% (should be ignored) rechargeable: yes status: Discharging 
CPU:       Topology: Dual Core model: Intel Core i7-5500U bits: 64 type: MT MCP arch: Broadwell rev: 4 L2 cache: 4096 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19163 
           Speed: 798 MHz min/max: 500/3000 MHz Core speeds (MHz): 1: 798 2: 798 3: 798 4: 798 
Graphics:  Device-1: Intel HD Graphics 5500 vendor: Toshiba driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:1616 
           Display: x11 server: X.Org 1.20.6 driver: intel,modesetting FAILED: ati unloaded: amdgpu alternate: fbdev,vesa 
           compositor: kwin_x11 resolution: 1366x768~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2) v: 4.6 Mesa 19.3.1 compat-v: 3.0 
           direct render: Yes 
Audio:     Device-1: Intel Broadwell-U Audio vendor: Toshiba driver: snd_hda_intel v: kernel bus ID: 00:03.0 
           chip ID: 8086:160c 
           Device-2: Intel Wildcat Point-LP High Definition Audio vendor: Toshiba driver: snd_hda_intel v: kernel 
           bus ID: 00:1b.0 chip ID: 8086:9ca0 
           Sound Server: ALSA v: k5.5.0-1-MANJARO 
Network:   Device-1: Intel Wireless 3160 driver: iwlwifi v: kernel port: 6040 bus ID: 07:00.0 chip ID: 8086:08b3 
           IF: wlp7s0 state: up mac: <filter> 
           Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Toshiba driver: r8169 v: kernel port: 4000 
           bus ID: 08:00.0 chip ID: 10ec:8168 
           IF: enp8s0 state: down mac: <filter> 
Drives:    Local Storage: total: 111.79 GiB used: 28.11 GiB (25.1%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 120GB size: 111.79 GiB speed: 6.0 Gb/s serial: <filter> rev: 2B6Q 
           scheme: GPT 
Partition: ID-1: / size: 100.58 GiB used: 28.11 GiB (28.0%) fs: ext4 dev: /dev/sda2 
           ID-2: swap-1 size: 8.80 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3 
Sensors:   System Temperatures: cpu: 52.0 C mobo: N/A gpu: amdgpu temp: 43 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 208 Uptime: 4m Memory: 7.69 GiB used: 1.77 GiB (23.0%) Init: systemd v: 242 Compilers: gcc: 9.2.0 
           Shell: bash v: 5.0.11 running in: yakuake inxi: 3.0.37 


cat /etc/resolv.conf

Generated by Connection Manager
nameserver ::1
nameserver 127.0.0.1

Screenshot_20200105_145659

I see you are on the experimental kernel. Have you tested older kernels such as 4.19, 4.14, or the real time kernels.

If desired you can try to changing your default nameservers:

Make a backup of /etc/resolv.conf and remove any file write protection (if enabled):

sudo cp /etc/resolv.conf /etc/resolv.conf.bak && sudo chattr -i /etc/resolv.conf

Then, run the following command to auto-generate an /etc/resolv.conf file with Google as the DNS servers:

echo -e "nameserver 8.8.8.8\nsearch 8.8.4.4" | sudo tee /etc/resolv.conf

If desired, once you have completed the edits you can write protect the new resolv.conf (optional).

To write protect /etc/resolv.conf issue the following command::

sudo chattr +i /etc/resolv.conf

To restore /etc/resolv.conf to its original state issue the following command:

sudo chattr -i /etc/resolv.conf; sudo cp /etc/resolv.conf.bak /etc/resolv.conf 

Reboot after updating your nameservers.

i have tested this with 5.4.6-2,still the same. Never with a real time. The thing i forgot to mention is that i am using pi-hole device (rpi0w) for a dns server. I will try your solution and report back.

Kernel 5.4 currently is experiencing many networking issues especially with iwlwifi based Intel adapters. I would highly suggest testing kernels besides 5.4 & 5.5.

I see. So your suggestion is to change the kernel and keep the default nameservers ?

Either or, and or both, if neither changes things individually.

You could alternately test the cloudflare dns servers:

Run the following command to auto-generate an /etc/resolv.conf file with cloudflare as the DNS servers:

echo -e "nameserver 1.1.1.1\nsearch 1.0.0.1" | sudo tee /etc/resolv.conf

Reboot after updating your nameservers.

I wouldn't recommend an RT (Real time) kernel unless your doing media production, or any other timing sensitive work, where this would be a requirement. I would however suggest using the 4.19, or earlier, LTS (Long Term Support) kernels. Yes, I realize that the 5.4 kernel series has been marked as an LTS release by Manjaro, however, upstream kernel.org has yet to do so. Because of these issues, and some other regressions that have been reported, I would wait until they get sorted out. Basically, find the best LTS kernel series that is the most stable, and reliable, for your hardware and stick with that. "Newer is not always better."

That is quite important.

Not using pi-hole but still - I am using a default raspbian as DNS using root-servers. If my network becomes unresponsive with dns lookup it is usually my pi acting up.

You need to verify - preferably from a ssh terminal into your pi-hole - that DNS queries does in fact work - or not.

Then you can turn to trouble shooting the OS.

Yes you're right. However,if the problem was pi-hole ,every other device in my network should have issues,at least in my opinion. I'm only experiencing issues on the manjaro laptop.

Switched to 4.19.91-1 .So far,so good. I'm wondering should i revert the changes i made with Connman and return to NetworkManager? Would that make any sense? @tbg whats your opinion?

As hardened sysadmin - I take the shortest path possible. Start the root of DNS queries and work towards the client. Learned the hard way :slight_smile: - in my younger days I always bugged with client.

If the DNS is the router - reboot the router - then check one more time after reboot. Then you can concentrate. Eliminate the broadest scope first.

1 Like

Makes sense to me, plasma-nm is the native way to go. :wink:

1 Like

In my opinion, if NM creates no problems for you then I would return to using it as it is the default in almost every version of Manjaro. This makes troubleshooting easier when searching for a solution from past forum posts.

You can always keep Connman installed, (but masked) in case you need it again in the future.

On a side note, with regards to the Real Time kernels. I felt the same about them not being worth testing in the past. I have however changed my opinion. There are times when kernel regressions hit the mainline kernels that are not present in the real time kernels (yet).

This temporarily solves some issues that could cause major problems until the main kernels recieved fixes. I have seen the real time kernels solve issues with Bluetooth and freezing fairly recently so they do serve a purpose. I am currently using a real time kernel because of issues with freezing and it runs very well on my old computer.

A lot of computers do not run well with a real time kernel, but for others it is a real life saver in making the machine usable.

2 Likes

Coming back to report that nothing helped. I am on 4.19.112-1 now and I have no connection.
Trying to ping my router on 192.168.1.1 and I get the "Destination Host Unreachable" message.

Any help would be VERY appreciated, because it's very frustrating to reboot every time this happens.

Thanks in advance.

If you are still experiencing dropped connections then test these fixes:



Disable MAC Address Randomization with the following command:

echo -e "[device]\nwifi.scan-rand-mac-address=no" | sudo tee /etc/NetworkManager/conf.d/disable-random-mac.conf


Disable Network Manager's WiFi power saving features with the following command:

echo -e "[connection]\nwifi.powersave = 0" | sudo tee /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

A setting of "0" will totally disable power saving features in the WiFi adapter.

A setting of "2" or "1" will be less aggressive, but still leave power saving enabled.



Try locking your Wifi connection to your AP's SSID in network manager.

You can do this in Network Manager's "Wi-Fi" tab in your WiFi connection's properties settings.

There is a "BSSID" drop down field where you can select and lock your home Wi-Fi to a single BSSID.



After modifying Network Manager's configuration, reboot both your router and your computer.



Another good troubleshooting step is to temporarily disable the tlp power manager.

sudo systemctl mask tlp.service

sudo systemctl mask tlp-sleep.service

Reboot after those changes.

If there is no improvement you can re-enable tlp by repeating those commands using "unmask" instead of "mask".



1 Like

Tried everything you told me to and nothing helped unfortunately. This is the first time im considering switching back to Windows after 6 years of daily Linux experience.Anyway,thank you very much for your time .

It is possible that adding extra iwlwifi driver options will help correct the dropped connections.

See this post for how to test the iwlwifi driver options:



This service is a last resort and definitely not a real fix, but this service works very well to maintain a connection. I have use this service I wrote in the past and it will automatically restart a downed connection within seconds. Depending on your network activities and the frequency of the dropped connections this can be quite a good workaround.

If you do online gaming this is obviously not going to be very satisfactory for you. However, for most other online activities it can make your connection quite passable to use. The continuous ping used in the script is sometimes enough to keep a connection from dropping.

The script of course needs to be modified to reflect your personal network components. You can also incorporate any driver options that you find improve your connectivity into the modprobe command in the script. For your system it should go something like this (without extra driver options):

With a text editor create:

Network Restart Script:

/usr/local/sbin/network_restart.sh

network_restart.sh script contents:

#!/bin/bash
# to terminate running service & script:  sudo systemctl stop network-restart.service && sudo killall -9 network_restart
#/usr/local/sbin/network_restart.sh
while true; do
     ping -c 1 8.8.8.8  | grep received
     if [ $? -eq 0 ]; then sleep 2
else
 echo "Connection broken, restarting network connection"
    /bin/sh -c 'nmcli networking off'
      systemctl stop NetworkManager
       ip link set wlp7s0 down
       lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs sudo rmmod
       sleep 1
       modprobe iwlwifi
       sleep .5
       ip link set wlp7s0 up
       sleep .5
       systemctl start NetworkManager
      /bin/sh -c 'nmcli networking on'
     /bin/sh -c 'nmcli r wifi off'
    sleep .5
   /bin/sh -c 'nmcli r wifi on'
  sleep 10
 break
fi
done
exec "$ScriptLoc"/usr/local/sbin/network_restart.sh && exit

Make the script executable:

sudo chmod +x /usr/local/sbin/network_restart.sh

The service is as follows:

Network Restart Service:

With any root capable text editor create the systemd service file:

/etc/systemd/system/network-restart.service

With the following contents:

# to terminate running service & script:  sudo systemctl stop network-restart.service && sudo killall -9 network_restart
#/etc/systemd/system/network-restart.service
#sudo systemctl enable network-restart.service
#sudo systemctl start network-restart.service
#sudo systemctl stop network-restart.service
#sudo systemctl disable network-restart.service
#systemctl status network-restart.service
#sudo systemctl daemon-reload

[Unit]
Description=Network Restart Service 
WantedBy=network.target 

[Service]
User=root
Type=simple
Restart=always
RestartSec=3
RemainAfterExit=yes
Restart=on-failure
StartLimitIntervalSec=0
ExecStartPre=-sleep 15
ExecStart=/usr/local/sbin/network_restart.sh

[Install]
WantedBy=network.target

Once you have created and saved the service file, enable the service:

sudo systemctl enable network-restart.service


For full details on the script and service read:



thank you for your time. Unfortunately nothing made any difference at all. Still having the limited connectivity issues. I tried fedora 31 and the moment the connection dropped i had a window with some problem details :

A kernel problem occurred, but your kernel has been tainted (flags:GI). Explanation:
I - Working around severe firmware bug.
Kernel maintainers are unable to diagnose tainted reports.
WARNING: CPU: 1 PID: 0 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2084 iwl_trans_pcie_grab_nic_access+0x1e9/0x220 [iwlwifi]
Modules linked in: ccm ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_conexant snd_hda_codec_generic kvm ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec irqbypass snd_hda_core iwlmvm snd_hwdep crct10dif_pclmul crc32_pclmul snd_seq iTCO_wdt mac80211 iTCO_vendor_support mei_hdcp snd_seq_device ghash_clmulni_intel libarc4 snd_pcm intel_cstate iwlwifi intel_uncore intel_rapl_perf pcspkr wmi_bmof joydev toshiba_acpi snd_timer cfg80211 sparse_keymap i2c_i801 snd mei_me industrialio lpc_ich toshiba_bluetooth mei soundcore
 rfkill acpi_pad ip_tables amdgpu i915 amd_iommu_v2 gpu_sched ttm rtsx_pci_sdmmc i2c_algo_bit mmc_core hid_logitech_hidpp drm_kms_helper drm crc32c_intel r8169 serio_raw rtsx_pci hid_logitech_dj wmi video fuse
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G          I       5.5.11-200.fc31.x86_64 #1
Hardware name: TOSHIBA SATELLITE S50-B/Type2 - Board Product Name1, BIOS 2.00 12/02/2014
RIP: 0010:iwl_trans_pcie_grab_nic_access+0x1e9/0x220 [iwlwifi]
Code: 8e fa 49 8d 56 08 bf 00 20 00 00 e8 81 b1 1b f9 e9 36 ff ff ff 89 c6 48 c7 c7 c8 b0 f6 c0 c6 05 59 4d 03 00 01 e8 99 ce 19 f9 <0f> 0b e9 f1 fe ff ff 48 8b 7d 38 48 c7 c1 30 b1 f6 c0 31 d2 31 f6
RSP: 0018:ffffb7ed00108dd0 EFLAGS: 00010086
RAX: 0000000000000000 RBX: ffffb7ed00108e00 RCX: 0000000000000007
RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffff9c4456c99cc0
RBP: ffff9c444f760028 R08: 0000000000000414 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffff9c444f76976c R14: 00000000ffffffff R15: 000000000000000a
FS:  0000000000000000(0000) GS:ffff9c4456c80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc6fd4ec970 CR3: 000000004260a004 CR4: 00000000003606e0
Call Trace:
 <IRQ>
 iwl_read_prph+0x34/0x90 [iwlwifi]
 iwl_trans_pcie_log_scd_error+0x13a/0x210 [iwlwifi]
 iwl_pcie_txq_stuck_timer+0x46/0x70 [iwlwifi]
 ? iwl_pcie_clear_cmd_in_flight+0x60/0x60 [iwlwifi]
 call_timer_fn+0x2d/0x130
 __run_timers.part.0+0x16f/0x260
 ? timerqueue_add+0x96/0xb0
 ? enqueue_hrtimer+0x36/0x90
 run_timer_softirq+0x26/0x50
 __do_softirq+0xee/0x2ff
 irq_exit+0xe9/0xf0
 smp_apic_timer_interrupt+0x76/0x130
 apic_timer_interrupt+0xf/0x20
 </IRQ>
RIP: 0010:cpuidle_enter_state+0xc9/0x3e0
Code: e8 5c e1 8e ff 80 7c 24 0f 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 ea 02 00 00 31 ff e8 6e 35 95 ff fb 66 0f 1f 44 00 00 <45> 85 ed 0f 88 40 02 00 00 49 63 d5 4c 2b 64 24 10 48 8d 04 52 48
RSP: 0018:ffffb7ed000c3e68 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: ffff9c4456caae00 RBX: ffff9c4456cb5e28 RCX: 000000000000001f
RDX: 0000000000000000 RSI: 000000003574f210 RDI: 0000000000000000
RBP: ffffffffbb74eec0 R08: 000000261e9927bd R09: 0000000000000346
R10: 000000000000023d R11: ffff9c4456ca9be4 R12: 000000261e9927bd
R13: 0000000000000005 R14: 0000000000000005 R15: ffff9c445556cd00
 ? cpuidle_enter_state+0xa4/0x3e0
 cpuidle_enter+0x29/0x40
 do_idle+0x1e4/0x280
 cpu_startup_entry+0x19/0x20
 start_secondary+0x162/0x1b0

Might be helpful?
Thanks again @tbg

Reinstall the linux firmware package (and reboot after any firmware changes).

If that is no better, then try downgrading the linux firmware package.

Test older linux firmware packages up to a year old.

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

Forum kindly sponsored by