Wi-Fi 6 is coming

The upcoming standard is called IEEE 802.11ax and it will be available starting in the fall of 2019.

The latest standard we’ve been using is called 802.11ac, and although we haven’t heard Wi-FI 5, the new standard will be widely promoted as Wi-Fi 6 (as the 6th generation).

The new Wi-Fi 6, 802.11ax uses both 2.4 GHz & 5 GHz and has features such as multi-user, multiple-input, multiple-output (MU-MIMO), Orthogonal Frequency Division Multiple Access (OFDMA) — allows more devices to simultaneously operate on the same channel — throughput of 9 to 10 gigabits per second in optimal conditions. It also supports WPA3.

For reference:
Wi-Fi 5, 802.11ac (only uses 5 GHz)
Wi-Fi 4, 802.11n (uses both 2.4 GHz & 5 GHz)

Ref: What is Wi-Fi 6 and When Will I Get It?

byobu: switch to screen for byobu backend for multiple windows to a single server

I usually connect to a single server via PuTTY, and have three (horizontally) split sessions for logs, and another PuTTY window for sysadmin, and maybe one for coding (with multiple sessions via byobu), and possibly another one for reference. This doesn’t seem to be possible with tmux as backend for byobu.

This may be because, tmux, in spite of all the praises it receives for speed, features, and whatnot, doesn’t support multiple concurrent, but distinct sessions via byobu. I haven’t researched this deep enough to conclusively say that there is absolutely no way to do this, but I’ve found simply switching over to screen to be much easier solution for now.

byobu: number of updates available doesn’t get cleared

Environment: RHEL 7.6 (Maipo), byobu v5.73, Screen v4.01.00devel (2006-05-02)

Even after a complete update of the system (via yum in this case) the number of updates available indicator on the status line on byobu doesn’t get updated. This happens regardless of terminal multiplexer you’re using (either screen, or tmux.) This indicator seems to be cached under /dev/shm/byobu-mhan-CQCSeDjp/cache.screen folder, and a very short-lived, temporary workaround seems to be simply emptying out the folder. More permanent solution would be to fix the script itself (/usr/libexec/byobu/updates_available). On line 66, the following yum command is executed:

yum list updates -q | grep -vc "Updated Packages"

That is supposed to return the number of updates available, but it only works properly when it’s under under sudo on this system. It fails with an error message when it is run with user account, which byobu assumes when this script is run:

Cannot upload enabled repos report, is this client registered?

This seems to be a message related to RH subscription manager, which is typically installed as a plugin to yum. We can run without plugins to see if it still complains:

No complaint here. And return of 0 is promising. That 1! below has been an eyesore, so for now, this will be a good enough of a fix for me. This may disable some repos that were added as plugins, and I will have to double check that some other time. Adding –noplugins to line 66 in /usr/libexec/byobu/updates_available.

ssh: putty: “Couldn’t get a file descriptor referring to the console”

Environment: CentOS, PuTTY rel. 0.71

Whenever I use PuTTY (on Windows) to connect to my CentOS box, I always get the message immediately after the authentication:

Couldn't get a file descriptor referring to the console

I decided not to ignore the message today, and figured out that setfont in my .bash_profile was causing it. I recall putting that in when I used to work from home more often and connect directly on console. Just nuke or comment out the line, and all is at peace.

ssh: “perl: warning: Setting locale failed”

Environment: CentOS 7.6.1810

When logging in from a WSL console (Windows 10, v1809, Build 17763.615 + Ubuntu 18.04) into my CentOS box it seems to be complaining about locale settings.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "C.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").


According to this page, you can just add the following lines to /etc/environment file:


vim-plug: git error “could not read Username for…”

When I tried to PlugInstall a new plugin called ‘talek/vorax4’, which is an old SQL*Plus IDE, git kept on returning with the following error:

x vorax4:
    Cloning into '/home/skan/.vim/plugged/vorax4'...
    fatal: could not read Username for 'https://github.com': terminal prompts disabled

Here’s the screen shot:

I had the following line in my ~/.vimrc.

Plug 'talek/vorax4.git'

Then my Google search yielded this helpful page, and it explains that this is caused by the system trying to authenticate with https with an account that has 2FA enabled.

This can be solved by forcing git to use ssh for all interactions.

Jaco Pretorius

And following the instructions there, I executed the following line:

$ git config --global --add url."git@github.com:".insteadOf "https://github.com/"

Above command adds the following lines to ~/.gitconfig.

[url "git@github.com:"]
    insteadOf = https://github.com/

However, I was getting a different error this time:

ERROR: Repository not found.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.

I went back to into ~/.vimrc and removed that .git extension from the plugin name, so it reads:

Plug 'talek/vorax4'


Then, after all these, I realized I could have just removed .git from the repo name without adding that line to ~/.gitconfig. 😉