[13:40] <takov751> greetings all
[13:40] <takov751> I am looking for some guidance .
[13:40] <takov751> At this moment i have a wireguard connection
[13:41] <takov751> i imported my settings with nmcli. i am able to manage it with nmcli
[13:41] <takov751> however is there a method or plugin to add this to the network gui ?
[13:54] <lotuspsychje> takov751: i saw some wireguard packages in the repos available now, maybe something usefull there?
[13:54] <lotuspsychje> !info wireguard-tools
[13:54] <lotuspsychje> perhaps?
[13:54] <takov751> yes in 20.04 you just need to install wireguard  package
[13:54] <takov751> and it will install everything needed
[13:54] <takov751> after i just imported my settings with nmcli and its just works
[13:54] <lotuspsychje> ah, it pulls the tools too?
[13:54] <takov751> yesp
[13:55] <lotuspsychje> i see
[13:55] <takov751> I still have problems and question regarding wireguard ,however thats a server side issue i am having.
[13:56] <takov751> The clients unable see each other,but i believe thats a fundamental logical issue which i am not seeing :D
[18:24] <TJ-> takov751: there is no GUI for wireguard currently. I did package an older one that had been abandoned by its author but Jason hated it 
[18:25] <TJ-> takov751: clients unable to see each other would be a routing/forwarding/firewall issue (assuming you mean 'ping $IPv4' fails - there is no multicast discovery so mDNS fails as do other broadcasts without a proxy on the server
[18:26] <takov751> TJ- : I see thanks 
[18:48] <evils> i'm getting wifi outages 1-2 a day on ubuntu 20.04, with an intel ac 9260 module
[18:50] <mason> evils: Is this new with 20.04? And have you verified that the traditional things - choice of channel, microwaves, portable phones - aren't being problematic?
[18:52] <evils> mason: never had anything but 20.04 running on this hardware, the other devices around it don't have a problem, inc the smartphone which also does 5GHz, the problem doesn't go away by itself, it does on a reboot
[18:53] <evils> also, the access point is like ~1M away
[18:53] <mason> evils: I'd look at dmesg and see if there's anything, verify you have the right firmware installed for your wifi hardware, um... Beyond that, maybe try to duplicate this on a second device.
[18:54] <evils> i suspect it's hardware specific, the additional drivers tab has always said "this device doesn't work"
[18:54] <mason> evils: An ideal test might be installing 18.04 or something on external media so you can directly compare and see if this is a regression. Or maybe even just boot from live media and use it for a while.
[18:56] <evils> https://i.imgur.com/8t6Ym83.jpg
[18:56] <mason> evils: In case it's not packages, there seems to be firmware for the 9260 here: https://www.intel.com/content/www/us/en/support/articles/000005511/network-and-i-o/wireless-networking.html
[18:57] <mason> packaged*
[18:58] <evils> odd, i switched that computer over to a cable, now i can't reach it via ssh
[18:59] <evils> mason: any idea if the 20.04 kernel supports "firmware loading"?
[19:00] <mason> evils: It's a fantastic question. Looking for docco.
[19:02] <TJ-> evils: kernel (modules) automatically request firmware loading
[19:02] <evils> TJ-: if we're assuming i'm missing firmware, why assume i have a module that'll request this firmware?
[19:02] <mason> TJ-: Where's documentation showing where to store it, and is it pattern-based? I'm finding some old stuff and I'm curious what the modern method is.
[19:03] <mason> evils: You almost certainly have the module, and it's possible Ubuntu ships the firmware aready.
[19:03] <evils> this is the old stuff? https://wiki.ubuntu.com/Kernel/Firmware#How_is_Firmware_Used.3F
[19:03] <TJ-> mason: "modinfo -F firmware iwlwifi"
[19:03] <evils> mason: when i looked at this issue a few days ago i think i concluded it's included in linux-firmware
[19:03] <evils> yet the problem persists
[19:04] <mason> evils: Do you see a "firmware missing" message in dmesg?
[19:04] <evils> ofc, that was already installed, so no reason to think gaining that knowledge would fix it xD
[19:04] <TJ-> evils: you should see kernel messages showing firmware requests/loaded
[19:04] <evils> mason: having trouble getting remote access atm, can't look at the logs
[19:05] <TJ-> evils: the fact the device works shows some firmware is being loaded... there may be later versions so checking which version is loaded is the first order of business
[19:05] <evils> TJ-: good point
[19:05] <TJ-> !info linux-firmware
[19:06] <TJ-> that's where the shipped firmware files come from. Upstream could possibly have later versions 
[19:07] <mason> evils: Worth following, if this wasn't you in the first place: https://askubuntu.com/questions/1214266/how-to-change-bluetooth-firmware-version-for-intel-ac-9260-card
[19:07] <evils> not me
[19:08] <TJ-> you'd expect to see something like (in kernel log): "iwlwifi 0000:02:00.0: loaded firmware version 29.1654887522.0 ..."
[19:08] <mason> evils: Also relevant and kind of interesting: https://bugzilla.kernel.org/show_bug.cgi?id=201319
[19:09] <TJ-> evils: is this device headless? Do you have opportunity when it loses the connection to check the logs. What is it using to manage the wifi (NetworkManager ?) 
[19:10] <evils> it's my father's personal computer, (turns out it's a really bad idea to give a first time ubuntu user a pre-release LTS...)
[19:10] <evils> TJ-: it's stock 20.04, so whatever that uses to manage wifi
[19:11] <TJ-> evils: but is it desktop or server? they use different tools
[19:11] <evils> desktop
[19:12] <TJ-> OK, so NetworkManager. So you can check its logs for clues with "journalctl -b 0 -u NetworkManager.service"
[19:12] <evils> i don't suppose you know why i can't reach the machine since it's on cable?
[19:14] <TJ-> is the port active? what is the link (Fast or Gigabit Ethernet) ?
[19:14] <TJ-> connected to a switch?
[19:15] <TJ-> evils: most default desktop NetworkManager configs have a setting to *disable* NM managing wired connections!
[19:15] <evils> the machine used to have internet access via wifi, ssh (from the same subnet, but i'm behind another router) used to work, now that it's using a cable that no longer works
[19:16] <TJ-> you can check that config with "cat /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf "
[19:16] <TJ-> stupidest change Ubuntu devs made in a long time and NOT documented 
[19:18] <TJ-> evils: does the PC have a hardware wifi radio kill switch? Have you tried toggling that in case it kicks the wifi back into action?
[19:18] <evils> it does not
[19:18] <TJ-> evils: what pc make/model is it?
[19:19] <evils> hmm, i'm using duckdns to discover that machine via ipv6, seems like that's not resolving...
[19:19] <TJ-> evils: devices are required to have a way to disable radios... either a hardware switch or a hot-key combination
[19:19] <evils> TJ-: diy based on aorus b450 i pro wifi with an amd 3400g
[19:19] <TJ-> evils: ahhh, so built onto a PC motherboard then
[19:20] <evils> yes, the b450 i pro wifi is a mini-itx motherboard with on-board wifi (the intel ac 9260 module under a can)
[19:20] <TJ-> evils: I take it you're not in front of it?
[19:20] <evils> the software rf kill switch, isn't that something i'd see if i'm in the gui?
[19:21] <mason> TJ-: I ran into that issue with wired connections recently. Inexplicable at best.
[19:21] <TJ-> evils: you can check with "rfkill list" ... software blocking is done by "rfkill block <devname>"
[19:21] <evils> TJ-: it's upstairs, but it's in use so i can't really sit in front of it for more than 5-10 minutes
[19:21] <TJ-> evils: I'd fix the NM not handling wired connection then you can remote in
[19:22] <evils> TJ-: for that, cat /usr/.../10-globally... see if it mentions the ethernet?
[19:23] <TJ-> evils: as in do "sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf && sudo systemctl restart NetworkManager" and then just check the wired link is brought up
[19:23] <TJ-> evils: this command ^^^ causes the shipped config file to be ignored
[19:23] <evils> sounds like it may break stuff...
[19:24] <TJ-> evils: in my experience it fixes things!
[19:24] <TJ-> E.g. not managing wired connections!
[19:24] <evils> well, lets see
[19:27] <evils> that 10-globally file already existed, contained [keyfile] and just: unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma
[19:30] <TJ-> evils: right, that means NM won't manage wired connections so you need to create the empty file of the same name as I showed
[19:30] <evils> touch won't blank a file
[19:30] <evils> also, didn't you say you wanted NM not to manage wired connections?
[19:30] <TJ-> evils: that line says don't manage any device unless it is wifi, or a GSM/CDMa cellular link
[19:31] <TJ-> evils: no, the other way around. By default NM is configured NOT to manage wired interfaces. You want it to manage them
[19:31] <evils> ah, i read your messages as "not managing wired connections fixes things"
[19:31] <TJ-> evils: creating the empty file of the same name over-rides this config file that Ubuntu ships, thus enabling management of wired interfaces
[19:31] <evils> k
[19:32] <evils> i do think it's currently using its wired connection
[19:32] <evils> hmm, i think i can just dump dmesg there and send it to myself...
[19:32] <TJ-> evils: does "nmcli con" show a wired connection, and in use?
[19:33] <evils> brb
[19:39] <evils> TJ-: nmcli con shows both ethernet and wifi, in green, no apparent textual indication that they're in use...
[19:40] <evils> got the dmesg and journalctl outputs
[19:41] <mason> TJ-: Interesting. I've only ever copied the stock config into /etc. Hadn't considered an empty config.
[19:41] <evils> ah shit, forgot to actually set an empty config xD
[19:41] <mason> But yeah, I whapped into "not managed" recently and had to chase it down.
[19:41] <evils> [   10.861133] iwlwifi 0000:06:00.0: FW already configured (0) - re-configuring
[19:41] <TJ-> evils: green means they're in use
[19:42] <TJ-> evils: it's possible because both are up, if the wifi is the default and has got a failure, that the PC doesn't know to route over the wired link since I assume they're both on the same subnet
[19:43] <TJ-> evils: you can do something like "nmcli con down 'Wired connection 1' (or whatever the connection ID is)
[19:44] <evils> ok, end of dmesg (minus all the 'audit' stuff from apparmor), 41 and 43s, rfkill: input handler enable, then disable; after that, just the ethernet link becoming active
[19:45] <evils> TJ-: you mean nmcli con down 'wifi'?
[19:47] <TJ-> evils: oops yes hehehe
[20:01] <evils> downing wifi on its own didn't seem to fix it, only noticed now you referred to touch /etc/... and cat /usr/lib/..., /etc indeed didn't have that file, touched it, restarted NM, still have the issue, waiting for duckdns to refresh, just in case
[20:03] <TJ-> evils: hmmm... well check if the wired connection is getting an IPv4 address (presumably via DHCP? )
[20:06] <evils> going by the journalctl output, yes
[20:15] <TJ-> evils: can the PC reach the LAN gateway, and the Internet? In other words, could the issue be that the sshd isn't running/firewall blocking/ on another device
[20:24] <evils> it definitely has internet
[20:25] <evils> current plan is to set up an ssh reverse tunnel with autossh...
[20:35] <TJ-> evils: so the problem may be the client connecting in, not the PC's openssh-server refusing
[20:39] <evils> not sure what you mean
[20:40] <evils> again, it worked on wifi, now not on wire, i'm not reaching the machine, can't ping it, it can set its IPv4 and v6 addresses on duckduckgo, but not getting a connection refused either...
[20:40] <TJ-> evils: if the PC has connectivity then it could be the clients are the problem (when not able to reach the PC on wired)... it depends on HOW specifically you're trying to connect to the PC when wifi goes down... for example, are you using the IPv4 assigned to the *wired connection* or a hostname (which may be resolving to the broken WiFi interface)
[20:41] <TJ-> evils: if your local client cannot "ping IPv4-of-PC-wired-interface" then that's a network issue
[20:41] <evils> i'm attempting to ssh to <user>@<ipv6 address> because i'm behind another NAT
[20:41] <TJ-> evils: the other option is restrictive firewall on the target PC
[20:42] <TJ-> evils: ahhh! how many NAT routers are there between your client and the target?
[20:42] <TJ-> evils: is it NAT, or PNAT?
[20:42] <evils> i'm unfamiliar with PNAT
[20:42] <TJ-> NAT translates one IPv4 to another; PNAT shares one IPv4 and maps each client connection to a different port
[20:43] <TJ-> most home gateways do PNAT (1 IPv4 for multiple local clients)
[20:43] <evils> the layout is this: [ISP's router] -> ubuntu desktop, [ISP's router] -> [my router], [my router] -> [my pc]
[20:45] <evils> ubuntu desktop is on 192.168.0.x, given to it from the isp router, my router is also in that subnet, and my desktop is on 10.30.x.x
[20:45] <evils> this topology was the same when the ubuntu desktop was on wifi
[20:46] <TJ-> evils: so in fact your router should just be doing NAT not PNAT, for sane LANs. 
[20:46] <evils> i don't believe PNAT is a common term...
[20:47] <evils> https://en.wikipedia.org/wiki/Network_address_translation
[20:47] <TJ-> evils: but, let's deal with specifics. If the desktop has two interfaces both connecting to the ISP router, then they'll each get different IPv4 address in 192.168.0.0/24 . 
[20:47] <evils> TJ-: they do indeed
[20:47] <evils> .103 and 175 if memory serves
[20:47] <TJ-> If your router is configured correctly, then, when everything is working fine, from your desktop you should be able to "ping 192.168.0.x" for each 
[20:48] <evils> TJ-: huh, so i can xD
[20:48] <evils> i'm in xD
[20:48] <evils> i didn't think that'd work
[20:48] <TJ-> evils: if we assume WiFi is .103 then when wifi goes down, you should still be able to "ping 192.168.0.175"
[20:49] <TJ-> evils: so, your issue may be trying to use IPv6 and that not being correctly configured in YOUR router :)
[20:49] <evils> so i can ssh to it on both .103 and .173, had the ipv6 setup in hopes of this remaining functional after he moves
[20:50] <TJ-> evils: which IPv6 address were you trying to connect to? I hope it wasnt' a link-local address!
[20:50] <evils> 2a02:...
[20:51] <TJ-> evils: OK... and does YOUR router know how to route that? what IPv6 subnet does your PC have? are they in the same subnet ?
[20:52] <TJ-> evils: presumably the ISP router is doing prefix-delegation
[20:53] <evils> my router is fairly stock openwrt, i'll remind you that it worked on that IPv6 prefix on wifi
[20:54] <evils> but i think the IPv6 issue is kinda mute now if i succeed in setting up a tunnel with autossh, and i'm already logged in via 192.168.0.x, so now i should be able to address the wifi driver issue
[20:55] <TJ-> Great :)
[20:57] <evils> iwlwifi-9260-th-b0-jf-b0-46.ucode
[20:58] <TJ-> evils: possibly the last one available
[21:00] <evils> the one from intel's site is: iwlwifi-9260-th-b0-jf-b0-34.ucode
[21:00] <evils> is that last number supposed to be sequential?
[21:01] <TJ-> that's the last release so far as I can see in the iwlwifi upstream firmware repo, so that's food
[21:01] <TJ-> good
[21:01] <evils> if that number is supposed to be sequential, and the one on intel's site is lower, wouldn't that indicate a roll-back?
[21:02] <TJ-> See https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/tree/  
[21:02] <TJ-> you'll see iwlwifi-9260-th-b0-jf-b0-46.ucode
[21:03] <evils> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/iwlwifi-9260-th-b0-jf-b0-46.ucode?id=fdfb1531c40d89a3ac115d7fb23fb23a3867c017
[21:03] <evils> -46 seems to be specific to the 9000 series
[21:22] <evils> ok, i'm actually seeing some connection failures in journalctl -b -1/-2 -u networkmanager
[21:23] <TJ-> evils: what frequency band is the AP on? 2.4GHz? could be collisions due to congestion from other APs
[21:24] <evils> this is using the ISP's setup, not quite sure what's actually being used, i think they emmit the same SSID over multiple, going by the wifi not being a bottleneck, i'm guessing 5GHz
[21:25] <TJ-> evils: "nmcli dev wifi" will show you ... channel numbers below 15 are 2.4GHz ... above are 5.xGHz
[21:25] <evils> with the accesspoint being ~1M await, i really doubt it's a connectivity issue, certainly not with the speeds i got, and i would really expect it to reconnect in that case
[21:25] <evils> nmcli dev wifi says channel 40
[21:26] <evils> signal 85
[21:26] <TJ-> so 5.x 
[21:27] <TJ-> ok, so focus on all the messages around the time of the last connection drop. What is the timestamp of the message you spotted?
[21:27] <evils> there seem to be a few "connection disconnected (reason [-4|2|15)", seem to be close to the reboots
[21:28] <TJ-> you can use "journactl --since "some-date-time" --until "some-later-date-time"
[21:28] <TJ-> that'll let you see other messages from other sub-systems that may be related within the same time period
[21:31] <evils> how do i see the logs for just a specific date?
[21:33] <TJ-> journalctl --since="2020-03-09" --until="2020-03-10"
[21:33] <evils> that gets me 2 days
[21:34] <evils> ideally this'd work, journalctl --since "2020-03-12T13:00" --until "2020-03-12T18:00"
[21:34] <TJ-> only gets me one day (09)
[21:35] <evils> ok, got just the 12th now
[21:35] <TJ-> it's nice - you can do things like "--since="5 minutes ago"
[21:35] <evils> still 25k lines...
[21:35] <evils> it's not nice if it doesn't accept ISO8601...
[21:35] <TJ-> evils: use / to start a regexp search for a string in the failure messages
[21:36] <TJ-> see man 7 systemd.time
[21:45] <evils> xD seeing fatal GPU errors in these logs...
[21:50] <TJ-> hardware errors? investigate IOMMU issues
[21:53] <evils> there are IOMMU warnings/errors at start, but everything seems to work, minus some artefacting in the composer
[21:54] <evils> but apparently the screen went black at some point
[21:54] <evils> i assumed the reports of "there's nothing" and "i want internet" were abotu the same thing xD
[21:55] <evils> anyway, the network manager warnings about connection disconnected are preceded by a dbus error: dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/0
[21:57] <evils> and that's preceded by among other things: wpa_supplicant[1953]: wlp6s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="telenet-3AEC4" auth_failures=2 duration=20 reason=WRONG_KEY
[22:03] <evils> ok, i think this is a fair summation, https://hastebin.com/sigaqacesi.pl