Intel Wireless 9560 - High latency on WIFI

supiri · 9 December 2020 16:01

I switched to Garuda a few days ago after using Manjaro exclusively for almost 2 years, apart from few Nvidia related issues my experience with Garuda was pretty good but today I noticed a strange issue with my wifi card.

I have a 4G router and Fiber connection (which I connect to via ethernet cable), for the last few days I have only been using a fiber connection and today I tried to switch to the 4G router (via WIFI) and I noticed my internet is extremely slow. So I tried connecting to the router from my phone and in that connection worked fine.

Then I ran ping against my router's IP found out it has extremely High latency, note that the router sits like 50 centimeters away from the laptop.

❯ ping 192.168.1.1                                                                                                                                        97%  ─╯
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=2089 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1870 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=847 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=0.916 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=1.82 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=2052 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=1.77 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=0.842 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=3.99 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=1.06 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=1951 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=928 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=64 time=8.03 ms
64 bytes from 192.168.1.1: icmp_seq=48 ttl=64 time=0.731 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=64 time=2049 ms
64 bytes from 192.168.1.1: icmp_seq=62 ttl=64 time=2.28 ms
^C
--- 192.168.1.1 ping statistics ---
62 packets transmitted, 16 received, 74.1936% packet loss, time 62257ms
rtt min/avg/max/mdev = 0.731/737.960/2089.107/899.352 ms, pipe 3

I tried disabling Wifi power save and MAC address randomization on Garuda Network Assistant but it didn't help. When I connect to my router via LAN cable it works without an issue.

❯ inxi -Fxxza                                                                                                                                             97%  ─╯
System:    Kernel: 5.9.12-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 10.2.0 
           parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen root=UUID=c1ed7ada-65d9-457d-b3fc-1915453c8b16 rw 
           rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 
           systemd.unified_cgroup_hierarchy=1 resume=UUID=cae05301-3b3a-469d-832c-8e526c83468d loglevel=3 
           Desktop: KDE Plasma 5.20.4 tk: Qt 5.15.2 info: latte-dock wm: kwin_x11 dm: SDDM Distro: Garuda Linux 
Machine:   Type: Laptop System: ASUSTeK product: ROG Strix G531GT_G531GT v: 1.0 serial: <filter> 
           Mobo: ASUSTeK model: G531GT v: 1.0 serial: <filter> UEFI: American Megatrends v: G531GT.307 date: 04/28/2020 
Battery:   ID-1: BAT0 charge: 45.4 Wh condition: 46.8/50.5 Wh (93%) volts: 12.5/12.5 model: ASUSTeK ASUS Battery type: Li-ion 
           serial: N/A status: Not charging 
CPU:       Info: 6-Core model: Intel Core i7-9750H bits: 64 type: MT MCP arch: Kaby Lake family: 6 model-id: 9E (158) 
           stepping: D (13) microcode: DE L2 cache: 12.0 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 62399 
           Speed: 4052 MHz min/max: 800/4500 MHz Core speeds (MHz): 1: 4052 2: 4274 3: 3820 4: 4072 5: 3985 6: 4019 7: 4078 
           8: 4147 9: 4130 10: 4090 11: 4149 12: 4177 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Enhanced IBRS, IBPB: conditional, RSB filling 
           Type: srbds mitigation: TSX disabled 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel UHD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:3e9b 
           Device-2: NVIDIA TU117M [GeForce GTX 1650 Mobile / Max-Q] vendor: ASUSTeK driver: nvidia v: 455.45.01 
           alternate: nouveau,nvidia_drm bus ID: 01:00.0 chip ID: 10de:1f91 
           Display: x11 server: X.Org 1.20.10 compositor: kwin_x11 driver: intel,nvidia display ID: :0 screens: 1 
           Screen-1: 0 s-res: 3840x1200 s-dpi: 96 s-size: 1013x316mm (39.9x12.4") s-diag: 1061mm (41.8") 
           Monitor-1: eDP1 res: 1920x1080 hz: 120 dpi: 143 size: 340x190mm (13.4x7.5") diag: 389mm (15.3") 
           Monitor-2: HDMI-1-0 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") 
           OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 20.3.0 direct render: Yes 
Audio:     Device-1: Intel Cannon Lake PCH cAVS vendor: ASUSTeK driver: snd_hda_intel v: kernel 
           alternate: snd_soc_skl,snd_sof_pci bus ID: 00:1f.3 chip ID: 8086:a348 
           Sound Server: ALSA v: k5.9.12-zen1-1-zen 
Network:   Device-1: Intel Wireless-AC 9560 [Jefferson Peak] driver: iwlwifi v: kernel port: 5000 bus ID: 00:14.3 
           chip ID: 8086:a370 
           IF: wlo1 state: up mac: <filter> 
           Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASUSTeK driver: r8169 v: kernel port: 3000 
           bus ID: 03:00.0 chip ID: 10ec:8168 
           IF: eno2 state: up speed: 100 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 1.38 TiB used: 329.70 GiB (23.4%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/nvme0n1 vendor: Micron model: 2200V MTFDHBA512TCK size: 476.94 GiB block size: physical: 512 B 
           logical: 512 B speed: 31.6 Gb/s lanes: 4 serial: <filter> rev: P1MA0V4 scheme: GPT 
           ID-2: /dev/sda vendor: Toshiba model: MQ04ABF100 size: 931.51 GiB block size: physical: 4096 B logical: 512 B 
           speed: 6.0 Gb/s rotation: 5400 rpm serial: <filter> rev: 0J scheme: GPT 
Partition: ID-1: / raw size: 259.79 GiB size: 259.79 GiB (100.00%) used: 45.95 GiB (17.7%) fs: btrfs dev: /dev/nvme0n1p5 
           ID-2: /home raw size: 259.79 GiB size: 259.79 GiB (100.00%) used: 45.95 GiB (17.7%) fs: btrfs dev: /dev/nvme0n1p5 
           ID-3: /var/log raw size: 259.79 GiB size: 259.79 GiB (100.00%) used: 45.95 GiB (17.7%) fs: btrfs 
           dev: /dev/nvme0n1p5 
           ID-4: /var/tmp raw size: 259.79 GiB size: 259.79 GiB (100.00%) used: 45.95 GiB (17.7%) fs: btrfs 
           dev: /dev/nvme0n1p5 
Swap:      Kernel: swappiness: 10 (default 60) cache pressure: 75 (default 100) 
           ID-1: swap-1 type: partition size: 16.00 GiB used: 0 KiB (0.0%) priority: -2 dev: /dev/nvme0n1p6 
           ID-2: swap-2 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram0 
           ID-3: swap-3 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram1 
           ID-4: swap-4 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram2 
           ID-5: swap-5 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram3 
           ID-6: swap-6 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram4 
           ID-7: swap-7 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram5 
           ID-8: swap-8 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram6 
           ID-9: swap-9 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram7 
           ID-10: swap-10 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram8 
           ID-11: swap-11 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram9 
           ID-12: swap-12 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram10 
           ID-13: swap-13 type: zram size: 650.7 MiB used: 0 KiB (0.0%) priority: 32767 dev: /dev/zram11 
Sensors:   System Temperatures: cpu: 72.0 C mobo: N/A 
           Fan Speeds (RPM): cpu: 4400 
Info:      Processes: 352 Uptime: 32m wakeups: 1 Memory: 7.63 GiB used: 4.60 GiB (60.3%) Init: systemd v: 247 Compilers: 
           gcc: 10.2.0 clang: 11.0.0 Packages: pacman: 1666 lib: 455 Shell: Zsh v: 5.8 running in: yakuake inxi: 3.1.09

Any idea how to fix this?. I can't just connect to the 4G router via a LAN cable because I need to use my ethernet port to connect to my other router and I need to switch between these 2 depending on what I am doing.

librewish · 9 December 2020 16:05

open garuda-network-assistant

disable powersave and also disable wifi mac randomization

supiri · 9 December 2020 16:06

Hi,

I already tried that it didn’t work

jonathon · 9 December 2020 16:08

2.4GHz or 5GHz wifi?

This also has issues on certain kernels - it’s not a particularly reliable driver.

supiri · 9 December 2020 16:22

Both were using 2.4GHz (router doesn’t support 5GHz)

The thing is when I was using Manjaro, this problem was there with windows. on Linux side, WIFI worked fine but in windows, there was high latency. When I installed Garuda I also had to reinstall windows and now the WIFI on the windows side is working without an issue

tbg · 10 December 2020 03:55

Windows has been known many times over to interfere with networking in Linux. There is a possibility that may be a factor. In Windoze driver advanced properties see if you can find a wifi power saving option. Be sure to disable it if it is present in Windoze.

Then power down completely and remove the battery from the laptop and disconnect the power cord. Then with the power sources removed press and hold the power button for 20-30 seconds, Let the laptop sit for a few minutes with no power, then reconnect the power cord, but not the battery. Restart and boot directly into Garuda. Check you speeds.

There is a possibility the linux-firmware is a component to this problem but we'll leave that for later.

The next thing to test is changing the iwlwifi driver options (which I will explain in my next post below).

tbg · 10 December 2020 03:58

How to test different iwlwifi driver options on the fly

You can temporarily test different iwlwifi driver options to see if your connectivity improves.

You can change the Intel iwlwifi drivers on the fly via rmmoding and modprobing.

Test one choice of options at a time by entering the following commands in the terminal individually.

Start at the top and work your way down the list, testing your connection for improvement after each change.

Open a root terminal by running the commands below.

At the terminal prompt enter:

su

Then input your root password.

Work your way down the list below, running each command individually. Test your connection for improvement after running each command.

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi swcrypto=1'

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi 11n_disable=8'

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi 11n_disable=1'

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi swcrypto=1 11n_disable=8'

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi swcrypto=1 11n_disable=1'

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi swcrypto=1 11n_disable=1 bt_coex_active=0'

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi swcrypto=1 11n_disable=8 bt_coex_active=0'

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi swcrypto=1 11n_disable=1 bt_coex_active=0 power_save=0'

/bin/bash -lc 'lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs rmmod && sleep 3 && modprobe iwlwifi swcrypto=1 11n_disable=8 bt_coex_active=0 power_save=0'

Those are some of the most commonly used options to improve connectivity with the iwlwifi driver. There are other options as well, but the above options are are the one that are commonly the most effective. Those options when executed from the terminal are not permanent. The modified driver option only persists until you reboot. The options can be made permanent by creating a configuration file in /etc/modprobe.d.

How to make your iwlwifi driver option changes persistent

To permanently change the driver options, create the file:

/etc/modprobe.d/iwlwifi.conf

You can add any of the following lines to the iwlwifi configuration file /etc/modprobe.d/iwlwifi.conf to make the option(s) persistent:

options iwlwifi bt_coex_active=0
options iwlwifi bt_coex_active=1
options iwlwifi 11n_disable=1
options iwlwifi 11n_disable=8 
options iwlwifi swcrypto=1
options iwlwifi power_save=0
options iwlmvm power_scheme=1 
options iwlwifi d0i3_disable=1 
options iwlwifi uapsd_disable=1

Test the options individually, and in combination to find which option(s) are most effective in improving your connectivity. Rebooting will wipe any driver option you have tested via modprobing.

In sequence below is an explanation of what the above options actually do:

1st option: disables Bluetooth compatibility
2nd option: enables Bluetooth compatibility
3rd option: disables wireless N band
4th option enables antenna aggregation
5th option - adds software encryption
6th option - disables adapters power saving
7th option: another way to disable power saving (if also using the iwlmvm module)
8th option: disables the power save mode
9th option: disables the power save mode

Adding a comment ( # pound sign) in front of any option disables it. Try any, or all options in different combinations. Simply comment out, or delete any option that doesn’t improve your performance. You can also delete the /etc/modprobe.d/iwlwifi.conf file completely if you find it is of no benefit.

Reboot after making any permanent driver option change in /etc/modprobe.d /iwlwifi.conf for the option to take effect.

supiri · 10 December 2020 08:44

Funny thing, I disabled the WIFI adapter from the windows side and boot to the Linux side, and seems to resolve the issue (at least for now)

❯ ping 192.168.1.1                                                                                                                                       100%  ─╯
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=25.8 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.814 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.929 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.887 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.862 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.974 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.989 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.894 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=2.10 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=1.79 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=0.872 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1.19 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=4.10 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.917 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=0.879 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=0.870 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=3.96 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=6.01 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=2.19 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=1.15 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=1.83 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=1.94 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=0.915 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=1.29 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=1.05 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=0.952 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=0.867 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=0.888 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=0.945 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=0.847 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=0.916 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=37.4 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=0.881 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=0.883 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=14.7 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=0.942 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=5.08 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=22.7 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=1.69 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=0.888 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=4.91 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=0.996 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=64 time=3.12 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=0.919 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=64 time=3.11 ms
64 bytes from 192.168.1.1: icmp_seq=48 ttl=64 time=1.37 ms
64 bytes from 192.168.1.1: icmp_seq=49 ttl=64 time=0.991 ms
64 bytes from 192.168.1.1: icmp_seq=50 ttl=64 time=1.31 ms
64 bytes from 192.168.1.1: icmp_seq=51 ttl=64 time=0.884 ms
64 bytes from 192.168.1.1: icmp_seq=52 ttl=64 time=1.14 ms
64 bytes from 192.168.1.1: icmp_seq=53 ttl=64 time=2.31 ms
64 bytes from 192.168.1.1: icmp_seq=54 ttl=64 time=3.88 ms
64 bytes from 192.168.1.1: icmp_seq=55 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_seq=56 ttl=64 time=0.864 ms
64 bytes from 192.168.1.1: icmp_seq=57 ttl=64 time=0.873 ms
64 bytes from 192.168.1.1: icmp_seq=58 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=64 time=0.921 ms
64 bytes from 192.168.1.1: icmp_seq=60 ttl=64 time=1.01 ms
64 bytes from 192.168.1.1: icmp_seq=61 ttl=64 time=0.857 ms
64 bytes from 192.168.1.1: icmp_seq=62 ttl=64 time=0.856 ms
64 bytes from 192.168.1.1: icmp_seq=63 ttl=64 time=0.949 ms
^C
--- 192.168.1.1 ping statistics ---
63 packets transmitted, 63 received, 0% packet loss, time 62466ms
rtt min/avg/max/mdev = 0.814/3.041/37.403/6.219 ms

I used some audio issue that comes and goes a while ago and folks at asus-nb-ctrl discord told me shutdown the system completely when switching rather than doing a reboot and that issue also go fixed just like that.

I will try this if the wifi issue comes up again.

Also thank you very much for taking your valuable time to write detailed debugging processes. Now I feel bad posting an issue without doing simple things like disabling the window driver and testing it again because I feel like I wasted your time and energy

UPDATE:

The issue reappeared after a while. So I followed your steps

after running this command only it got fixed. So I added options iwlwifi 11n_disable=1 and options iwlwifi swcrypto=1 to /etc/modprobe.d/iwlwifi.conf and rebooted and now everything seems to be fine (I tired rebooting few times)

AGAIN, thank you very much for you help

jonathon · 10 December 2020 11:28

That’s not really a “simple thing” - it’s something completely non-obvious if you’ve never come across it before, and a powered-off OS really shouldn’t have persistent affects on hardware.

Now it’s on the forum it will no doubt help others who find the same symptoms!

tbg · 10 December 2020 18:33

No it shouldn’t. However more and more it does happen that the adapter is disabled completely on the hardware level because the adapter is turned off completely by Windoze to save power.

@supiri I’m so happy that fixed things up for you, and it was no trouble at all. I’ve many reams of networking notes from providing support for people in Linux. Other than possibly updating my notes slightly the work to compile the notes was all done years ago.

So no worries, glad I could help.

Share · 27 May 2021 17:01

Thanks this worked for me

tbg · 27 May 2021 17:48

Please don't necrobump old technical support requests without adding anything new and important to the conversation.