.vimrc

packadd! matchit
filetype plugin indent on
syntax on
set directory=~\vimfiles\swap undofile undodir=~\vimfiles\undo ruler visualbell incsearch ignorecase hlsearch smartcase showmatch autoindent backspace=2 wildmenu
set grepprg=rg.exe\ --vimgrep\ -i
set grepformat=%f:%l:%c:%m
nnoremap <leader>b <Esc>:ls<Cr>:b *
nnoremap <leader>e <Esc>:e *
nnoremap <leader>s <Esc>:split +b *
nnoremap <leader>E <Esc>:e %:h\*
nnoremap <leader>S <Esc>:s %:h\*
nnoremap <leader>w <Esc>:bw
nnoremap <leader>y "+y
vnoremap <leader>y "+y
nnoremap <leader>Y "+Y
nnoremap <leader>p "+p
vnoremap <leader>p "+p
nnoremap <leader>P "+P
nnoremap <BS>      <Esc>:let @/=""<Cr>
nnoremap <C-s>     <Esc>:up<Cr>
inoremap <C-s>     <Esc>:up<Cr>
nnoremap <A-Down>  <Esc>:cnext<Cr>
nnoremap <A-Up>    <Esc>:cprevious<Cr>

rg.exe is part of ripgrep.

Disabling Bluetooth auto-suspend with module options

In my previous post I showed how to restart Bluetooth on Debian Linux. Here I explain how to disable Bluetooth auto-suspend with a kernel module option.

The behaviour of kernel modules can be controlled with parameters. The command modinfo shows information about a module and lists its parameters. In the example below, modinfo btusb shows the parameters for the Bluetooth module.

# modinfo btusb
...
parm:           disable_scofix:Disable fixup of wrong SCO buffer size (bool)
parm:           force_scofix:Force fixup of wrong SCO buffers size (bool)
parm:           enable_autosuspend:Enable USB autosuspend by default (bool)
parm:           reset:Send HCI reset command on initialization (bool)

To control Bluetooth auto-suspend, we must use the parameter enable_autosuspend. It can be set in a configuration file in directory /etc/modprobe.d/. 

options btusb enable_autosuspend=0

Here I have added the kernel option to disable Bluetooth auto-suspend in file btusb_autosuspend-disable.conf.

Restarting Bluetooth on Debian Linux

On my laptop I use a Bluetooth keyboard and a Bluetooth mouse. Occasionally the Bluetooth adapter in the laptop shuts off completely, meaning that it becomes impossible to restart the Bluetooth service with sudo systemctl restart bluetooth.service.

My troubleshooting points to powersaving as the cause of this intermittent failure, but the TLP setting that is supposed to prevent autosuspend on Bluetooth devices does not seem to prevent it. As a temporary workaround I am using the commands below to restart Bluetooth from the shell.

$ sudo rmmod btusb && sudo modprobe btusb && sudo systemctl restart bluetooth.service

This solution works on Debian testing bullseye with kernel x86_64 Linux 5.5.0-2-amd64.

Centrino Ultimate N-6300 slow to connect to WiFi network

WiFi connections from my laptop became unstable after I upgraded it to Ubuntu 19.04. To get them to work, I had to turn the WiFi adapter on and off several times, which quickly became annoying.

The following attempts to fix the problem were unsuccessful:

  • disabling IPv6
  • disabling power-saving on the WiFi adapter
  • setting bt_coex_active=0 during kernel loading to disable Bluetooth/WiFi interference protection

Eventually the correct solution was to disable 802.11n with the following procedure:

  1. Edit or create a configuration file under /etc/modprobe.d (e.g. iwlwifi_custom.conf).
  2. Add this line and save the file.
    options iwlwifi 11n_disable=1
  3. Reload the iwlwifi module.
    sudo rmmod iwldvm
    sudo rmmod iwlwifi
    sudo modprobe iwlwifi
  4. Connect to the WiFi network.

SO #57225262—Inputting list of passwords in a class

Stack Overflow question ‘Inputting list of passwords in a class’ is more interesting as an object-oriented design (OOD) exercise than as a debugging exercise, but it also provides an opportunity to practise some Python programming.

The requirements identified in the problem are:

  • represent a set of credentials comprised of a username and a password;
  • represent a user account made up of an identifier and one active set of credentials and zero or more inactive credentials;
  • store user accounts that can be retrieved subsequently by username;
  • validate a given set of credentials, using the stored user accounts.

Additionally, a user account has the following constraints:

  • It must be uniquely identifiable by the username of the active set of credentials.
  • A set of credentials must be used only once for a given user account.

The design model consists of multiple classes, each addressing a single responsibility as follows.

ClassResponsibility
Credentialsrepresent a set of credentials
UserAccountrepresent a user account
AccountStorestore user accounts, enforcing the uniqueness constraint
Authenticationvalidate supplied credentials

The program code implements the model very faithfully and uses the same class names, thus making it easy to reason about. It has been tested with Python 2.7.15rc1 and has been checked for PEP8 compliance.

NOTES

For brevity, the solution presented here does not:

  • implement best practices used for security in real-world scenarios, such as salting and hashing;
  • enforce uniqueness of user account identifiers;
  • consider performance factors.

In lieu of conventional unit tests, a main routine exercises use-cases to ensure that the program works properly.

class Credentials:

    def __init__(self, username, password):
        self.username = username
        self.password = password

    def has_username(self, username):
        return self.username == username

    def matches(self, credentials):
        return self.username == credentials.username and \
            self.password == credentials.password

class UserAccount:

    def __init__(self, user_id):
        self.user_id = user_id
        self.active_credentials = None
        self.past_credentials = []

    def add(self, credentials):
        self._check_uniqueness(credentials)
        if self.active_credentials is None:
            self.active_credentials = credentials
        else:
            self.past_credentials.append(self.active_credentials)
            self.active_credentials = credentials

    def has_username(self, username):
        return self.active_credentials.has_username(username)

    def has_same_username(self, user_account):
        return self.has_username(user_account.active_credentials.username)

    def has_credentials(self, credentials):
        return self.active_credentials is not None and \
            self.active_credentials.matches(credentials)

    def _check_uniqueness(self, credentials):
        if self.has_credentials(credentials):
            raise Exception('These credentials are currently in use.')
        for c in self.past_credentials:
            if c.matches(credentials):
                raise Exception(
                        'These credentials have been used in the past.')

class AccountStore:

    def __init__(self):
        self.user_accounts = []

    def add(self, user_account):
        self._check_uniqueness(user_account)
        self.user_accounts.append(user_account)

    def find_by_username(self, username):
        for ua in self.user_accounts:
            if ua.has_username(username):
                return ua
        return None

    def _check_uniqueness(self, user_account):
        for ua in self.user_accounts:
            if ua.has_same_username(user_account):
                raise Exception(
                        'An account with the same username is already active.')

class Authentication:

    def __init__(self, account_store):
        self.account_store = account_store

    def validate(self, credentials):
        user_account = self.account_store.find_by_username(
                credentials.username)
        if user_account is None:
            return False
        return user_account.has_credentials(credentials)

if __name__ == '__main__':
    credentials = Credentials('user1', 'password1')
    user_account = UserAccount(101)
    user_account.add(credentials)

    account_store = AccountStore()
    account_store.add(user_account)

    user_account1 = account_store.find_by_username('user1')
    print 'user_account1', user_account1

    user_account2 = account_store.find_by_username('user2')
    print 'user_account2', user_account2

    authentication = Authentication(account_store)
    print 'Expecting True...', authentication.validate(
            Credentials('user1', 'password1'))
    print 'Expecting False...', authentication.validate(
            Credentials('user2', 'password1'))
    print 'Expecting False...', authentication.validate(
            Credentials('user1', 'password2'))

    user_account.add(Credentials('user1', 'password2'))
    print 'Expecting True...', authentication.validate(
            Credentials('user1', 'password2'))
    print 'Expecting False...', authentication.validate(
            Credentials('user1', 'password1'))

    try:
        user_account.add(Credentials('user1', 'password1'))
    except Exception:
        print 'Expecting exception... Pass'

    try:
        user_account.add(Credentials('user2', 'password1'))
        print 'Not expecting exception... Pass'
        print 'Expecting True...', authentication.validate(
                Credentials('user2', 'password1'))
    except Exception:
        print 'Not expecting exception... Fail'

    try:
        user_account1 = UserAccount(102)
        user_account1.add(Credentials('user1', 'whatever'))
        account_store.add(user_account1)
        print 'Expecting True...', authentication.validate(
                Credentials('user1', 'whatever'))
    except Exception:
        print 'Not expecting exception... Fail'

    try:
        user_account2 = UserAccount(103)
        user_account2.add(Credentials('user1', 'whatever'))
        account_store.add(user_account1)
        print 'Expecting exception... Fail'
    except Exception:
        print 'Expecting exception... Pass'


The output of the program is:

EY@LENNY:~/Source/junk/python/pwman$ python all.py
user_account1 <__main__.UserAccount instance at 0x7faa36f11170>
user_account2 None
Expecting True... True
Expecting False... False
Expecting False... False
Expecting True... True
Expecting False... False
Expecting exception... Pass
Not expecting exception... Pass
Expecting True... True
Expecting True... True
Expecting exception... Pass
EY@LENNY:~/Source/junk/python/pwman$

Undefined behaviours in C

Undefined behaviours in the C language confuse many beginners. As an occasional C programmer I am also baffled when I encounter them—as happened with this code that I wrote in an Arduino sketch.

static void
get_input(String prompt, void* const input, void (*parse_func)(void* const), int (*validate_func)(const void* const))
{
  while (!validate_func((const void* const)input)) {
    Serial.println(prompt);
    while (Serial.available() == 0);
    parse_func(input);
  }
}

void
loop()
{
  get_input("Enter the number of blinks: ",
        &(led->blinks),
        *parse_int,
        *validate_positive_int);
}

get_input() is a generic function. It takes a parameter String prompt and two function pointer parameters (*parse_func)(void* const) and (*validate_func)(const void* const). These generic function pointers take parameters of type void, which can be cast to any other type.

At runtime I passed the function validate_positive_int() as argument for parameter (*validate_func)(const void* const). It converts its argument to an integer value and tests if the result is greater than zero.

static int
validate_positive_int(const void* const val)
{
  return *(const int* const)val > 0;
}

As I was debugging the sketch, I modified the function as follows

static int
validate_positive_int(const void* const val)
{
  *(int*)val = 1234; // <--- modification 
  return *(const int* const)val > 0;
}

Although I assigned a new value to the parameter of type const void* const – that is, a constant – the code compiled successfully, and the program executed without any error.

But when I tried to change the value of the parameter by casting it to the same type as declared for the parameter, the compiler reported an error—as it should.

static int
validate_positive_int(const void* const val)
{
  *(const int* const)val = 1234; // <--- modification 
  return *(const int* const)val > 0;
}
test.c: In function ‘validate_positive_int’:
test.c:15:28: error: assignment of read-only location ‘*(const int *)val’
     *(const int* const)val = 1234;

This was puzzling because I expected the code to not compile in both cases.

Going through the C documentation, I found that an undefined behaviour arises when a const object (that is, const void* const) is modified through a non-const pointer (that is, int*).

Even if I was reluctant to accept this explanation because of my familiarity with safer language compilers that enforce parameter declarations strictly – in a case similar to the above, that the value of a const parameter is immutable – I eventually had to accept that C is different in how a parameter declaration is not enough to cause a compilation error when an argument is treated contradictorily to the declaration.

When a programmer declares a parameter for a function, they ask future users of that function to call it with arguments of the declared type. However, they do not guarantee that their function will not treat the argument however they want. In the example above, although the function tells the caller that it must be passed a const, it can still modify the argument.

Programming Arduino in Atmel Studio

As a fun way to improve my C, I started programming the Arduino using Atmel Studio instead of the friendlier Arduino IDE.

Below is my very first program. It blinks a red LED and a white LED according to a preset pattern.

#define F_CPU 16000000UL

#include <avr/io.h>
#include <util/delay.h>

struct Led
{
    int pin;
    int blinks;
    int on_duration;
    int off_duration;
};

void delay_ms(int ms)
{
    while (ms-- > 0) {
        _delay_ms(1);
    }
}

void blink(const struct Led* const led)
{
    for (int i = 0; i < led->blinks; i++) {
        PORTB |= led->pin;
        delay_ms(led->on_duration);
        PORTB &= ~led->pin;
        delay_ms(led->off_duration);
    }
}

int main(void)
{
    const struct Led white_led = { 1<<PB6, 10, 100, 500 };
    const struct Led red_led = { 1<<PB7, 10, 500, 1000 };

    DDRB |= white_led.pin;
    DDRB |= red_led.pin;
    while (1) {
        blink(&white_led);
        blink(&red_led);
    }
}

With C in Atmel Studio and the AVR-LIBC library, IO ports are manipulated by changing bit patterns in the registers associated with the relevant ports. This requires a good understanding of bitwise operations in C despite the availability of macros to simplify the task.

For example, to set pin 12 of the Arduino to output mode, bit 6 of register DDRB must be set to 1. To do so requires an | (OR) operation with a bit pattern operand where bit 6 is set to 1 and the rest set to 0, so that the states of the other bits in the register are not disturbed.

Using macros DDRB and PB6 defined in AVR-LIBC, this is done like this: DDRB |= 1 << PB6 .

If you are new to C and are unfamiliar with macros, you might wonder about that statement. Besides, DDRB and PB6 are not referenced anywhere else in my program, so how does this line of code work?

DDRB is a macro that expands into C code to dereference the address of the register associated with setting the mode for pin 12, and PB6 is just a symbolic constant for the value 6. In the statement above, by shifting the value 1 left by 6 positions, we create a new value which is then applied to the bit pattern stored at the dereferenced address with an | operation to turn bit 6 of the register to 1. In this case, this sets pin 12 to output mode.

In a nutshell, the sequence of operations is as follows.

Step 1:

1 << 6 = 01000000

Step 2:

Assuming the register DDRB is initially 00000001:

00000001 | 01000000 = 01000001

In my C program, the result of step 1 is assigned to struct field Led.pin and is used as the second operand for the operation in step 2.

It took about an hour to refresh my knowledge of bitwise operations, but the real challenge was interpreting the Arduino schema and the information in datasheets, especially to find the right registers to manipulate.

Hacking SSL support into smtpop.dll

We use smtpop.dll in one application to retrieve email from a POP3 mailbox. Today we had to connect to a mailbox over SSL, which smtpop.dll does not support.

Our code to retrieve email is abstracted behind a façade class, so I expected to simply substitute a new library for smtpop.dll and to call new methods. However, the tight coupling of the façade to the interface of smtpop.dll meant that we needed the replacement to also expose the exact same interface.

After trying several things, I resigned to create a new class with the code from the decompilation of smtpop.dll. Fortunately, only two methods, Open and Quit, had to be changed.

namespace ClassLibrary4
{
    using System.IO;
    using System.Net.Security;
    using System.Net.Sockets;

    using SmtPop;

    public class Pop3ClientWithSsl : POP3Client
    {
        #region Fields

        private SslStream sslStream;

        #endregion

        #region Constructors and Destructors

        public Pop3ClientWithSsl()
        {
            this.UseSsl = true;
        }

        #endregion

        #region Public Properties

        public bool UseSsl { get; set; }

        #endregion

        #region Public Methods and Operators

        public new int Open(string hostname, int port, string username, string password)
        {
            if (this.UseSsl)
            {
                return this.OpenWithSsl(hostname, port, username, password);
            }

            return base.Open(hostname, port, username, password);
        }

        public new string Quit()
        {
            try
            {
                return base.Quit();
            }
            finally
            {
                this.m_streamReader.Close();
                this.m_streamWriter.Close();
                if (this.UseSsl)
                {
                    this.sslStream.Close();
                }
            }
        }

        #endregion

        #region Methods

        private int OpenWithSsl(string hostname, int port, string username, string password)
        {
            this.m_host = hostname;
            this.m_port = port;
            this.m_user = username;
            this.m_tcpClient = new TcpClient(hostname, port);

            this.m_netStream = this.m_tcpClient.GetStream();
            this.sslStream = new SslStream(this.m_netStream, false);
            this.sslStream.AuthenticateAsClient(hostname);

            this.m_streamReader = new StreamReader(this.sslStream);
            this.m_streamWriter = new StreamWriter(this.sslStream) { AutoFlush = true };

            string welcome = this.m_streamReader.ReadLine();
            if (welcome != null && welcome.StartsWith(+OK))
            {
                return this.SendLogin(username, password);
            }

            this.m_error = welcome;
            return -1;
        }

        #endregion
    }
}

The methods of class POP3Client were not virtual, but some of the class members were in protected scope and were accessible in the new class. I rewrote the Open and Quit methods as new methods, which made them no longer polymorphic, thus forcing us to replace calls to POP3Client with calls to Pop3ClientWithSsl everywhere in the code.

Java Server Faces rage!

From http://thoughtworks.fileburst.com/assets/technology-radar-jan-2014-en.pdf:

We continue to see teams run into trouble using JSF– JavaServer Faces — and are recommending you avoid this technology.

Teams seem to choose JSF because it is a J2EE standard without really evaluating whether the programming model suits them. We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP, exactly the reverse of what modern web frameworks do. JSF, like ASP.NET webforms, attempts to create statefulness on top of the stateless protocol HTTP and ends up causing a whole host of problems involving shared server-side state. We are aware of the improvements in JSF 2.0, but think the model is fundamentally broken.
We recommend teams use simple frameworks and embrace and understand web technologies including HTTP, HTML and CSS.

This quote describes exactly how I feel about Java Server Faces.

From my old posts, you can see that I have been a strong supporter of JSF. I continued to believe in its potential even when it was new and lacked features.

JSF 2.0 was supposed to address developers’ complaints about the shortcomings of earlier versions, such as lack of support for bookmarkable URLs and the absence of view parameters. But it has many of its own flaws, and various implementations still do not follow the underlying JavaEE standards. The slow progress and the persistent incompatibility make developing with JSF rather frustrating.