Investigating an OpenVPN connection problem in Gentoo Linux and Lubuntu 22.04 but not in Android 13

Back in 2020 I successfully used OpenVPN to access a remote server from my laptop and from my smartphone. Fast forward to 2023 and I needed to use OpenVPN again to access the same remote server. I could again access the remote server when connecting from my smartphone, now running Android 13, using the OpenVPN client app. However, when I tried to use OpenVPN from my laptop running Gentoo Linux, and from my desktop machine running Lubuntu 22.04, VPN connection attempts always timed out. The OpenVPN client configuration file (referred to generically as ‘client.ovpn‘ in some articles, named ‘bsf1.ovpn‘ in my case) and the OpenVPN password were both correct, so I did not understand why a connection could not be established from the laptop and desktop machine to the remote server, especially as there was not a problem connecting from my smartphone running Android 13.

I use KDE in Gentoo Linux, and Lubuntu 22.04 uses LXQt. In both those Desktop Environments I used the relevant GUI front-end to NetworkManager to import the client.ovpn file and to try to connect to the VPN server. As these connection attempts had failed, I launched the OpenVPN client from the command line in Gentoo Linux to see if there were any error messages, and the output is shown below. (For privacy reasons I have annonimised my public IP address, domain, e-mail address, country, location and organisation in all the command line output shown in this post.)

root # openvpn --config bsf1.ovpn
2023-09-30 01:07:02 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-09-30 01:07:02 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2023-09-30 01:07:02 OpenVPN 2.6.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2023-09-30 01:07:02 library versions: OpenSSL 3.0.10 1 Aug 2023, LZO 2.10
2023-09-30 01:07:02 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Enter Private Key Password:
2023-09-30 01:08:57 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-09-30 01:08:58 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:08:58 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:08:58 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-09-30 01:08:58 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=fc150984 3a9d3b4f
2023-09-30 01:08:58 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:08:58 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:08:58 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:08:58 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:08:58 TLS Error: TLS handshake failed
2023-09-30 01:08:58 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:08:58 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:08:58 Restart pause, 1 second(s)
2023-09-30 01:08:59 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:08:59 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:08:59 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:08:59 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=00c193e4 f375c3df
2023-09-30 01:08:59 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:08:59 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:08:59 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:08:59 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:08:59 TLS Error: TLS handshake failed
2023-09-30 01:08:59 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:08:59 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:08:59 Restart pause, 1 second(s)
2023-09-30 01:09:00 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:00 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:00 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:00 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=415fddcd dc5faf65
2023-09-30 01:09:01 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:01 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:01 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:01 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:01 TLS Error: TLS handshake failed
2023-09-30 01:09:01 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:01 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:01 Restart pause, 1 second(s)
2023-09-30 01:09:02 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:02 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:02 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:02 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=1458e510 821d0c37
2023-09-30 01:09:02 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:02 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:02 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:02 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:02 TLS Error: TLS handshake failed
2023-09-30 01:09:02 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:02 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:02 Restart pause, 1 second(s)
2023-09-30 01:09:03 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:03 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:03 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:03 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=9ab3df76 86d3e81d
2023-09-30 01:09:03 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:03 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:03 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:03 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:03 TLS Error: TLS handshake failed
2023-09-30 01:09:03 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:03 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:03 Restart pause, 2 second(s)
2023-09-30 01:09:05 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:05 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:05 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:05 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=9f21e4f5 a4d9fecb
2023-09-30 01:09:05 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:05 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:05 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:05 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:05 TLS Error: TLS handshake failed
2023-09-30 01:09:05 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:05 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:05 Restart pause, 4 second(s)
2023-09-30 01:09:09 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:10 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:10 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:10 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=bb6d7166 52844953
2023-09-30 01:09:10 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:10 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:10 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:10 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:10 TLS Error: TLS handshake failed
2023-09-30 01:09:10 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:10 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:10 Restart pause, 8 second(s)
2023-09-30 01:09:18 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:18 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:18 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:18 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:19 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=099e3b11 8ddc87c1
2023-09-30 01:09:19 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:19 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:19 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:19 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:19 TLS Error: TLS handshake failed
2023-09-30 01:09:19 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:19 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:19 Restart pause, 16 second(s)
2023-09-30 01:09:35 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:35 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:35 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:35 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=38ffac21 50e59cc4
2023-09-30 01:09:35 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:35 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:35 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:35 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:35 TLS Error: TLS handshake failed
2023-09-30 01:09:35 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:35 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:35 Restart pause, 32 second(s)
^C

The error message ‘TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled.‘ made me suspect that the version of the OpenSSL package (which also provides TLS) in Gentoo Linux on my laptop is incompatible with the version of the OpenSSL package on the remote server.

The command line output in Lubuntu 22.04 on the desktop machine also showed there was a problem with TLS when I tried to launch the VPN client:

user $ sudo openvpn --config bsf1.ovpn
[sudo] password for fitzcarraldo: 
2023-10-03 14:00:43 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-10-03 14:00:43 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2023-10-03 14:00:43 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 14 2022
2023-10-03 14:00:43 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2023-10-03 14:00:43 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
🔐 Enter Private Key Password: ************            
2023-10-03 14:00:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-10-03 14:00:48 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:48 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:48 RESOLVE: Cannot resolve host address: bsfitzgerald.ddns.net:1194 (Temporary failure in name resolution)
2023-10-03 14:00:48 RESOLVE: Cannot resolve host address: bsfitzgerald.ddns.net:1194 (Temporary failure in name resolution)
2023-10-03 14:00:48 Could not determine IPv4/IPv6 protocol
2023-10-03 14:00:48 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-10-03 14:00:48 SIGUSR1[soft,init_instance] received, process restarting
2023-10-03 14:00:48 Restart pause, 5 second(s)
2023-10-03 14:00:53 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:00:53 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:53 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:55 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:00:55 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:00:55 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:00:55 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:00:55 TCP_CLIENT link local: (not bound)
2023-10-03 14:00:55 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:00:56 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=c3ec9433 c4139af0
2023-10-03 14:00:57 VERIFY OK: depth=1, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:00:57 VERIFY OK: depth=0, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:00:58 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:00:58 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:00:58 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:00:58 TLS Error: TLS handshake failed
2023-10-03 14:00:58 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:00:58 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:00:58 Restart pause, 5 second(s)
2023-10-03 14:01:03 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:01:03 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:03 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:03 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:01:03 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:01:03 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 TCP_CLIENT link local: (not bound)
2023-10-03 14:01:03 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=486e45aa bbf5d0b0
2023-10-03 14:01:05 VERIFY OK: depth=1, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:05 VERIFY OK: depth=0, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:05 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:01:05 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:01:05 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:01:05 TLS Error: TLS handshake failed
2023-10-03 14:01:05 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:01:05 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:01:05 Restart pause, 5 second(s)
2023-10-03 14:01:10 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:01:10 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:10 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:10 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:10 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:01:10 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:01:10 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:01:10 TCP_CLIENT link local: (not bound)
2023-10-03 14:01:10 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:11 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=2523066e a7169e23
2023-10-03 14:01:12 VERIFY OK: depth=1, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:12 VERIFY OK: depth=0, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:13 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:01:13 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:01:13 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:01:13 TLS Error: TLS handshake failed
2023-10-03 14:01:13 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:01:13 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:01:13 Restart pause, 5 second(s)
^C

The version of OpenSSL currently running on the remote server is as follows:

user $ openssl version
OpenSSL 1.0.2l  25 May 2017

whereas the version of OpenSSL currently running in Gentoo Linux on the laptop is:

user $ openssl version
OpenSSL 3.0.10 1 Aug 2023 (Library: OpenSSL 3.0.10 1 Aug 2023)

and the version of OpenSSL currently running in Lubuntu 22.04 on the desktop machine is:

user $ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

The last time I successfully used the OpenVPN client on the laptop was in 2020, when the version of OpenSSL on the laptop was 1.1.1g, so my suspicion grew that the root cause of the problem is a version difference in OpenSSL between the client machine and the remote server.

I searched the Web and found OpenVPN bug report #348: ‘2.6 client cannot connect to old 2.2 and 2.1 server‘. Therefore I tried adding the following three lines to the client.ovpn file (bsf1.ovpn) in Gentoo Linux:

tls-cert-profile insecure
providers legacy default
compat-mode 1.1.1

Now the laptop can connect to the remote VPN server via the command line in a terminal window, as shown in the output below:

root # openvpn --config bsf1.ovpn
2023-09-30 03:13:26 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-09-30 03:13:26 OpenVPN 2.6.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2023-09-30 03:13:26 library versions: OpenSSL 3.0.10 1 Aug 2023, LZO 2.10
2023-09-30 03:13:26 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Enter Private Key Password:
2023-09-30 03:13:33 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-09-30 03:13:33 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 03:13:33 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 TCPv4_CLIENT link local: (not bound)
2023-09-30 03:13:33 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-09-30 03:13:33 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=4103e161 8493e221
2023-09-30 03:13:34 VERIFY OK: depth=1, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-09-30 03:13:34 VERIFY OK: depth=0, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-09-30 03:13:35 Control Channel: TLSv1, cipher SSLv3 DHE-RSA-AES256-SHA, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2023-09-30 03:13:35 [server] Peer Connection Initiated with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:35 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-09-30 03:13:35 TLS: tls_multi_process: initial untrusted session promoted to trusted
2023-09-30 03:13:36 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2023-09-30 03:13:36 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-options DNS 8.8.8.8,route-gateway 10.10.1.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.10.1.4 255.255.255.0'
2023-09-30 03:13:36 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: dhcp-options (2.6.4)
2023-09-30 03:13:36 OPTIONS IMPORT: --ifconfig/up options modified
2023-09-30 03:13:36 OPTIONS IMPORT: route options modified
2023-09-30 03:13:36 OPTIONS IMPORT: route-related options modified
2023-09-30 03:13:36 Using peer cipher 'AES-128-CBC'
2023-09-30 03:13:36 net_route_v4_best_gw query: dst 0.0.0.0
2023-09-30 03:13:36 net_route_v4_best_gw result: via 192.168.96.245 dev wlp3s0
2023-09-30 03:13:36 ROUTE_GATEWAY 192.168.96.245/255.255.255.0 IFACE=wlp3s0 HWADDR=d8:fc:93:c5:f4:6d
2023-09-30 03:13:36 TUN/TAP device tun0 opened
2023-09-30 03:13:36 net_iface_mtu_set: mtu 1500 for tun0
2023-09-30 03:13:36 net_iface_up: set tun0 up
2023-09-30 03:13:36 net_addr_v4_add: 10.10.1.4/24 dev tun0
2023-09-30 03:13:36 net_route_v4_add: 111.222.333.444/32 via 192.168.96.245 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 net_route_v4_add: 0.0.0.0/1 via 10.10.1.1 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 net_route_v4_add: 128.0.0.0/1 via 10.10.1.1 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 UID set to nobody
2023-09-30 03:13:36 GID set to nogroup
2023-09-30 03:13:36 Capabilities retained: CAP_NET_ADMIN
2023-09-30 03:13:36 Initialization Sequence Completed
2023-09-30 03:13:36 Data Channel: cipher 'AES-128-CBC', auth 'SHA256', compression: 'lzo'
2023-09-30 03:13:36 Timers: ping 10, ping-restart 12
[...]

and I can access the SMB shares on the remote server by entering ‘smb://192.168.0.10‘ in the Dolphin file manager’s window in KDE on the laptop.

However, if I terminate the openvpn client on the command line and then import the modified bsf1.ovpn file into NetworkManager using plasma-nm (the KDE GUI front-end to NetworkManager), connection attempts to the VPN still time out. The created NetworkManager connection file /etc/NetworkManager/system-connections/bsf1.nmconnection does not contain the settings in the additional three lines that I added to the client.ovpn file, as apparently they are meaningless to NetworkManager. When I use the plasma-nm GUI to import the client.ovpn file I assume plasma-nm or NetworkManager simply ignore the additional three lines when they parse the configuration file.

In Lubuntu 22.04 I edited bsf1.ovpn to add the three lines:

tls-cert-profile insecure
providers legacy default
compat-mode 1.1.1

and launched the openvpn client from the command line, but OpenVPN objected to the compat-mode line:

user $ sudo openvpn --config wjh1.ovpn
Options error: Unrecognized option or missing or extra parameter(s) in bsf1.ovpn:93: compat-mode (2.5.5)
Use --help for more information.

For the openvpn client command to execute successfully in Lubuntu 22.04 I had to omit the line ‘compat-mode 1.1.1‘, i.e. the two manually-added lines to bsf1.ovpn in Lubuntu 22.04 are:

tls-cert-profile insecure
providers legacy default

In my situation (i.e. the client is using OpenSSL 3.x.x in Lubuntu 22.04 and the remote server is using OpenSSL 1.x.x) the VPN connection still times out when attempting to connect using the GUI front-end (nm-tray or nm-applet) to NetworkManager in LXQt, so the work-around is still to launch the OpenVPN client from the command line as already explained:

user $ openvpn --conf bsf1.ovpn

and I can access the SMB shares on the remote server by entering ‘smb://192.168.0.10‘ in the PCManFM-Qt file manager’s window in LXQt on the desktop machine.

The remaining question I had was why my Samsung Galaxy Note 20 Ultra 5G running Android 13 can connect to the remote server via OpenVPN. I suspected that Android 13 uses an earlier version of OpenSSL that is compatible with the version on the remote server. A little research online showed me that Android 13 (and a couple of previous versions of Android) uses a Google fork of OpenSSL called BoringSSL. So, to find the version of OpenSSL/BoringSSL in Android 13, I cloned the BoringSSL repository on my laptop:

user $ git clone https://android.googlesource.com/platform/external/boringssl

and then I searched for the environment variable OPENSSL_VERSION_TEXT:

user $ grep -r OPENSSL_VERSION_TEXT boringssl/*
boringssl/include/openssl/crypto.h:// OPENSSL_VERSION_TEXT contains a string the identifies the version of
boringssl/include/openssl/crypto.h:#define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1 (compatible; BoringSSL)"
boringssl/src/include/openssl/crypto.h:// OPENSSL_VERSION_TEXT contains a string the identifies the version of
boringssl/src/include/openssl/crypto.h:#define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1 (compatible; BoringSSL)"
boringssl/src/crypto/crypto_test.cc:// Test that OPENSSL_VERSION_NUMBER and OPENSSL_VERSION_TEXT are consistent.
boringssl/src/crypto/crypto_test.cc:// Node.js parses the version out of OPENSSL_VERSION_TEXT instead of using
boringssl/src/crypto/crypto_test.cc:            std::string(OPENSSL_VERSION_TEXT).substr(0, strlen(expected)));

As I had surmised, OpenSSL (well, the fork BoringSSL) in Android 13 is Version 1.1.1. That is why the original bsf1.ovpn still works with the OpenVPN client on my phone to access the OpenVPN server running on the remote server.

By the way, in order to use OpenVPN in Lubuntu 22.04, you need to install the following three Ubuntu packages:

openvpn
network-manager-openvpn
network-manager-openvpn-gnome (despite Lubuntu using LXQt rather than GNOME)

The NetworkManager GUI front-end nm-tray does not support password asking, so you need to use the NetworkManager GUI front-end nm-applet to connect to the VPN (assuming both client and server have compatible versions of OpenSSL, that is). You can either type ‘nm-applet‘ on the command line or you can switch to using nm-applet instead of nm-tray by deselecting nm-tray in LXQt ‘Application Menu’ > ‘Preferences’ > ‘LXQt Settings’ > ‘Session Settings’ > ‘Autostart’ and adding nm-applet to the Autostart list. See Lubuntu Manual Appendix G Advanced Networking for further details. As already mentioned, in my situation the client is using OpenSSL 3.x.x and the server is using OpenSSL 1.x.x so the VPN connection still times out, therefore the work-around is still to launch openvpn from the command line:

user $ openvpn --conf bsf1.ovpn

To summarise my situation:

On my smartphone running Android 13 I simply use the OpenVPN client app for Android with the original client.ovpn configuration file (named ‘bsf1.ovpn‘ in my case) in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

In Gentoo Linux currently running OpenSSL 3.0.10, I have to edit the original client.ovpn configuration file and add three lines, then launch the openvpn client from the command line in a terminal window in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

In Lubuntu 22.04 currently running OpenSSL 3.0.2, I have to edit the original client.ovpn configuration file and add two lines, then launch the openvpn client from the command line in a terminal window in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

The bottom line is: To avoid problems, check you have the same version of OpenSSL installed in the client and server devices when using OpenVPN.

Disabling the DebugLoggerUI service app in Android

The following notification appeared every time I switched on my Blackview Tab 10 tablet (Android 11):

DebugLoggerUI

DebugLoggerUI service is running

I cannot remember if this notification started appearing after I upgraded the tablet’s firmware last year to remove a bug in the original firmware (I had contacted Blackview and they supplied me with the updated firmware file plus a Windows 10 tool to update the tablet’s firmware). Anyway, the DebugLoggerUI notification was annoying and the log files it created were not needed either.

I enabled ‘Developer options‘ in Android and selected the settings page for DebugLoggerUI. I tapped the DebugLoggerUI’s wastebin icon to delete the existing log files, then unticked all the listed log files in order to prevent further logging.

The following notification now appeared every time I switched on the tablet, confirming that logging had ceased:

DebugLoggerUI

DebugLoggerUI service is running
Warning: All logs are stopped!!!

However the service was still running and there was no way to permanently disable or uninstall the DebugLoggerUI app from the tablet’s menus. I therefore decided to try to disable the application by using adb (Android Debug Bridge). The procedure I used is listed below.

1. Installed adb tools on the computer

In Lubuntu:

user $ sudo apt install android-tools-adb

In Gentoo Linux:

root # emerge android-tools

2. Enabled ‘Developer Options’ on the tablet

‘Settings’ > ‘About tablet’ and quickly tapped seven times on ‘Build number’.

3. Enabled ‘USB Debugging’ on the tablet

‘Settings’ > ‘System’ > Developer options’, scroll down and tap on ‘USB debugging’. Tapped ‘OK’ when prompted ‘Allow USB debugging?’.

4. Launched adb on the computer

user $ adb start-server

5. Connected the tablet to the computer with a USB cable

user $ adb devices
List of devices attached
DKTAB10EEA007074        unauthorized

A few prompts on the tablet asked whether or not to allow USB debugging. Tapped ‘Always allow from this computer’ and tapped ‘OK’.

6. Checked for a DebugLoggerUI service

user $ adb shell service list | grep -i logger

Nothing was returned.

7. Checked for a DebugLoggerUI app

user $ adb shell pm list packages | grep -i debug
package:com.debug.loggerui
package:com.mediatek.gnssdebugreport

8. Disabled the DebugLoggerUI app

user $ adb shell pm disable-user --user 0 com.debug.loggerui
Package com.debug.loggerui new state: disabled-user

9. Checked if the app is now disabled (enabled=3)

user $ adb shell dumpsys package com.debug.loggerui | grep enabled
    User 0: ceDataInode=467223 installed=true hidden=false suspended=false distractionFlags=0 stopped=false notLaunched=false enabled=3 instant=false virtual=false

N.B. If I want to re-enable the app in future, I would use the following command:

user $ adb shell pm enable --user 0 com.debug.loggerui

10. Stopped the adb server on the computer

user $ adb kill-server

11. Unplugged the phone from the computer.

12. Restarted the tablet.

Great! No more notification message about DebugLoggerUI.

Replacing the cracked screen on a Blackview Tab 10 tablet

Blackview Tab 10 (in its protective case) with original touchscreen.

In a previous post I mentioned that the LCD touchscreen of my Blackview Tab 10 tablet had partially popped out of the tablet’s plastic housing and had developed a crack when I tried to push it back in, as can be seen in the photograph below.

Crack in top right corner of screen of Blackview Tab 10 (in its protective case).

I decided to try to replace the damaged screen, so in April 2022 I contacted Blackview’s customer support department in China to ask if they sell spare parts. They pointed me to the Blackview accessories section of online retailer AliExpress. AliExpress listed a replacement screen specifically for the Tab 10, which cost me just over GBP 87 including postage in May 2022. However, when I tried to remove the tablet’s original screen I damaged the FPC (flexible printed circuit) FFC (flexible flat cable) connecting the tablet’s PCB (printed circuit board) to the screen, shown in the photographs below.

Original FPC attached to PCB of Blackview Tab 10.

Damaged original FPC of Blackview Tab 10.

Basically, I was not careful when removing the part of the FPC that was attached to the back of the screen by a double-sided self-adhesive pad, and the tiny connector socket soldered onto the FPC cable broke off, as shown in the photograph above.

In December 2022 I decided to have another go at repairing the tablet so I contacted Blackview again to ask if they would be able to supply me with a replacement FPC cable for the Tab 10, which they kindly agreed to do. Thumbs up to Blackview for great service.

By the way, when I popped out the original screen from the tablet’s housing I discovered why I had been unable to push the corner of the screen back into the tablet’s housing. There is a row of small rectangular metal blocks along the inside top edge of the original screen, as shown in the photographs below. I assume they were intended to attract a magnetic flap on a cover for the tablet. Anyway, the metal blocks are glued into recesses in the back of the plastic surround of the screen. The block in the top left corner of the screen (looking at the screen from the back) – which I have indicated with a red circle on the second photograph – had come unstuck and had fallen between the back of the screen and the tablet’s PCB. When I tried to press the corner of the screen back into the tablet’s housing, the metal block prevented the screen from being pushed back in and the pressure cracked the screen.

Back of original screen of Blackview Tab 10.

Rear view of top right of original screen of Blackview Tab 10.

To complicate things further, when I removed the original screen I discovered that the replacement screen AliExpress had listed as a Tab 10 component is not exactly the same physically as the original screen; it does not have the same plastic surround as the original screen (see above two photographs) and it could not be clipped into the tablet’s housing. Furthermore, the overall dimensions of the replacement screen are very slightly smaller than the overall dimensions of the original screen, leaving a tiny gap between the edges of the replacement screen and the inside edges of the tablet’s housing, as shown in the photographs below. My solution was to use three double-sided self-adhesive pads to affix the back of the new screen to the inside back of the tablet. Initially I thought about using a silicone sealant or a very thin nitrile rubber cord to plug the gap between the edge of the new screen and the tablet’s housing, but the lip of the protective case that came with the tablet covers some of the gap and it is not very noticeable, as shown in the photographs below. Of course, the only thing stopping the screen falling out of the tablet’s housing is the double-sided self-adhesive pads attaching the back of the screen to the inner back of the tablet, but I am confident that is adequate.

Top left corner of Blackview Tab 10 (in its protective case) with replacement screen fitted.

Bottom right corner of Blackview Tab 10 (in its protective case) with replacement screen fitted.

Blackview Tab 10 (in its protective case) with replacement screen fitted.

Flap of protective case closed on Blackview Tab 10 with replacement screen fitted.

After clumsily damaging the original FPC flat cable last year, this time I was very careful when connecting the replacement FPC cable to the tablet’s PCB and to the replacement screen, and the new screen worked perfectly as soon as I powered up the tablet. In my earlier post I mentioned that the detection of taps was a little slow for the Blackview Tab 10, however the response is now as good as the response of the touchscreen of the Blackview Tab 11. Apart from replacing the Tab 10’s screen, the only difference from the as-bought Tab 10 is that it no longer has a SIM inserted, but I cannot see how that would have any impact on tap detection. Therefore I assume the new screen itself is somehow more responsive than the original screen fitted to the Tab 10.

In conclusion, I am happy to be able to use the Blackview Tab 10 again a year later, as I do not like throwing things away if there is a chance to repair them, albeit the repair cost me about GBP 96 for the replacement screen and FPC cable. My main regret is that, if I had popped out the original screen rather than trying to push it back into the tablet’s housing, I would have noticed the loose metal block and been able to glue it back in place and thus avoided cracking the screen. Still, I suppose I learned about FPC and FFC connectors, and the improved tap response is a welcome outcome.

Blackview Tab 11, a good budget tablet

Blackview Tab 11 tablet with optional wireless keyboard.

Last year a family member told me that her compact mobile phone’s screen is too small to show family photos properly to her friends. She said her friends use tablets to show their family’s photos, and she asked me if it would be possible to access her existing WhatsApp account via a tablet. I explained that, without guaranteed access to Wi-Fi in public areas, it would not be feasible to use WhatsApp Web on a tablet, so a tablet would need to have a SIM card. As the tablet’s SIM card would have a different phone number she would need a different WhatsApp account on the tablet but that account could be a member of the existing WhatsApp chat groups of which she is a member on her mobile phone. Additionally, she could forward to her tablet’s WhatsApp account any photos she receives in her mobile phone WhatsApp’s account.

Coincidentally, a few weeks later we changed our home Broadband provider (the previous provider’s service was terrible), and the new package included a mobile phone SIM card with 5 GB data monthly at a very cheap price. We already have good SIM-only packages for our mobile phones, so the new SIM card was available to be used in a tablet. Therefore I decided to buy a budget tablet, and plumped for a Blackview Tab 10, which had a good specification for a budget tablet. It came in September 2021 with Blackview firmware version Tab10_EEA_TP717_V1.0.0_20210429V07 containing some bugs: the System Manager app did not work after I inserted a 128 GB microSD card and the tablet’s microphone did not work in WhatsApp, Signal and Skype. I was able to fix the bugs by upgrading the tablet’s firmware to version Tab10_EEA_TP717_V1.0_20210824V09 with the help of Blackview’s customer support department. I assume a Tab 10 purchased since September 2021 would already have the newer firmware. Anyway, after upgrading the firmware everything works well. The tablet’s camera performance is not stellar, but who buys a tablet for its cameras? I would summarise the Blackview Tab 10’s features as follows:

• It has 4 GB RAM and 64 GB storage.
• It was supplied with a charger, USB C earphones (including microphone), OTG (on-the-go) adapter (USB C plug on one end, USB A socket on the other end), and a protective case which can be folded to make a kickstand.
• It does not have a 3.5 mm jack socket for earphones, so you have to use earphones that have a USB C plug.
• In the UK it works well to make and receive phone calls (4G), send and receive SMS messages (4G), and send and receive mobile data (4G). The SIM card for a mobile network that also supports 5G works with 4G too. I had to enter the APN (Access Point Name) parameters of my mobile service provider, which I found by googling.
• According to Blackview the Tab 10’s mobile phone functionality does not work in the USA. only Europe and Asia.
• It comes with Blackview’s Doke OS_P 1.0 using Android 11.
• It has a bright, crisp screen, albeit without automatic brightness adjustment.
• It can be connected to a magnetic keyboard designed for the Tab 10 (see Blackview’s online shop).
• Wi-Fi and Bluetooth work well.
• It is fine for browsing the Web, viewing photos, watching YouTube videos and other videos, reading documents, chatting via WhatsApp, Signal and Skype.
• The tap detection is a little slow, but fine for normal use.

There is a very comprehensive review of the Tab 10 on the NOTEBOOKCHECK Web site.

By the way, since I bought the Tab 10 Blackview has released a Tab 10 Pro with 8 GB RAM and 128 GB storage, with handwriting support. The additional memory, storage and handwriting support make the Tab 10 Pro a better choice than the Tab 10 for an extra GBP 30 or so.

Anyway, the Tab 10 filled the brief I had been given.

This post would have ended here except that, last week, I noticed that the Tab 10’s screen had partially popped out of its plastic housing. I suspect one of my family had either dropped the tablet or sat on it on the sofa. When I tried to push the screen back into its housing a crack formed in a corner of the screen. The crack appears to be in the LCD screen under the touch screen. I asked a local repair shop how much they would charge to repair it and they quoted me nearly half what I paid for the tablet, so I decided to buy the latest Blackview tablet model instead, the Tab 11. The Tab 11 has a higher specification than the Tab 10 and I paid less for it than I paid for the Tab 10 (although the Tab 10 is now being discounted by Blackview and some online stores and can be purchased for less than the Tab 11).

Apart from the higher specification CPU and GPU than the Tab 10, the Tab 11 has double the RAM and double the storage. The Tab 11 housing is aluminium alloy rather than the plastic housing of the Tab 10, and it weighs less than the Tab 10. The NOTEBOOKCHECK Web site does not yet have a comprehensive review of the Tab 11, but the TECHXREVIEWS Web site has a fairly comprehensive review. The Tab 11 is noticeably snappier and responsive than the Tab 10 and I like it a lot so far. Unlike the Tab 10, the Tab 11 has a 3.5 mm socket for earphones with a 3.5 mm jack plug, which I prefer.

The Tab 11’s mobile phone functionality does not work in the USA, only Europe and Asia according to Blackview. I can confirm a UK SIM card works perfectly in the Tab 11 in the UK. The SIM card I am using supports the mobile provider’s 5G network but the Tab 11 supports up to 4G LTE, which works fine with the SIM card.

There is significant commonality between the Tab 11 and Tab 10 as they both use Android 11. The Tab 10 has Blackview’s Doke OS_P 1.0 on top of Android 11, whereas the Tab 11 has Doke OS_P 2.0 which has several additional features (split screen functionality, for example).

I have seen a YouTube video review that claims the Tab 11 does not support Widevine L1, despite Blackview’s specification for the Tab 11. I have not tested that feature as it is not something I am particularly interested in. However, I read Blackview’s blog post ‘How to enable or check out Widevine L1 Certification on Blackview Tab 11?‘ and I installed the third-party Android app ‘DRM Info‘ which indicated the Tab 11 supports Widevine L1, although that is as far as I have checked. I installed the BBC iPlayer app on the Tab 11, and programmes play perfectly; video looks great to my eyes, and audio is also excellent. YouTube videos also play well and sound great. I’m not interested in playing games, so cannot comment on that aspect, although the reviews of the Tab 11 I have watched on YouTube claim games performance is good.

I would summarise the Blackview Tab 11’s features as follows:

• It has 8 GB RAM and 128 GB storage.
• The housing is made of aluminium alloy and is strong and rigid.
• The tablet weighs less than the Tab 10.
• It was supplied with a charger, OTG (on-the-go) adapter (USB C plug on one end, USB A socket on the other end), and a protective case which can be folded to make a kickstand.
• It has a 3.5 mm jack socket for earphones.
• In the UK it works well to make and receive phone calls (4G), send and receive SMS messages (4G), and send and receive mobile data (4G). The SIM card for a mobile network that also supports 5G works with 4G too.
• According to Blackview the Tab 11’s mobile phone functionality does not work in the USA. only Europe and Asia.
• It comes with Blackview’s Doke OS_P 2.0 using Android 11.
• It has a bright, crisp screen with automatic brightness adjustment (‘adaptive brightness’).
• It can be connected to a wireless keyboard designed to work with the Tab 11 (see Blackview’s online shop).
• Wi-Fi and Bluetooth work well.
• It is good for browsing the Web, viewing photos, watching YouTube videos and other videos, reading documents, chatting via WhatsApp, Signal and Skype.
• The tap detection is good, and response is snappy.
• Audio is good.

In summary, if you’re in the market for a budget tablet, in my opinion the Blackview Tab 11 would be a good choice; I am very pleased with it. At the time of writing, Blackview’s online shop lists the Tab 11 at GBP 168.44 and the Tab 10 at GBP 145.47. Unless your budget is tight, I would forget the Tab 10; the Tab 11 is the way to go. If you want a tablet that supports a UK SIM card as well as Wi-Fi and Bluetooth, the Blackview Tab 10 and Tab 11 are good budget choices in the UK, although the Tab 11 is a much better choice if you can afford the extra GBP 25 or so. However, US residents should note that the tablets do not support mobile networks in the USA (Wi-Fi and Bluetooth work fine in any case). Blackview’s Web site states “This tablet’s 4G [mobile] network connection can only work in Europe and Asia area, please pay attention before purchasing or consult us.”

croc – another file transfer method

I have lost count of the number of times I have had to send a large file to someone at work, usually in a hurry. I’ve used Dropbox, ownCloud, Firefox Send (no longer available) etc. Transferring large files became a bit easier when e-mail service providers increased the size limit for attachments, but that is still not a solution for very large files. The xkcd cartoon FILE TRANSFER sums up the situation nicely.

I recently discovered the command line utility croc, which the author claims is a way to ‘easily and securely transfer stuff from one computer to another.’ I thought I’d give it a try, if only to have another tool to fall back on in an emergency. It does rely on both ends having croc installed, but hopefully that should not be a show-stopper as croc is available for Linux, Windows, macOS and BSD. To quote the author:

croc differs from a utility like scp because it doesn’t require any two computers to have enabled port-forwarding. Instead, croc will uses a relay – a temporary server setup locally (if both computers are on lan) or publicly (default is at croc4.schollz.com). Any two computers can connect to the relay, and after securing their channel with PAKE [password authenticated key exchange], they can transfer encrypted metadata and data through the relay. The relay works by first having the computers communicate the PAKE protocol via websockets, and then exchanging encrypted metadata, and then stapling the TCP connections directly so that they can transfer directly.

So, to use croc you will be dependent on the public relay provided by the author unless you set up your own relay (instructions are provided in the author’s original 2018 blog post introducing croc – see link above – and in various third-party articles about croc, such as ‘Securely Transfer Files and Folders Between Computers Using Croc‘ and ‘Transfer Files And Folders Between Computers With Croc‘).

Anyway, I installed croc in Lubuntu and Gentoo Linux from the author’s GitHub repository and indeed it is easy to use and works fine. The binary releases for the various OSs and Linux distributions can be found on the Releases page of the GitHub repository or via the OS package manager.

Lubuntu 20.10:

user $ wget https://github.com/schollz/croc/releases/download/v9.1.6/croc_9.1.6_Linux-64bit.deb
user $ sudo dpkg -i croc_9.1.6_Linux-64bit.deb

Gentoo Linux:

root # emerge net-misc/croc

(Note that croc ebuilds are not currently marked as Stable in the Gentoo Linux Portage tree, so you’ll have to unmask them by keyword if you are using the Stable branch.)

Termux:

I even installed croc in Termux on my Samsung Galaxy Note 20 Ultra 5G, and it works in Android too:

$ pkg install croc

Other OSs and other Linux distributions:

See the instructions in the README file online.

Using croc

Using croc is as simple as entering a command on one computer, informing (via e-mail, telephone, SMS, Signal or other social media) the person using the other computer of the command to use, and entering that command on the other computer. For example:

Sender

user $ croc send Documents/flight-times.ods
Sending 'flight-times.ods' (16.6 kB)
Code is: 8878-salary-courage-roger
On the other computer run

croc 8878-salary-courage-roger

Receiver

user $ croc 8878-salary-courage-roger
Accept 'flight-times.ods' (16.6 kB)? (Y/n) 

If the receiving user then enters ‘Y’, the sending user sees something similar to this:

user $ croc send Documents/flight-times.ods
Sending 'flight-times.ods' (16.6 kB)
Code is: 8878-salary-courage-roger
On the other computer run

croc 8878-salary-courage-roger

Sending (->192.168.1.74:60740)
 100% |████████████████████| (17/17 kB, 10.918 MB/s)
user $ 

and the receiving user sees something similar to this:

user $ croc 8878-salary-courage-roger
Accept 'flight-times.ods' (16.6 kB)? (Y/n) Y

Receiving (<-[::1]:39442)
 100% |████████████████████| (17/17 kB, 3.989 MB/s)
user $ 

The observant reader will notice that the above example shows a file being transferred on the same computer. When transferred between different computers the IP addresses of each computer will be displayed instead. I have used croc to transfer files between different computers on my home network (I would normally just use my NAS for this, though), between remote computers on the Internet, and between my computers and my phone via mobile broadband, and croc works in all cases.

I have not mentioned all croc’s features. I’ll leave you to read up on croc in more detail in the links I’ve given above. It looks like it might be a useful tool to have installed.

Using adb tools in Linux to remove bloatware from my Samsung Galaxy Note 20 Ultra

Samsung included a lot of bloatware on my Galaxy Note 20 Ultra 5G, and it is not possible to uninstall it using Play Store. However, it is possible to remove this stuff using adb tools. I got rid of the bloatware I don’t want very easily using the Linux version of the adb tools.

I have never had a Facebook account and never will, so I decided to remove all trace of it as follows:

1. Installed adb tools

In Lubuntu 20.10:

user $ sudo apt install android-tools-adb

In Gentoo Linux:

root # emerge dev-util/android-tools

2. Enabled ‘Developer Options’ on the phone

‘Settings’ > ‘About Phone’ > ‘Software Information’ and quickly tapped 7 times on ‘Build number’.

3. Enabled USB Debugging on the phone

‘Settings’ > ‘Developer options’, scrolled down and tapped on ‘USB debugging’.

4. Launched adb

user $ adb start-server
* daemon not running; starting now at tcp:5037
* daemon started successfully

5. Connected the phone to the computer using the USB cable

A few prompts on the phone asked whether or not I wanted to allow USB debugging. Tapped ‘Always allow from this computer’ and tapped ‘OK’.

6. Uninstalled Facebook

The packages I needed to uninstall were:

com.facebook.appmanager
com.facebook.katana
com.facebook.services
com.facebook.system

First I tried to uninstall with the ‘-k‘ option:

user $ adb uninstall -k --user 0 com.facebook.appmanager
The -k option uninstalls the application while retaining the data/cache.
At the moment, there is no way to remove the remaining data.
You will have to reinstall the application with the same signature, and fully uninstall it.
If you truly wish to continue, execute 'adb shell cmd package uninstall -k'.

See ‘Difference between pm clear and pm uninstall -k on Android‘

I have never been a member of Facebook and never will, so I dispensed with the ‘-k‘ option and entered the following commands:

user $ adb uninstall --user 0 com.facebook.appmanager
Success
user $ adb uninstall --user 0 com.facebook.katana
Success
user $ adb uninstall --user 0 com.facebook.services
Success
user $ adb uninstall --user 0 com.facebook.system
Success

I didn’t want the LinkedIn, Samsung Global Goals and Spotify apps either, so I uninstalled those too:

user $ adb uninstall --user 0 com.linkedin.android
Success
user $ adb uninstall --user 0 com.samsung.sree
Success
user $ adb uninstall --user 0 com.spotify.music
Success

7. Stopped the adb server on the computer

user $ adb kill-server

8. Unplugged the phone from the computer.

That’s it.

In order to disable the apps using this method, you will need to know the exact package name of the app you want to get rid of. For this, use Play Store and install App Inspector (there are several apps with this name in Play Store; I installed the app by Projectoria Ltd but the others look OK too). Launch App Inspector and you can find the package name under the name of the app. This starts with a ‘com‘ or ‘net‘ followed by words separated by dots.

For example, App Inspector shows the package name for LinkedIn as ‘com.linkedin.android‘.

Some useful links:

• How to install and setup ADB tools on Linux
• How To Remove Bloatware on Samsung Galaxy Note 20 and Improve Performance
• WARNING: Do *NOT* delete all the apps in this list
• Disable Bloatware on Your Galaxy Note 20 for Free Without Root
• How to Remove Samsung Bloatware without Root (ADB)

To get a list of all the packages installed on my phone:

user $ adb shell pm list packages

To get a list of system apps only:

user $ adb shell pm list packages -s

To get a list of only Samsung packages:

user $ adb shell pm list packages | grep samsung

To search for e.g. facebook packages:

user $ adb shell pm list packages | grep facebook

(Returns nothing now, as I already deleted all the Facebook packages. Yay!)

To search for other packages, e.g.:

user $ adb shell pm list packages | grep kids
package:com.samsung.android.kidsinstaller
package:com.sec.android.app.kidshome

Installing Linux on an old Motorola Xoom tablet

Back in March 2012 I bought a Motorola Xoom Android tablet (Model MZ604 UK), when tablets were going to be the next big thing. It was available in two versions: 3G and Wi-Fi, and it was the latter version I purchased. When it was released in early 2011 the Xoom was state-of-the-art with its NVIDIA Tegra 2 chip, 1 GB RAM, 32 GB internal storage memory, microSD Card slot (up to 32 GB), Wi-Fi, Bluetooth, GPS, gyroscope, magnetometer, accelerometer, barometer and Android 3.0, trumping the first Apple iPad and Samsung’s Galaxy Tab. It has a 2 MP front-facing camera and 5 MP rear-facing camera that records 720p video, supports 720p video playback, has a 10.1-inch display (1280×800 pixels) and 3D graphics acceleration, and a micro HDMI port.

Apple launched the iPad 2 almost immediately after Motorola launched the Xoom, and the Xoom looked outclassed. By the time I bought my Xoom in March 2012 Motorola was already discounting it. Motorola issued a couple of Android updates for the UK Xoom before the company stopped supporting it, although I think mine lost its second update (Android 4.1.1, if I recall correctly) after I factory-reset it several years later when it became very sluggish. Anyway, ‘Settings’ > ‘About tablet’ tells me it currently has Android 4.0.4 installed.

It had been gathering dust on a shelf for several years until I decided to dust it off yesterday to see if there was anything useful I could still do with it (the answer is: not much). None of the apps on it can be upgraded. The version of the Play Store app can no longer access the Google app store. Even if it could, most of the apps in the app store cannot run in Android 4.0.4. The YouTube app cannot access YouTube. The Web browser cannot browse many modern Web sites and can no longer download files either, displaying a message that the browser is no longer supported and must be updated — except that it cannot be. The Google Talk app no longer works since Google pulled the plug on its Talk service (not that I ever used Google Talk anyway). The Gmail app still works, but I don’t use Gmail either. The Maps app still works, as do the Music and Gallery apps.

I connected the Xoom to my desktop machine using a USB cable (Type-A to Micro-USB) and was able to copy files quickly and easily to and from the Xoom. I systematically set about finding versions of Android APK files on the Web that the Xoom would be able to install. APKPure for Android is one of several Web sites to find older versions of APK files. The latest versions I found that the Xoom could install are as follows:

Google Chrome browser

com.android.chrome-42.0.2311.111-2311111-minAPI14.apk

This old version of the Google Chrome browser works better than the browser supplied with Android 4.0.4 on the Xoom but is still not much use, as it cannot browse many sites and cannot download files either. It can access YouTube and play some of the videos, which is some consolation given that neither the browser nor the YouTube apps supplied with Android 4.0.4 can access YouTube any more.

File Manager + (an excellent Android app, by the way)

File Manager_v2.6.0_apkpure.com.apk

This older version of File Manager + works well in Android 4.0.4 on the Xoom, and even enables me to browse files on my Cloud server via WebDAV, although the Xoom cannot open hi-res photos (4032×3024 etc.) via WebDAV. This version of File Manager + supports SMBv1 but not later versions of the protocol, so I cannot browse SMB shares on my home network, as all my machines use either SMBv2 or SMBv3. Pity.

Total Commander

Total Commander file manager_v3.20_apkpure.com.apk
WebDAV plugin Total Commander_v3.01_apkpure.com.apk
LAN plugin for Total Commander_v3.20_apkpure.com.apk

Although I find Total Commander’s UI rather old-fashioned, with the WebDAV and LAN plugins installed I can browse files on my Cloud server via WebDAV, and browse files on my NAS via SMBv2/v3. So Total Commander works well, and the Xoom can open hi-res photos (4032×3024 etc.) via either protocol.

NewPipe legacy (forked by sh000gun to work with Android 4.0+)

NewpipeLegacy-armeabi-v7a-API-14.apk

This open-source YouTube app works in Android 4.0.4 on the Xoom and allows me to view some YouTube videos, although the app tends to crash quite often. Still, it is better than the YouTube app supplied with Android 4.0.4 on the Xoom, as that does not work at all and cannot be upgraded.

Linux

The following Android apps enabled me to root the Xoom and install and run an old version of Linux in a chroot:

BusyBox_v64_apkpure.com.apk

Linux Deploy_v2.5.0_apkpure.com.apk

VNC Viewer Remote Desktop_v2.1.1.019679_apkpure.com.apk

Those were the most-recent versions of the BusyBox, Linux Deploy and VNC Viewer apps for Android that the Xoom could manage to install.

I downloaded the tarball LAIOT.tar.gz from the following Web page and extracted the file TiamatCWM.img from it:

https://sourceforge.net/projects/laiot/files/LAIOT.tar.gz/download?use_mirror=phoenixnap&r=&use_mirror=master

Note: Do NOT try to run the shell scripts in LAIOT, because they are out of date and will mess up the ADB and Fastboot tools in Linux on the desktop machine.

To be able to install Linux it was first necessary to root Android 4.0.4 on the Xoom. I used a modified version of the procedure given in the 2014 blog post Motorola Xoom Root on Linux:

• I installed ADB and Fastboot on a desktop machine running Lubuntu 20.10:

user $ sudo apt install adb
user $ sudo apt install fastboot

• I enabled the USB Debugging mode on the Xoom (‘Settings’ > ‘Developer options’).
• I downloaded the file Xoom-Universal-Root.zip from XDA Developers Forums thread [Root] Universal Xoom Root – ANY XOOM ANY UPDATE. The main link in that thread no longer works but a link in Post #411 in the thread still downloads the file.
• I inserted a 32 GB microSD card in the Xoom microSD Card slot.
• I connected the Xoom to the desktop machine via a USB cable.
• I copied the file Xoom-Universal-Root.zip to the microSD card.
• I checked connectivity:

user $ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached 
0299918743aad023        device

• I reboot the Xoom:

user $ adb reboot bootloader

• ‘Starting Fastboot protocol support’ was displayed on the Xoom’s boot screen. I typed the following commands on the desktop machine:

user $ fastboot oem unlock

• In response to a question on the text screen on the Xoom I pressed Volume Down (accept) then Volume Up (confirm).
• I repeated the process to confirm, i.e. I pressed Volume Down (accept) then Volume Up (confirm).
• ‘Device unlock operation in progress’ appeared on the Xoom screen and the Xoom rebooted.
• The bootloader was now unlocked.
• I typed the following commands on the desktop machine:

user $ adb reboot bootloader
user $ fastboot flash recovery TiamatCWM.img

• When flashing was complete I rebooted the Xoom by pressing Volume Up + the ON/OFF button.
• Upon booting, when the Motorola logo appeared I pressed Volume Down.
• ‘Android Recovery’ appeared in the top left corner of the screen.
• I pressed Volume Up to enter recovery mode.
• This mode is called ‘ClockworkMod recovery’. I selected ‘Install zip from sdcard’ > ‘Choose zip from sdcard’, then selected the zip file I had downloaded earlier to the microSD card (Use Volume Up/Down to navigate and ON/OFF to select).
• I rebooted, and root access was enabled. I verified this by downloading the Android app ‘Root Checker_v6.5.0_apkpure.com.apk’, copying it to the Xoom via USB, installing it and launching the app.

Now that the Xoom had been rooted, I could proceed with installing Linux in a chroot. To do this I followed the procedure given in the 2017 Android Authority article How to install a Linux desktop on your Android device. In the Linux Deploy app I selected ‘Ubuntu’ as the distribution, ‘Precise [Pangolin]’ as the distribution suite, and LXDE as the desktop environment. I installed the three apps BusyBox, Linux Deploy and VNC Viewer, launched the BusyBox app and tapped ‘Install’. Then I launched Linux Deploy, tapped the configuration icon next to the STOP button in the top right of the screen and configured Linux Deploy as follows:

BOOTSTRAP

	Distribution
	Ubuntu

	Architecture
	armhf

	Distribution suite
	precise

	Source path
	http://ports.ubuntu.com/

	Installation type
	File

	Installation path
	${EXTERNAL_STORAGE}/linux.img

	Image size (MB)
	Automatic calculation

	File system
	ext4

	User name
	root

	User password
	android

	Privileged users
	root

	Localization
	C

	DNS
	Automatic detection

	Network trigger

	Power trigger

INIT

	Enable
	Allow to use a initialization system  <--- NOT TICKED

	Init system
	run-parts

	Init settings
	Change settings for the initialization system

MOUNTS

	Enable
	Allow to mount the Android resources  <--- NOT TICKED

	Mount points
	Edit the mount points list

SSH

	Enable
	Allow to use a SSH server  <--- NOT TICKED

	SSH settings
	Change settings for SSH server

PULSEAUDIO

	Enable
	Allow to use an audio output  <--- NOT TICKED

GUI

	Enable
	Allow to use a graphical environment  <--- TICKED

	Graphics subsystem
	VNC

	GUI settings
	Change settings for the graphics subsystem

	Desktop environment
	LXDE

Then I tapped the three-dot icon in the top right of the screen, tapped ‘Install’ then ‘OK’. Once the messages on the screen stopped scrolling and a final message ‘<<< deploy’ was displayed, I tapped the START arrow and ‘OK’.

I launched VNC Viewer, tapped the ‘+’ icon to add a new connection, entered ‘localhost:5900’ for the address and ‘Linux’ for the name, tapped ‘CREATE’ then ‘CONNECT’. From there I was prompted to enter the password I had specified previously under ‘User password’ (see above), and the LXDE Desktop was displayed.

After following the procedure in the above-mentioned article to configure and install the Linux image, subsequently I use the following steps to start and stop Linux on the Xoom:

To start Linux on the Xoom, use Linux Deploy.
Press the ‘START’ arrow at the top right of the Linux Deploy screen.
Then open VNC and press ‘Connect’.

To exit Linux on the Xoom, use Linux Deploy.
Tap the square ‘STOP’ button at the top right of the Linux Deploy screen.
Tap ‘OK’ to ‘Stop services & unmount the container’.
Then tap the menu button (three horizontal bars) at the top left of the Linux Deploy screen.
Tap ‘Exit’.

To exit VNC Viewer:
Press the ‘Recent Apps’ icon (two overlapping rectangles) at the bottom left of the Xoom’s Android screen.
Swipe to the left to close the app.

The phone name assigned automatically by Android on my new phone prevented Bluetooth pairing and connecting in Linux

I recently installed Lubuntu 20.10 on a desktop machine, but Bluetooth did not work with my new phone (Samsung Galaxy Note 20 Ultra with Android 11). Bluetooth had worked fine in Lubuntu 18.04 on the same desktop machine with my previous Android phone (Samsung Galaxy Note 8 with Android 9).

The first thing I discovered was that, although the Lubuntu 20.10 Installer had installed Bluez, it had not installed a Bluetooth manager, so I installed Blueman:

$ sudo apt install blueman

Then, I re-installed Bluez just to be sure:

$ sudo apt install --reinstall bluez

The Bluetooth device was detected but Lubuntu 20.10 would not pair with my new phone.

The Bluetooth device was definitely unblocked:

$ rfkill --output-all
ID TYPE      DEVICE TYPE-DESC         SOFT      HARD
 1 wlan      phy0   Wireless LAN unblocked unblocked
 2 bluetooth hci0   Bluetooth    unblocked unblocked

Now, the phone name Android 11 had assigned automatically to my new phone was Fitzcarraldo’s Galaxy Note20 Ultra 5G. After trying many things, I began to wonder if the apostrophe in the phone name was causing the problem, so I changed the name in the phone (Settings > About phone > Edit) to Fitzcarraldo Galaxy Note20 Ultra 5G. Blueman/Bluez were then able to pair with, and connect to, the phone. Problem solved, but what a silly cause.

Using WS-Discovery to enable Windows 10 to browse SMB shares in my home network of Linux computers

I have not used Windows 10 for more than two years now (see ‘Bye bye Windows 10, and good riddance‘ regarding my failed attempts to upgrade Windows 10 Version 1607 to 1703 and 1709). Nevertheless I am aware that, since Version 1709, Windows 10 no longer has SMBv1 and Computer Browser service installed by default. Computer Browser service used NetBIOS and SMBv1 to provide what Microsoft named ‘My Network Places‘ or ‘Network Neighborhood’. Thus Microsoft has dropped the concepts of network ‘workgroups’, ‘master browsers’, NetBIOS, NetBIOS broadcasts, WINS and so on. SMB has not been dropped, though; Versions 2 and 3 of the SMB protocol are now used, albeit using a different mechanism for device discovery.

Although they perform different jobs, Microsoft bundled the Computer Browser service software with the SMBv1 software. Microsoft could have provided them separately, but it made some sense to bundle them together in the early days of Windows networking. Thus, as SMBv1 is not installed by default in Windows 10 Version 1709 and later versions, neither is Computer Browser service. To put it another way, if you install SMBv1 in Windows 10 you automatically install Computer Browser service as well. None of that interested me since I stopped using Windows 10 after Version 1607. Since then my home network has comprised a server, desktop and laptops running various Linux distributions with Samba and using broadcast NetBIOS for name resolution. Of course I know that NetBIOS — especially broadcast NetBIOS for name resolution — is ancient networking technology, but it works well for my home networking needs. All my machines can browse each other’s SMB shares and create/copy/move/delete remote files and folders. The File Manager + app on my phone running Android 9 can also browse SMB shares on the Linux machines and create/copy/move/delete remote files and folders.

Two of my blog posts from 2016 and 2017 explain how I set up my home network for file sharing. One of the machines in the network had Windows 10 1607 installed, but that was replaced with Lubuntu in 2018.

• A correct method of configuring Samba for browsing SMB shares in a home network
• Prevent Linux firewalls interfering with Samba commands in a home network that uses broadcast NetBIOS name resolution

SMBv1 is an inherently insecure protocol, so, after I dropped Windows, I reconfigured Samba on my Linux machines to use only SMBv3, which works fine. Subsequently I found that Android 9 on my Samsung Galaxy Note 8 phone apparently does not support SMBv3, only SMBv1 and SMBv2, so I reconfigured Samba on my Linux machines to allow SMBv2 as well as SMBv3. In other words, the Linux machines use SMBv3 with each other but SMBv2 with the phone (see my comments in the Comments section of my 2016 post ‘A correct method of configuring Samba for browsing SMB shares in a home network‘).

Anyway, I happen to have an evaluation copy of Windows 10 Enterprise Version 1709 installed in a VirtualBox VM (virtual machine) on one of my Linux laptops and, purely to satisfy my curiosity, I decided to try to get Windows 10 Version 1709 to browse and access SMB shares on the Linux machines in my home network, and vice versa, without having to dispense with broadcast NetBIOS name resolution for the Linux machines and without having to install SMBv1 (and Computer Browser service) in Windows 10.

When I first booted Windows 10 Enterprise 1709, SMB shares on my Linux machines were not displayed in File Explorer, and Windows 10 could not find them if I entered the UNC (Universal Naming Convention) address ‘\\hostname\foldername‘ or ‘\\IPaddress\foldername‘ (e.g. ‘\\AKHANATEN\anne‘ or ‘\\192.168.1.70\anne‘) in File Explorer’s address bar. My Web searches indicated that many people cannot see SMB shares in File Explorer either but can access a share by entering the UNC address in the File Explorer address bar. Apparently the advice from Microsoft these days is to use ‘Map a Network Drive…’ in File Explorer. Therefore, given that I wanted to be able to browse SMB shares in ‘File Explorer’ > ‘Network’, I clearly had some work to do. My goal for Windows 10 was twofold: to be able to view my remote SMB shares in Windows 10 File Explorer automatically and to be able to access (copy/move/delete/open) my remote SMB shares in Windows 10 File Explorer. Of course I also wanted to be able to browse and access SMB shares on the Windows 10 machine from the Linux machines.

Now, Windows 10 comes with Web Services Dynamic Discovery (WS-Discovery) installed. This enables SMB hosts running WS-Discovery software to be found by clients running WS-Discovery software. I believe Version 20.04 of the KDE Applications package kio-extras will support SMB host discovery using WS-Discovery, but that version is not available in the Stable Branch of Gentoo Linux installed on my main laptop, nor in Lubuntu 18.04 which is installed on my family’s desktop machine. So I thought I would have a look at what is currently available for those two distributions. I was particularly interested to see if I could find an implementation of WS-Discovery for Linux that would run in parallel with broadcast NetBIOS name resolution currently installed on the Linux machines in my home network, as broadcast NetBIOS name resolution works fine with SMBv2 and SMBv3 for Linux and Android devices in a home network (my Samsung Galaxy Note 8 phone can browse the SMB shares on any of the Linux machines in my home network).

Thanks are due to Steffen Christgau for creating a daemon that can be used in Linux installations to enable Windows 10 to discover SMB shares on Linux machines via WS-Discovery: wsdd – A Web Service Discovery host daemon. The README file for wsdd states:

wsdd implements a Web Service Discovery host daemon. This enables (Samba) hosts, like your local NAS device, to be found by Web Service Discovery Clients like Windows.

It also implements the client side of the discovery protocol which allows to search for Windows machines and other devices implementing WSD. This mode of operation is called discovery mode.

wsdd only depends on Python 3 and can be installed in many Linux distributions. If no wsdd package exists for a specific distribution, it can simply be run from the command line or from a Bash script. The following blog post by Ralph Mönchmeyer explains how to use wsdd (although not a complete solution for my specific case): Samba 4, shares, wsdd and Windows 10 – how to list Linux Samba servers in the Win 10 Explorer.

Below I list the steps I took to enable me to browse SMB shares in an evaluation copy of Windows 10 Enterprise Version 1709 running in a VM on one of my Linux laptops. I don’t have access to the latest version of Windows 10 (2004), but hopefully some or most of the following will still be applicable.

Step 1. Disable firewalls temporarily

I disabled the firewall in the Linux machine and in the Windows 10 machine so that the firewalls could be ruled out if there were any problems getting share browsing to work. Once all the steps were completed I re-enabled the firewalls.

Step 2. Specify the workgroup in Windows 10

Select ‘Control Panel’ > ‘System and Security’ > ‘System’ and, under ‘Computer name, domain, and workgroup settings’, if necessary click ‘Change settings’ to rename the workgroup. The default workgroup name was ‘WORKGROUP‘ so I renamed it to ‘HOME‘, my current network’s workgroup.

Step 3. Ensure the correct SMB protocol in Windows 10

SMBv1 (and Computer Browser service) are disabled by default in Windows 10 Version 1709 and later (see ‘SMBv1 is not installed by default in Windows 10 version 1709, Windows Server version 1709 and later versions‘) but I nevertheless made sure that SMBv1 is disabled and that SMBv2 and SMBv3 are installed (see ‘How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows‘). I did the following in PowerShell (Run as administrator):

PS C:\WINDOWS\system32> Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

PS C:\WINDOWS\system32> Set-SmbServerConfiguration -EnableSMB2Protocol $true

Step 4. Disable NetBIOS-over-TCP/IP in Windows 10

Select ‘Settings’ > ‘Network & Internet’ > ‘Ethernet’ > ‘Change adapter options’.

Right-click ‘Ethernet’, click ‘Properties’, select ‘Internet Protocol Version 4 (TCP/IPv4)’ and click ‘Properties’. Click ‘Advanced’. Click on the WINS tab (even though my network does not use WINS), select ‘Disable NetBIOS over TCP/IP’ and click ‘OK’, ‘OK’ and ‘Close’.

Step 5. Configure ‘Function Discovery’ in Windows 10

See the article ‘SMBv1 is not installed by default in Windows 10 version 1709, Windows Server version 1709 and later versions | Microsoft Docs‘, in particular the following:

Explorer Network Browsing

The Computer Browser service relies on the SMBv1 protocol to populate the Windows Explorer Network node (also known as “Network Neighborhood”). This legacy protocol is long deprecated, doesn’t route, and has limited security. Because the service cannot function without SMBv1, it is removed at the same time.

However, if you still have to use the Explorer Network in home and small business workgroup environments to locate Windows-based computers, you can follow these steps on your Windows-based computers that no longer use SMBv1:

1. Start the “Function Discovery Provider Host” and “Function Discovery Resource Publication” services, and then set them to Automatic (Delayed Start).
2. When you open Explorer Network, enable network discovery when you are prompted.

All Windows devices within that subnet that have these settings will now appear in Network for browsing. This uses the WS-DISCOVERY protocol. Contact your other vendors and manufacturers if their devices still don’t appear in this browse list after the Windows devices appear. It is possible they have this protocol disabled or that they support only SMBv1.

Press Windows Key+R, enter ‘services.msc‘ (without the quotes) and click ‘OK’.

Change the ‘Startup type’ of ‘Functions Discovery Provider Host’ to ‘Automatic (Delayed Start)’.

Change the ‘Startup type’ of ‘Function Discovery Resource Publication’ to ‘Automatic (Delayed Start)’.

Step 6. Configure the sharing options in Windows 10

Select ‘Settings’ > ‘Network & Internet’ > ‘Sharing options’ and configure the options as follows:

Private (current profile)

1. Network discovery
   • ‘Turn on network discovery’ is selected.
   • ‘Turn on automatic setup of network connected devices.’ is ticked.
2. File and printer sharing
   • ‘Turn on file and printer sharing’ is selected.
3. HomeGroup connections
   • ‘Allow Windows to manage homegroup connections (recommended)’ is selected.

Guest or Public

1. Network discovery
   • ‘Turn on network discovery’ is selected.
2. File and printer sharing
   • ‘Turn on file and printer sharing’ is selected.

All Networks

1. Public folder sharing
   • ‘Turn on sharing so anyone with network access can read and write files in the Public folders’ is selected.
2. Media streaming
   • Nothing is selected.
3. File sharing connections
   • ‘Use 128-bit encryption to help protect file sharing connections (recommended)’ is selected.
4. Password protected sharing
   • ‘Turn off password protected sharing’ is selected.

Step 7. Install WS-Discovery daemon on the Linux machines

Gentoo Linux
In Gentoo I simply installed the package net-misc/wsdd from the guru overlay:

root # eix -I wsdd
[I] net-misc/wsdd [1]
     Available versions:  (~)0.5 (~)0.6 {samba PYTHON_TARGETS="python3_6 python3_7 python3_8"}
     Installed versions:  0.6(00:39:07 07/06/20)(-samba PYTHON_TARGETS="python3_7 -python3_6 -python3_8")
     Homepage:            https://github.com/christgau/wsdd
     Description:         A Web Service Discovery host daemon.

[1] "guru" /var/lib/layman/guru

and, as I use OpenRC in Gentoo, I configured /etc/conf.d/wsdd.conf as follows:

# /etc/conf.d/wsdd

# Override the default user/group under which wsdd runs.
# Must follow the user[:group] notation.
#WSDD_USER="daemon:daemon"

# Specify alternative log file location.
#WSDD_LOG_FILE="/var/log/wsdd.log"

# Disable automatic detection of the workgroup from samba configuration.
#WSDD_WORKGROUP="MYGROUP"
WSDD_WORKGROUP="HOME"

# Additional options for the daemon, e.g. to listen on interface eth0 only.
# Refer to wsdd(1) for details.
#WSDD_OPTS="-i eth0"
WSDD_OPTS="--shortlog --interface enp4s0f1 --interface wlp3s0 --hostname tutankhamun --discovery"

Specifying the interfaces and hostname are optional, but wsdd seemed to work better when I specified them explicitly. You can ascertain the interfaces by using the command ‘ip address‘ or the deprecated command ‘ifconfig‘.

I added the service to the default runlevel so that it is started automatically when I boot the machine, and then I started it:

root # rc-update add wsdd default
root # rc-service wsdd start

Lubuntu 18.04

In Lubuntu 18.04 (which uses systemd) wsdd can be installed either manually or from a package:

a) Manual installation

user $ wget https://github.com/christgau/wsdd/archive/master.zip
user $ unzip master.zip
user $ sudo cp wsdd-master/src/wsdd.py /usr/bin/wsdd
user $ sudo cp wsdd-master/etc/systemd/wsdd.service /etc/systemd/system/

Edit the systemd service file /etc/systemd/system/wsdd.service to add desired options to the ExecStart command and to change the group from ‘nobody‘ to ‘nogroup‘:

...
ExecStart=/usr/bin/wsdd --workgroup HOME --shortlog --interface eno1 --interface wlp2s0 --hostname thutmoseiii --discovery
...
User=nobody
Group=nogroup
...

You can check whether the user and group exist in your installation as follows:

user $ grep ^nobody /etc/passwd
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
user $ grep ^nobody /etc/group
user $ grep ^nogroup /etc/group
nogroup:x:65534:

Actually, I prefer to specify ‘daemon‘ for the user and group in the wsdd.service file (which is also what the Gentoo Linux ebuild uses and what the .deb package uses):

...
ExecStart=/usr/bin/wsdd --workgroup HOME --shortlog --interface eno1 --interface wlp2s0 --hostname thutmoseiii --discovery
...
User=daemon
Group=daemon
...

You can check that this user and group also exist:

user $ grep ^daemon /etc/passwd
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
user $ grep ^daemon /etc/group
daemon:x:1:

(I tried both nobody:nogroup and daemon:daemon, and there was no apparent difference in behaviour.)

Enable the service so that it starts automatically when the machine is booted, and also start it now:

user $ sudo systemctl enable wsdd
user $ sudo systemctl start wsdd

b) Installing from a package

Here is a link to a .deb package for wsdd Version 0.6.0:

https://pkg.ltec.ch/public/pool/main/w/wsdd/

The resulting installation differs slightly from the manual procedure; the package creates a configuration file /etc/wsdd.conf and you declare the wsdd options in that file instead:

# command line parameters for wsdd (consult man page)
WSDD_PARAMS=""

The package also installs a systemd service file /lib/systemd/system/wsdd.service containing the following:

[Unit]
Description=Web Services Dynamic Discovery host daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
EnvironmentFile=/etc/wsdd.conf
ExecStart=/usr/bin/wsdd $WSDD_PARAMS
User=daemon
Group=daemon

[Install]
WantedBy=multi-user.target

The package installs the Python 3 executable wsdd in the directory /usr/bin/. It’s a very straightforward package.

Step 8. Configure Samba to make Windows 10 prompt for username and password

When you click on a network share in Windows 10’s File Explorer, Windows 10 uses the Windows 10 username and password to try to access the SMB share on the remote machine (see ‘Samba share does not ask for credentials from Windows Client‘). This will obviously not work unless the usernames/passwords on both machines match. To make Windows 10 prompt the user to enter the remote username and password, edit the file /etc/samba/smb.conf on each Linux machine and comment out the line ‘map to guest = bad user‘ (see the smb.conf files listed in my 2016 article ‘A correct method of configuring Samba for browsing SMB shares in a home network‘).

Step 9. Enable guest access in Windows 10

If I enter a SMB share’s UNC address in File Explorer’s address bar, or if I double-click on the remote machine’s icon in File Explorer (after WS-Discovery has made the SMB share visible in File Explorer), Windows 10 displays the following error message:

Network Error

Windows cannot access \\hostname

Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.

Error Code: 0x80070035
The network path was not found.

This has nothing to do with the fact that SMBv1 is disabled in Windows 10. It happens because Windows 10 1709 and onwards have guest logins disabled:

• Guest access in SMB2 disabled by default in Windows
• Windows 10 and Linux Samba Problem: ‘Windows cannot access \\hostname’
• Windows 10 1709 Cannot Access SMB2 Share Guest Access
• Policy CSP – LanmanWorkstation

To enable guest logins I edited the Windows 10 Registry and changed the following key from zero to one:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]

“AllowInsecureGuestAuth”=dword:1

Step 10. Configure the Windows 10 firewall

Select ‘Windows Defender Security Center’ > ‘Firewall & network protection’.

Click ‘Allow an app through the firewall’.

If not already ticked, select ‘Private’ and ‘Public’ for ‘Network Discovery’ and for ‘File and Printer Sharing’.

Step 11. Configure the Linux firewall

This is where things get more complicated. According to the README for wsdd:

Firewall Setup

Both incoming and outgoing multicast traffic on port 3702 must be allowed. For IPv4, the multicast address is 239.255.255.250, for IPv6 the link local SSDP multicast address (ff02::c) is used.

Incoming TCP traffic (and related outgoing traffic) on port 5357 must be allowed.

My laptops and desktop use UFW, and below I explain how I configured UFW to satisfy the above requirements.

Firstly, as my firewall is configured to deny incoming traffic and allow outgoing traffic by default, I enabled UFW and added the following DNS rules to UFW’s main rules (the following two commands add rules for both IPv4 and IPv6):

user $ sudo ufw allow 53/tcp
user $ sudo ufw allow 53/udp

Note that, in order for the multicast rule I use to work, xt_pkttype must either have been built into the kernel or built as a kernel module and have been loaded:

user $ lsmod | grep pkttype
xt_pkttype             16384  2
x_tables               40960  17 ip6table_filter,xt_conntrack,iptable_filter,xt_LOG,xt_multiport,xt_tcpudp,xt_addrtype,ip6t_rt,ip6_tables,ipt_REJECT,xt_CT,xt_pkttype,iptable_raw,ip_tables,xt_limit,xt_hl,ip6t_REJECT

To load the module automatically at boot, in Gentoo Linux I added ‘xt_pkttype‘ to the list of modules in the file /etc/conf.d/modules, and in Lubuntu 18.04 I added ‘xt_pkttype‘ to the list of modules in the file /etc/modules-load.d/modules.conf.

Also note that my firewall had previously already been configured for NetBIOS and SMB by using the following commands:

user $ # Rules for SMB
user $ # IPv4:
user $ sudo ufw allow from 192.168.1.0/24 to any port 137,138 proto udp
user $ sudo ufw allow from 192.168.1.0/24 to any port 139,445 proto tcp
user $ # IPv6:
user $ # (NetBIOS is undefined for IPv6 but I believe SMB uses Port 445 in IPv6)
user $ sudo ufw allow from ff80::/10 to any port 445 proto tcp

IPv4

The end of the file /etc/ufw/before.rules previously looked like this:

...
# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT
# The following is needed to enable Samba commands to
# work properly for broadcast NetBIOS name resolution
#
# raw table rules
*raw
:OUTPUT ACCEPT [0:0]
-F OUTPUT
-A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns
COMMIT

I inserted seven lines as shown below:

...
# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# allow MULTICAST WS-Discovery for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -m pkttype --pkt-type multicast -j ACCEPT
-A ufw-before-input -p udp -s 192.168.1.0/24 --dport 3702 -j ACCEPT
-A ufw-before-input -p udp -s 192.168.1.0/24 --sport 3702 -j ACCEPT
-A ufw-before-input -p tcp -s 192.168.1.0/24 --dport 5357 -j ACCEPT
-A ufw-before-input -p tcp -s 192.168.1.0/24 --sport 5357 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT
# The following is needed to enable Samba commands to
# work properly for broadcast NetBIOS name resolution
#
# raw table rules
*raw
:OUTPUT ACCEPT [0:0]
-F OUTPUT
-A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns
COMMIT

Actually the two IPv4 rules shown above for mDNS and UPnP that were already in the file /etc/ufw/before.rules have become redundant because the first of the five new rules I added encompasses them. It does no harm to leave those two rules in the file, though.

IPv6

The end of the file /etc/ufw/before6.rules previously looked like this:

...
# allow MULTICAST mDNS for service discovery
-A ufw6-before-input -p udp -d ff02::fb --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery
-A ufw6-before-input -p udp -d ff02::f --dport 1900 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

I inserted six lines as shown below:

...
# allow MULTICAST mDNS for service discovery
-A ufw6-before-input -p udp -d ff02::fb --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery
-A ufw6-before-input -p udp -d ff02::f --dport 1900 -j ACCEPT

# allow MULTICAST WS-Discovery for service discovery
-A ufw6-before-input -m pkttype --pkt-type multicast -j ACCEPT
-A ufw6-before-input -p udp -s fe80::/10 --dport 3702 -j ACCEPT
-A ufw6-before-input -p udp -s fe80::/10 --sport 3702 -j ACCEPT
-A ufw6-before-input -p tcp -s fe80::/10 --dport 5357 -j ACCEPT
-A ufw6-before-input -p tcp -s fe80::/10 --sport 5357 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

Actually the two IPv6 rules shown above for mDNS and UPnP that were already in the file /etc/ufw/before6.rules have become redundant because the first of the five new rules I added encompasses them. It does no harm to leave those two rules in the file, though.

Because the Linux machines in my network still use broadcast NetBIOS for name resolution I left all the NetBIOS rules in UFW as they were, including the extra lines I previously added to /etc/ufw/before.rules (see the raw table rule at the end of /etc/ufw/before.rules listed above and my blog post ‘Prevent Linux firewalls interfering with Samba commands in a home network that uses broadcast NetBIOS name resolution‘).

Actually, as my laptops change firewall zones automatically (see my post ‘Firewall zones (profiles) in Linux, and how to switch them automatically if you use UFW‘), on my laptops I added the new rules to the zone for my home network specified in my NetworkManager Dispatcher hook script /etc/NetworkManager/dispatcher.d/20_ufw-zones.

After reloading UFW, the UFW status on my machines now looks like this (I’ve excluded rules unrelated to this topic):

user $ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
137,138/udp                ALLOW IN    192.168.1.0/24
139,445/tcp                ALLOW IN    192.168.1.0/24
53/tcp                     ALLOW IN    Anywhere
53/udp                     ALLOW IN    Anywhere
445/tcp                    ALLOW IN    ff80::/10
53/tcp (v6)                ALLOW IN    Anywhere (v6)
53/udp (v6)                ALLOW IN    Anywhere (v6)

Note that UFW does not display rules declared in /etc/ufw/{before,before6}.rules

Step 12. Re-enable the Windows 10 firewall

Select ‘Settings’ > ‘Network & Internet’ > ‘Windows Firewall’.

Step 13. Check that wsdd is working as expected

To check that wsdd is actually detecting other machines running WS-Discovery, you can stop the daemon running and instead launch wsdd manually in a terminal window with verbose logging enabled.

For example, on my laptop running Gentoo Linux I did the following:

user $ sudo rc-service wsdd stop
user $ wsdd --workgroup HOME --verbose --interface enp4s0f1 --interface wlp3s0 --hostname tutankhamun --discovery

And on my family’s desktop running Lubuntu 18.04 I did the following:

user $ sudo systemctl stop wsdd
user $ wsdd --workgroup HOME --verbose --interface eno1 --interface wlp2s0 --hostname thutmoseiii --discovery

Check the output in the terminal window includes a discovered line for each machine running Windows 10 and for each Linux machine running wsdd. For example:

...
2020-06-16 00:31:09,331:wsdd INFO(pid 17574): discovered MSWIN10PC in Workgroup:HOME on 192.168.1.111%eno1
...
2020-06-16 00:31:10,013:wsdd INFO(pid 17574): discovered MSWIN10PC in Workgroup:HOME on [fe80::fc7e:7068:8c2c:e664]%eno1
...

After pressing Ctrl+C to stop wsdd running in the terminal, you can restart the daemon:

Gentoo Linux

user $ sudo rc-service wsdd start

Lubuntu 18.04

user $ sudo systemctl start wsdd

With wsdd running on the Linux machines they become visible in File Explorer on Windows 10 machines connected to the network. However, the converse is not necessarily true, as explained further on.

As I had previously configured Samba on my Linux machines to use broadcast NetBIOS to resolve names, Samba on the Linux machines fails to resolve the hostnames of the Windows 10 machines because Windows 10 no longer supports NetBIOS name resolution (neither broadcast nor WINS). I confirmed this by using the smbclient command in a terminal window:

user $ sudo smbclient //MSEDGEWIN10/TestSMBShare1 --debuglevel=10
...
added interface eno1 ip=192.168.1.111 bcast=192.168.1.255 netmask=255.255.255.0
Netbios name list:-
my_netbios_names[0]="THUTMOSEIII"
Client started (version 4.7.6-Ubuntu).
Opening cache file at /var/cache/samba/gencache.tdb
Opening cache file at /var/run/samba/gencache_notrans.tdb
sitename_fetch: No stored sitename for realm ''
internal_resolve_name: looking up MSEDGEWIN10#20 (sitename (null))
no entry for MSEDGEWIN10#20 found.
name_resolve_bcast: Attempting broadcast lookup for name MSEDGEWIN10
Connection to MSEDGEWIN10 failed (Error NT_STATUS_UNSUCCESSFUL)

However, in Gentoo Linux (Stable Branch, KDE Plasma 5.18.5, KDE Applications 19.12.3) on my main laptop I can enter ‘smb://hostname/sharename‘ (e.g. smb://msedgewin10/Users/Public) in the Dolphin file manager’s address bar and browse the contents of the SMB share on the Window 10 machine. I assume this is because Avahi on the Linux machine performs name resolution anyway even though the broadcast NetBIOS lookup has failed. Although Lubuntu 18.04 also has the Avahi daemon running, it does not resolve the hostname when I enter ‘smb://hostname/sharename‘ in PCManFM’s address bar; I have to enter ‘smb://IPaddress/sharename‘ (e.g. smb://192.168.1.64/Users/Public) to be able to browse the contents of the Windows 10 shared folder.

Conclusion

wsdd running on Linux machines enables Windows 10 to view networked Linux machines in File Explorer and browse SMBv2 and SMBv3 shares residing on Linux machines. It does not guarantee I will be able to view Windows 10 machines in Linux file managers automatically, though. But I can access Windows 10 machines by entering ‘smb://IPaddress/sharename‘ in the Linux file manager’s address bar, or, depending on what has been installed in the Linux installation and how it has been configured, by entering ‘smb://hostname/sharename‘.

To access a Linux SMB shared folder (as declared in that machine’s smb.conf file) in Windows 10 File Explorer, either I double-click on the Linux machine’s icon in the Network view or I enter the UNC address (e.g. \\tutankhamun\Users\Public) in the address bar. I can then access the files and sub-folders.

To browse a Windows 10 SMB shared folder and files in KDE Dolphin in Gentoo Linux current Stable Branch on my main laptop, I enter the UNC address (e.g. smb://msedgewin10/Users/Public) or click on the location I previously bookmarked under ‘Places’ in the left pane of the Dolphin window. I can then access the files and sub-folders. To browse a Windows 10 SMB shared folder and files in LXDE PCManFM in Lubuntu 18.04, I enter the UNC address with an IP address instead of a hostname (e.g. smb://192.168.1.64/Users/Public). I can then access the files and sub-folders. I am going to have to do some more digging to try to find out why KDE Dolphin in Gentoo Linux on my main laptop (kio-extras installed from Gentoo ebuild kio-extras-19.12.3-r2) can access Windows 10 by hostname but PCManFM in Lubuntu 18.04 cannot.

To enable machines running Window 10 to browse SMB shares on my other Linux machines I would need to perform the same Linux-related steps in each of those installations. My server firewall uses IPTABLES directly, rather than UFW, so the syntax of the additional firewall rules would be different.

Addendum, 16 June 2020: I suspected the problem browsing the Windows 10 SMB shares from Lubuntu 18.04 is due to PCManFM, so I installed a different file manager: SpaceFM (Version 1.0.5 for GTK2) and its associated utility udevil (Version 0.4.4). SpaceFM allows me to enter UNC addresses such as ‘smb://mswin10pc/Users/Public‘ without any problems. So, problem solved in Lubuntu 18.04 now as well.

Jitsi Meet, my favourite video conferencing platform (and a way to share audio when using it in Linux)

During the current COVID-19 lockdown I have been using video conferencing platforms a lot for family virtual meet-ups, quizzes and multi-player games by Jackbox Games. Zoom seems to be the most popular video conference platform at the moment, although several articles in the media have pointed out some of its security limitations (see, e.g., ‘‘Zoom is malware’: why experts worry about the video conferencing platform‘). Although many people like Zoom, my favourite video conferencing platform is Jitsi Meet.

For an excellent third-party video introduction to Jitsi Meet, watch the video: ‘Using Jitsi: A free, no-registration video conferencing site‘. WIRED Magazine’s recent article on Jitsi Meet is also worth reading: ‘Want to Ditch Zoom? Jitsi Offers an Open-Source Alternative‘.

The reasons I prefer Jitsi Meet to Zoom include the following:

1. no subscriptions are required to use all the features of Jitsi Meet;
2. unlike Zoom, Jitsi Meet does not require you to sign up;
3. unlike Zoom, Jitsi Meet does not require the installation of an application — it runs in Google Chrome or Firefox;
4. unlike the free version of Zoom, Jitsi Meet does not impose a time limit on the length of the meeting;
5. unlike the free version of Zoom, Jitsi Meet does not have a limit on the number of meeting attendees;
6. Jitsi Meet provides end-to-end encryption for one-to-one video calls*;
7. I find the performance of Jitsi Meet better than Zoom, which seems to be corroborated in basic benchmarking by Jitsi Meet’s developers (‘WebRTC vs. Zoom – A Simple Congestion Test‘);
8. I find image quality better in Jitsi Meet;
9. I find Jitsi Meet on a desktop/laptop more intuitive and easier to use than Zoom;
10. if I share audio in Zoom for Linux, the audio is very distorted**;
11. I find the UI of the Jitsi Meet app for Android easy to use (the app can be installed via Google Play);
12. Jitsi Meet is open-source, so anyone can inspect the source code;
13. if I wanted to, I could download the Jitsi software to my own server and set up a Jitsi Meet server to handle meetings instead of using the Cloud server provided by 8×8, Inc. (the company that develops the Jitsi Meetings software).

* Neither platform currently provides end-to-end encryption for group meetings, although the developers of Jitsi Meet are apparently working on implementing end-to-end encryption for group meetings using a new feature of Google Chrome called ‘Insertable Streams’.

** There is a work-around for this problem in Zoom for Linux; see my answer to the Unix & Linux Stack Exchange question ‘Play audio output as input to Zoom’. In the case of Jitsi Meet in Linux, PulseAudio Volume Control can be used to share audio, as I explain further down.

Jitsi Meet requires no installation; it runs in a browser window. Either Google Chrome or Firefox can be used, although I find it runs better in Google Chrome. Actually, an Ubuntu 16.04 user told me that Firefox hangs when he tries to join a Jitsi Meet meeting, but Jitsi Meet works fine in Firefox in my two Gentoo Linux installations and in my family’s Lubuntu 18.04 installation. When using Google Chrome, to be able to share your screen you need to install the Google Chrome extension ‘Jitsi Meetings’ by meet.ji.si in the Google Chrome Web Store.

One of my family here at home has a laptop running Windows 10. Google Chrome, but not Firefox, displays a ‘Share audio’ tick box when the ‘Share your screen’ icon is clicked (see ‘Jitsi Meet features update, April 2020‘). The ‘Share audio’ feature is needed when, for example, you are casting via the Internet to remote players a multi-user game running on your machine. During the current COVID-19 lockdown we have been having fun playing Jackbox Games Party Pack 6 this way with family and friends in different locations (see ‘(My Solution) Best method for Virtual Couch Multiplayer‘). Each household connects a laptop to their TV via HDMI and joins the Jitsi Meet meeting. The Jackbox Games games are cast via Jitsi Meet from the laptop at my house, and the group of players in each household can view and hear the game on their TV and participate using their mobile phones as per the Jackbox Games paradigm.

Jitsi Meet provides a ‘Share audio’ function in Windows only, but I found a work-around to to be able to share any application’s audio in Linux if I ever want to use my Linux machines to cast games by Jackbox Games or other suppliers. For once, I have found PulseAudio useful! I use PulseAudio Volume Control to redirect the audio output from the desired application (be it a game, music player, video player or whatever) to the microphone input. The precise way to do this depends on the audio hardware your machine has, but an example is given in the blog post: ‘Redirect Audio Out to Mic In (Linux)‘.

My family’s desktop machine running Lubuntu 18.04 uses a Webcam with an integral microphone connected via USB, and external powered speakers connected to the machine’s Line Out green-coloured 3.5 mm jack socket. The contents of the tabs in PulseAudio Volume Control when no applications that produce audio are running are shown in the following screenshots:

I make sure ‘All Streams’ is selected on the ‘Playback’ and ‘Recording’ tabs, ‘All Output Devices’ is selected on the ‘Output Devices’ tab, and ‘All Input Devices’ is selected on the ‘Input Devices’ tab.

Let us say I have launched Audacious to play some music and I want to cast that music to members of a Jitsi Meet meeting. When I am using Jitsi Meet for a meeting in Google Chrome, the contents of the PulseAudio Volume Control tabs on this machine are as follows:

To redirect the audio from e.g. Audacious to the meeting members, I select (click on the square button with the green disc and white tick) ‘Monitor of Built-in Audio Analogue Stereo’ on the ‘Input Devices’ tab, and on the ‘Recording’ tab I click on Chrome input: RecordStream from ‘Camera Analogue Mono’ and select Chrome input: RecordStream from ‘Monitor of Built-in Audio Analogue Stereo’, as shown below.

With the above settings in PulseAudio volume control, all the members of the meeting will be able to hear clearly the audio from Audacious. To switch back to my microphone to speak, I simply click on Chrome input: RecordStream from ‘Monitor of Built-in Audio Analogue Stereo’ on the ‘Recording’ tab and select Chrome input: RecordStream from ‘Camera Analogue Mono’ again.