Category: Interesting problems

Bracketed-paste or why does my mutt-in-screen-IMAP-login not work anymore?

After I upgraded my IRC-host to the next Debian release, I rebooted the box, restarted the IRC and mail client to get things back up again, and wanted to log into my mailbox again. I pasted the password from the password store into mutt (running inside screen) as I had always done and got login failed. Wat?

The IMAP login still worked fine via Thunderbird or mobile app from other devices, and dovecot wasn’t logging anything related to the failed login attempts from mutt. Wat?!

When I start mutt directly on that very box, so outside screen, login works just fine, too. WAT?

So, enable some verbose auth logging in dovecot, including incorrect passwords in plain text, to see what’s going on here:

# From /etc/dovecot/dovecot.conf

# Verbose logging for authentication things
auth_verbose = yes

# Log passwords from invalid logins in plaintext, use carefully!
auth_verbose_passwords = plain

With that in place, I could see, that the password pasted into mutt‘s password prompt, when running inside screen, resulted in the password being prepended by 200~ and having a trailing 201~, WAT?!

Noting my findings in the DENOG IRC channel, someone pointed me to Bracketed-paste, which explained the control characters I was seeing. Without that pointer in the right direction, I would have search way longer – I love the DENOG and Open Source communities 💜.

  • ESC [ 200 ~ to signify the beginning of pasted text and
  • ESC [ 201 ~ to signify the end.
Description of bracketed-paste (Wikipedia)

That lead to the discovery that you can disable this behavior in multiple ways, including adding the following line into ~/.inputrc:

set enable-bracketed-paste 0

And hence, I can paste happily ever after.

Beware of the details (and VLANs)

A friend today challenged me with this problem on an Ubuntu box:

auto eth2
iface eth2 inet static
    address 10.23.0.32
    netmask 31

auto eth2.210
iface eth2.210 inet static
    address 10.42.0.32
    netmask 31

root@box:~# ifup eth2.210
Cannot find device "eth2.210"
Failed to bring up eth2.210.

The first thing coming to mind is “package vlan missing?”, which it was. After installing it, it got more interesting:

root@box:~# ifup eth2.210
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
ifup: recursion detected for interface eth2 in parent-lock phase
ERROR: trying to add VLAN #210 to IF -:eth2:-  error: File exists
Cannot find device "eth2.210"
Failed to bring up eth2.210

A little poking around showed, that there’s no interface eth2.210 present in the system, but

root@box:~# cat /proc/net/vlan/config 
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
rename10       | 210  | eth2

root@box:~# ip l
[...]
10: rename10@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether DE:AD:BE:EF:23:42 brd ff:ff:ff:ff:ff:ff
[...]

Deleting the renameNN interface an running ifup again, just created a renameNN+1 interface with kernel log entries like

[7366672.699018] rename14: renamed from eth2.210

I suspected some bugs in /etc/network/if-{,pre-}up.d/ but this even happend, when manually running

ip link add link eth2 name eth2.210 type vlan id 210

or

ip link add link eth2 name vlan210 type vlan id 210

Dafuq?

Continue reading Beware of the details (and VLANs)