Configuring wifi-ap and hostapd on Ubuntu 20.04

If you have a fresh new, shiny Ubuntu focal installed and you are thinking to set up wifi sharing (an Access Point) in the part of your apartment that computer is located in installing and starting the wifi-ap snap is a great way to do so.
Especially if you, like me have installed it without a graphical desktop, so setting up an AP using the Network Manger GUI is now straightforward.

Make sure you have snap:

sudo apt install snapd

Then install wifi-ap:

snap install wifi-ap

Theoretically an automated setup will make it work straight after install, you can check that with:

wifi-ap.status

This did not work on my box, because I do not have a wlan0 interface, instead I had to configure it with:
wifi-ap.config set wifi.interface=wlp1s0

Configuring is very easy as far as you can live with the few options it gives you:
root@XXXXX:~# wifi-ap.config get
debug: false
dhcp.lease-time: 12h
dhcp.range-start: 10.0.60.2
dhcp.range-stop: 10.0.60.199
disabled: false
share.disabled: false
share.network-interface: enp3s0
wifi.address: 10.0.60.1
wifi.channel: 1
wifi.country-code: SG
wifi.hostapd-driver: nl80211
wifi.interface: wlp1s0
wifi.interface-mode: direct
wifi.netmask: 255.255.255.0
wifi.operation-mode: g
wifi.security: wpa2
wifi.security-passphrase: XXXXXXXXXX
wifi.ssid: XXXXXXXXXX

You can turn off the snap and back on with:
wifi-ap.config set disabled=true
wifi-ap.config set disabled=false

And restart with:
wifi-ap.status restart-ap

After these my hostapd was running but the few settings above did not allow me to set the settings to the optimal speed with the tuning options in hostapd.conf I have already experimented with earler:
ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40][TX-STBC][RX-STBC1]

And editing /var/snap/wifi-ap/355/hostapd.conf does not help as the snap regenerates it upon every startup in /snap/wifi-ap/355/bin/ap.sh which is a read-only mounted squashfs:
root@XXXXXX:~# mount |grep snap
/var/lib/snapd/snaps/wireless-tools_7.snap on /snap/wireless-tools/7 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_9665.snap on /snap/core/9665 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/wifi-ap_355.snap on /snap/wifi-ap/355 type squashfs (ro,nodev,relatime,x-gdu.hide)

So I have turned to this page on how to unmount and unpack the squashfs, modify the generating script https://askubuntu.com/questions/1046606/cannot-edit-system-file-snap-phpstorm-even-with-root-account-in-ubuntu-18-04/1046677:

cd ~

sudo umount /snap/wifi-ap/355
sudo unsquashfs /var/lib/snapd/snaps/wifi-ap_355.snap

This is when you modify anything you want in the squashfs-root directory except I could not unmount because the service process was still using the mount point. I figured out the PID for it with:
fuser -m /snap/wifi-ap/355
And killed it with:
kill -9

Then added the above config line to the config generation part of the script just before the wmm_* section, recreated the squasfs, backed up the old snap image and placed the newly generated there:

sudo mksquashfs squashfs-root wifi-ap_355.snap

sudo mv /var/lib/snapd/snaps/wifi-ap_355.snap /var/lib/snapd/snaps/wifi-ap_355.snap.backup

mv ~/wifi-ap_355.snap /var/lib/snapd/snaps/wifi-ap_355.snap

Not very elegant but then I just restarted my computer instead of figuring out how to restart the service I have killed.

I had everything in order, hostapd running in the wifi-ap snap with the updates options.

So long, and thanks for all the fish!

Troubleshooting Wireguard VPN on Windows 10, Android and Linux

I have had my share of pain over the compexity / slowness / incompatibilities / vulnerabilities of using Cisco,
To me it seems the primary problem with Wireguard are twofold:

1. Not having enough experience in the community (blog posts, walk-throughs, how-tos etc.) to set up all kinds of arrangements besides the usual site-to-site and cloud VPN jump-host.
2. Clients offer less the adequate error messages that could help with debugging / troubleshooting.
3. Clients across platforms are not consistent.

I am writing this for two reasons:

• helping fellow users with similar situations
• and to give feedback to the developers (will try to figure there to submit reports and which of the issues are known already).

Things to fix / disambiguate / document in the various WireGuard components:

1. The Android client does not have the nice log viewer that is part of the Windows client - and that helped me to see what is (not) happening) 
2. You can export the  log form the Android client is full of UI related Java messages, unlike the clean log of the Windows client - it really makes it very hard to comprehend what is going on.
3. The Android client just disappears after a while (even with the PersistentKeepalive set to 25), so suddenly the VPN protection disappears without any notification. This did not happen to the OpenVPN Android client, so probably just have to tell Android not to evict / suspend the VPN software somehow.
4. The error message "bad address" (Android client, creating configuration from scratch) is misleading or not informative enough: got it for example for 192.168.1.1/24 (should be /32 or 192.168.1.0/24) - could correct it automatically or at least be more informative telling you what is wrong.
5. It is hard to figure where Wireguard is logging on linux with systemd.
   Is it logging at all?
   - Could not find any trace of the failed connection attempts, so it was really hard to tell, if my DNS, my port forwarding or my Wireguard config is wrong (was the latter).
   - Could not find messages about 192.168.1.2/24 being inaccessible (overridden) if there is a 192.168.1.3/24 peer afterwards, so have to use /32 peers even if the server interface address is communicating on a 192.168.1.1/24 address with both of the clients.
   - systemd startup log did not habve any relevant messages either

What my mistakes and symptoms were:

1. Accidentally mixed up a private and a public key. Wiregoard just silently fails, does not tell you that there was a connection attempt but the key was wrong. Could have been any network related inaccessibility as well...
2. Did not know how to configure the peer addresses each for /32 so that they don't interfere but both can communicate with the /24 server interface.

Ubuntu 10.10 Maverick átkapcsolása NVidia-ról nyílt forrású Nouveau driverre

You might want to try the new, open source 2D and 3D drivers, if you have used the closed source NVidia drivers before upgrading.
It is simple, but far from trivial to switch to the open source Noveau drivers in Ubuntu 10.10 Maverick Meerkat:

Ha ki akarod próbálni a nyílt forrású új grafikus drivert az új 10.10-es Ubuntuban a régi NVidia driver helyett, akkor egy egyszerű, de nem nyilvánvaló lépéssort kell végrehajtanod:

Ubuntu Lucid upgrade FAIL

Annyira azért nem volt gáz a dolog, de az eddigi korlátlan bizalmamat a rendszerben kicsit visszavetette, hogy a verziófrissítés után nem indult el a FireFox.

Mint kiderült a gond nem a rendszer saját csomagjaival volt, hanem az általam kísérletezés közben telepített majd le nem szedett libmoon csomaggal és könyvtárral, amely a MoonLighthoz tartozil.
Ez a Microsoft SilverLight technológiáját (a flash alternatívája akarna lenni) próbálja megvalósítani nem Windows környezetbe, és hát még igen kialakulatlannak tűnik nekem.

Nem csak emiatt - úgy emlékszem konkrétan arra sem volt alkalmas, ami miatt feltettem (Office 2010 demót akartam megnézni).

Szerencsére ezen és a lenti IPv6 (internetszolgáltatói) DNS problémán kívül más gondot nem tapasztaltam...

Google Public DNS

Röviden: tényleg sokkal gyorsabb, frissebb szárazabb érzés! (különösen ajánlott, ha használsz Google szolgáltatásokat, pl. search, gmail, reader, picasa stb.)

Ráadásul úgy tűnik, korrekt az IPv6 támogatása is.

Az történt, hogy az Ubuntu Lucid verziójára frissítve megváltoztak a DNS illetve a FireFox beállítások, és a rendszer illetve a böngésző erősen elkezdett érdeklődni IPv6-on is.
Ekkortól _nagyon_ lassú lett bármilyen oldal betöltése aböngészőbe mind az irodából, mind otthonról (120 és 60 megabites UPC internet). Sokkal gyorsabb  volt (T-Mobile) mobilinternetről (!).

Rövid netes nyomozás után előbb az about:config-ban bekapcsoltam a http pipelineingot és a használandó http verziót 1.1-esre állítottam. Ez nem segített.

Még több nyomozás utána tettem egy próbát: használjuk a Google nyilvános DNS szolgáltatását.
És ettől nem csak helyreállt a FireFox sebessége, de észrevehetően gyorsultak is az oldalbetöltések. Próbáld ki te is!

Konklúzió: a T-Mobile már normálisan kezeli az IPv6 DNS-t is, az UPC még nem tudja...

Ha egyébként DHCP-t használsz, akkor is van olyan lehetőség, ami a gép és a default router címét és a subnet maskot DHCP-ből veszi, de hagyja, hogy a DNS-t kézzel add meg.
Részletes leírás itt