Network routing: trying to troubleshoot random slowdown of traffic

archuser_9999 · 2019-08-20 08:39:28

If I've understood correctly, the output of

systool -v -m rtl8821ae is

Module = "rtl8821ae"

  Attributes:
    coresize            = "286720"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "0"
    srcversion          = "108DBF910BA5B5A1F81FDAF"
    taint               = ""
    uevent              = <store method only>

  Parameters:
    aspm                = "0"
    debug_level         = "0"
    debug_mask          = "0"
    disable_watchdog    = "N"
    fwlps               = "N"
    int_clear           = "Y"
    ips                 = "N"
    msi                 = "Y"
    swenc               = "Y"
    swlps               = "N"

and I see nothing there that looks like HW encryption - presumably it would be ...?

hwenc

I looked again through the modules

$ lsmod

Module                  Size  Used by
ccm                    20480  3
fuse                  135168  3
snd_hda_codec_hdmi     69632  4
nouveau              2310144  23
arc4                   16384  2
rtl8821ae             286720  0
snd_hda_codec_realtek   126976  1
btcoexist             217088  1 rtl8821ae
snd_hda_codec_generic    94208  1 snd_hda_codec_realtek
mxm_wmi                16384  1 nouveau
wmi                    36864  2 mxm_wmi,nouveau
intel_powerclamp       20480  0
ledtrig_audio          16384  2 snd_hda_codec_generic,snd_hda_codec_realtek
i2c_algo_bit           16384  1 nouveau
coretemp               20480  0
rtl_pci                36864  1 rtl8821ae
ttm                   118784  1 nouveau
snd_hda_intel          53248  5
rtlwifi               126976  3 rtl_pci,rtl8821ae,btcoexist
snd_hda_codec         159744  4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
drm_kms_helper        225280  1 nouveau
kvm_intel             311296  0
input_leds             16384  0
mousedev               24576  0
mac80211              999424  3 rtl_pci,rtl8821ae,rtlwifi
joydev                 28672  0
snd_hda_core          102400  5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
kvm                   770048  1 kvm_intel
drm                   503808  6 drm_kms_helper,ttm,nouveau
r8169                  98304  0
snd_hwdep              20480  1 snd_hda_codec
irqbypass              16384  1 kvm
agpgart                53248  3 ttm,nouveau,drm
snd_pcm               135168  4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
iTCO_wdt               16384  0
cfg80211              856064  2 rtlwifi,mac80211
iTCO_vendor_support    16384  1 iTCO_wdt
syscopyarea            16384  1 drm_kms_helper
realtek                20480  1
intel_cstate           16384  0
sysfillrect            16384  1 drm_kms_helper
snd_timer              40960  1 snd_pcm
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
i2c_i801               36864  0
intel_uncore          139264  0
snd                   110592  18 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
rfkill                 28672  3 cfg80211
libphy                 98304  2 r8169,realtek
soundcore              16384  1 snd
i5500_temp             16384  0
pcspkr                 16384  0
evdev                  24576  20
i7core_edac            28672  0
lpc_ich                28672  0
asus_atk0110           24576  0
pcc_cpufreq            20480  0
mac_hid                16384  0
acpi_cpufreq           28672  1
crypto_user            16384  0
ip_tables              36864  0
x_tables               49152  1 ip_tables
ext4                  770048  3
crc32c_generic         16384  0
crc16                  16384  1 ext4
mbcache                16384  1 ext4
jbd2                  135168  1 ext4
sr_mod                 28672  0
cdrom                  73728  1 sr_mod
sd_mod                 57344  6
hid_generic            16384  0
usbhid                 65536  0
uas                    28672  0
hid                   143360  2 usbhid,hid_generic
usb_storage            77824  1 uas
ata_generic            16384  0
pata_acpi              16384  0
uhci_hcd               53248  0
ata_piix               36864  4
libata                282624  3 ata_piix,pata_acpi,ata_generic
firewire_ohci          49152  0
scsi_mod              249856  5 sd_mod,usb_storage,uas,libata,sr_mod
crc32c_intel           24576  4
firewire_core          81920  1 firewire_ohci
crc_itu_t              16384  1 firewire_core
ehci_pci               20480  0
ehci_hcd               98304  1 ehci_pci

I note several things - which may or may not be relevant:

I dug through any that seem to bear in any way on wifi. Very few of them have any options to be set, however one that really shouted at me was

systool -v -m cfg80211

Module = "cfg80211"

  Attributes:
    coresize            = "856064"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "2"
    srcversion          = "0ABD3CD026ECE15C642DA40"
    taint               = ""
    uevent              = <store method only>

  Parameters:
    bss_entries_limit   = "1000"
    cfg80211_disable_40mhz_24ghz= "N"
    ieee80211_regdom    = "00"

  Sections:

Because here is that contentious "00" set as regdom. Yes, I realise that these things are packaged for global use but... I also happen to know that the French, not doubt like some others, are PARTICULARLY hot on things like the regulatory domain being implemented. So much so that, from my several years spent using other Linux distros (mainstream ones at that) I have found myself in situations where the wireless would not connect AT ALL but simply sit there with the notification wheel spinning away UNTIL I got into the config and edited it for "FR". And even then

$ iw reg get

global
country FR: DFS-ETSI
	(2402 - 2482 @ 40), (N/A, 20), (N/A)
	(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
	(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
	(5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
	(5725 - 5875 @ 80), (N/A, 13), (N/A)
	(57000 - 66000 @ 2160), (N/A, 40), (N/A)

shows both "global" and my country.

I just added a module parameter to cfg80211 my grub file as per the wiki (and which has successfully changed the params for rtl8821ae, but note that even now it has booted up with that ieee_regdom region flag unchanged at "00". This could be a part of the problem, even if a small one.

Beyond this I can find nothing in lsmod that suggests I can edit or enable HW encryption.

That said I shall try editing as per your answer above

archuser_9999 · 2019-08-20 16:06:52

I think I'm making more 'progress' - at least in terms of narrowing down the problem.

I believe the issue is actually connected to the ISO arch install! As a newbie I'm happy to be corrected, but being curious I've spent the day testing things out... here's where I'm at at time of writing:

I continued to note that whatever issues I am suffering on this main tower/desktop, my laptop in particular has NO issues whatsoever. So, whatever I might have been thinking about the physical layout of my network doesn't apply (I believe) since NO other device is having issues. I've also done a hard reset of the entire network.

I began looking at the routing tables and comparing across the machines, noting they seemed very different (considering how much Arch there is in Solus). So I flushed the table and the cache, believing it would be recreated on boot. I deleted the connection via the applet and rebooted. Surprised to see via "connection details" that I had IPV6 addresses assigned despite it only being a 6to4 assignment via the IPV table showed NOTHING.

So I set about adding a default route, then reboot. Still no joy - connection made in a jiffy when logging into DE but NO actual internet.

So.... I've come all the way back to a new install via the ISO. And here's what I've found interesting. I go through all the correct steps, setting up kbd, wpa_passphrase etc. and ntp server.

The boot script invokes a wait timer for starting dhcp on the ethernet card. Doh! What about those of us who don't have access to a wired connection? Still, it times out quickly.

I connect via wpa_supplicant, interface comes up, and I use

dhclient wlp6s0

because dhcpcd kept complaining about waiting for an IPV6 server (which there isn't) and then timing out. This gives me NO working connection. However much I fiddle, I can't ping out.

I take the link down, and deactivate entirely the ethernet port (enp) and redo. This time things work, and I get an IP address.

I can sort of ping the external network, and I can sort of ping the WAP but there's packet loss. I'm signed into the admin panel for the WAP on a second machine, so can tell when this one is connected and has IP assigned. But even at this stage the routing is broken - the ISO install cannot connect to ANY mirror, despite my having edited for all local first. If I use 'ip route show' I get a blank - nothing is returned. So I run "dhclient wlp6s0" and it returns "FILE exists". Now I run ip route show once more... and there's some routing information. However, I still cannot ping anything.

I note the "forward poll" error, plus iwconfig showed "Encryption Key:off" !!

I then set the wifi card state down, unload and reload the kernel module rtl8821ae to include swenc and at the same time set the power saving off. I then run the wpa_supplicant again with config (this time including the regdomain in the conf file) and...

NOW it connects, gives me no errors. I can contact the mirrors but the bitrate is incredibly low and so they all time out!

What I'm going to do is go next door and hard-wire it into the ethernet just to get the install done. However, I rather suspect that ALL of my woes are born of the fact that something in this ISO does not like either a) not using ethernet or b) does not properly configure some part of the connection/routing/resolving for wireless. So, after the install - which downloads very fast - and I disconnect from ethernet... suddenly all the connections break.

I noted earlier that while tinkering with ip route (before I reinstalled) that by deleting routes and restarting the connection it would add a default route with a metric of 20600! I would see "page loading" but no actual load. If I set this metric to 300, often a web page would appear.

I've no idea if I'm talking nonsense here, or have put two and two together to make 5, but it does seem that there's something about the basic installation, coupled with the fact that swenc is OFF as compiled, and that setting it ON during grub doesn't really help? I might see if it's possible to recompile that driver. Meanwhile, I go on scratching my head...

seth · 2019-08-20 16:48:38

"swenc" controls the software/hardware encryption. "swenc=1" enables software encryption, "swenc=0" (or omitting the parameter) turns back to HW encryption.
"dhcpcd -4" will only run IPv4, though this should not be an issue at all.

I then set the wifi card state down, unload and reload the kernel module rtl8821ae to include swenc and at the same time set the power saving off. I then run the wpa_supplicant again with config (this time including the regdomain in the conf file) and...
NOW it connects, gives me no errors.

This has nothing to do w/ the installation ISO, the kernel module has a bug or the HW doesn't react too well to one of the features you disabled (encryption, power mangement)

Since you seem to confirm that those parameters have a reproducable and significant impact on the situation, isolate the one(s) that really matter, then configure the kernel module to use that parameter (explained in one of the links I posted earlier)

archuser_9999 · 2019-08-23 16:40:00

So...

Waited until the new router/WAP arrived before trying anything further.

What I can confirm:

WAP works VERY very well. Set it up quickly and simply, gives me really quick ping times to:

the WAP, the Gateway router, and google plus/or any other site I want to ping. NO packet loss, and all in the 20ms - 40ms return times (that's quick for here).

I'd run a long ethernet patch cable to the computer so have had zero connectivity issues over the hard line, but of course need to get back onto wifi for the long term.

I'm satisfied that there are no major errors in things like the wifi driver, firmware etc. but feel that I now I need to be asking a different question. It's not so much "why is my wifi not working" (implying drivers, software or firmware) as, to the best of my current understanding it's working very well. Instead the question might be more along the lines of:

If the ethernet connection is completely trouble free and sufficiently fast, and if

the new WAP means I have zero issues 'pinging' the network and the outside world

WHY

as in

WHY???

when connected via wifi does my browser sit there merrily waiting with the "contacting <website>" or "establishing secure connection to..."

and which, if I leave it, just goes on indefinitely without ever actually connecting?

I have a small network widget monitoring the connection. I note that on ethernet I'd be grabbing pages by roughly 2.5mb/S (again that's quick for around here!), yet on the wireless I'm getting anything between about 1.2kb/S up to about 800kb/S.

A recent update means I've reordered the mirrorlist with all regional mirrors first. But when trying `pacman -Syu` I note that the refresh runs at a decent clip for about one third of the way but then slows down and finally grinds to a halt, causing pacman to switch to the next mirror. The behaviour repeats i.e. it's fine for about 30% of the download but then slows to a crawl followed by a timeout.

What I need to know is what questions ought I to be asking? What ought I to be investigating now as the major hurdle in my wireless connection?

Note that once again NO other machine on this network has similar issues, and as best I can tell my wireless card is working fine now.

Any ideas or suggestions as to what I should be looking at now?

archuser_9999 · 2019-09-03 17:24:03

Apologies for the late response. I came here to say I've resolved ALL wifi issues simply by replacing my PCM wireless card with my old one. The problematic one - the rtl8821ae chip - was a newer, more expensive card. I'd assumed it would improve things. It didn't!

I'd been zipping along on ethernet by means of a long patch cable, but realise I need to get back to wifi. So I simply shut down and swapped out the cards. No errors, no log messages, no slowdowns. Lovely!

A sincere thank you to all for the help and for helping guide a newbie. I've learned a lot, feel I have a better system as a result (because I've done a bit of system maintenance, and learned to check logs).

Arch Linux

#26 2019-08-20 08:39:28

Re: Network routing: trying to troubleshoot random slowdown of traffic

#27 2019-08-20 16:06:52

Re: Network routing: trying to troubleshoot random slowdown of traffic

#28 2019-08-20 16:48:38

Re: Network routing: trying to troubleshoot random slowdown of traffic

#29 2019-08-23 16:40:00

Re: Network routing: trying to troubleshoot random slowdown of traffic

#30 2019-09-03 17:24:03

Re: Network routing: trying to troubleshoot random slowdown of traffic

Board footer