diary at Telent Netowrks

Nix wrought#

Tue, 03 Sep 2019 22:00:29 +0000

Time from unboxing new GL.iNet GL-MT300N-V2 to an ssh-able NixWRT installation: 30 minutes. Though admittedly this does not include the actual firmware build time itself as I did that bit yesterday when I ordered the box.

I lost the CPU for my backup server somewhere when we moved - I still have the disk, just not the bit that makes it go. Probably it's in a box I haven't unpacked yet, but anyway. Having generated much new "content" over the past few days - I've now scanned something over 500 pieces of paper into my paperless archive - it becomes somewhat more pressing to get the automated backup service running again.

  1. make the image
  2. find some scissors, open the box
  3. plug the device LAN port into my laptop and configure it to use a different RFC1918 address than the one it came with (which conflicts with the LAN here)
  4. upload the firmware.bin using the gl.inet web router admin page
  5. wait
  6. why is it not showing up on the LAN?
  7. wait
  8. ah yes, because it's still plugged into my laptop. Try plugging it into a LAN switch instead
  9. odds bodikins, I can ssh into it!

So, 30 minutes, would have been quicker if I weren't an idiot at step 6. To say I am mildly stoked this went so smoothly would be an understatement.

There are a couple of niggles: I need to rebuild the image because I forgot to update the name of the syslog host and I think I have probably also forgotten to put a real password on the rsync service. But both those are (or should be) simple fices.

Cracking over the papers#

Fri, 30 Aug 2019 11:19:35 +0000

One of the several billion things that needs sorting in our new house is a filing system for all the paper junk we get sent that we don't immediately need to deal with but probably shouldn't throw away: bills, PAYE coding notices, letters from the council, bank statements etc. After some thought and thanks to @antifuchs alerting me to the existence of the Paperless project I decided to go digital. Recommend.

Notes, in the order they occur to me

    services.paperless = {
      enable = true;
      extraConfig = {
        PAPERLESS_CORS_ALLOWED_HOSTS="http://localhost:8080";
      };
    };


sudo -u scanner scanimage --format png --batch=/var/spool/scans/$(date +%Y%m%d%H%M%S)Z_p%04d.png  --resolution 300 --source 'ADF Duplex'

where scanner is the username that paperless is running as and /var/spool/scans/ is where I arbitrarily decided the consumption directory should be. I scan to png not pdf because scanimage was silently failing to convert to pdf and instead leaving the files as pbm images. (1) pbm images are huge; (2) pbm images files with .pdf suffixes confuse the paperless web frontend and they confuse me too. I would like to automate this so it runs whenever I (or a family member) presses the "scan" button on the scanner itself, but haven't got that far yet. scanbd will probably do it but seems excessively featureful for my needs.

[dan@loaclhost:~]$ systemctl cat paperless-consumer.service| grep 'ExecStart='
ExecStart=/nix/store/2jaqzp6yhqwb2p0vs93whkwj0r0jf509-paperless document_consumer
[dan@loaclhost:~]$ sudo -u scanner /nix/store/2jaqzp6yhqwb2p0vs93whkwj0r0jf509-paperless document_correspondents

Switched out#

Wed, 26 Jun 2019 20:55:18 +0000

I have spent an inordinate amount of time lately to get a working NixWRT wireless extender running on my MT300A. The symptom is that whenever I reboot it, about 30-60 seconds later it will lock up every device on the switch it is plugged into for a minute - and as this presently includes my build system, which also serves as my NAS, the problem is a high-priority one.

I've had all kinds of hypotheses, many of which involved bridging loops somewhere on the LAN, but no amount of staring at network diagrams, poring over wireshark captures or or fiddling with STP seemed to have any effect. Until last night when I tried to do a TFTP boot forgetting that I'd unplugged it from the TFTP server, and that resulted in exactly the same problem without even starting the Linux kernel.

So, I guess we can eliminate NixWRT from our enquiries. Whether the problem is hardware, or is something to do with how U-Boot initializes the hardware - or both, even - I am in some sense cheered to learn that it was probably nothing I did. At this point I'm going to flash the latest extensino.nix build to it, put the cover back on, and go and plug it in somewhere I have wireless dead spots, so that I can actually start working on the new router that arrived last week. And maybe not reboot it too often, but actually I'm hoping that once the image can be booted from flash, U-boot won't need to initialize the network device at all and there will be no problem.

Well, I might just add in support for STP first, it seems like a sensible thing to have.

Blogging on logging#

Fri, 14 Jun 2019 08:34:20 +0000

Before I put NixWRT on my primary internet connection, I want to deploy this wireless range extender, which means unplugging the serial connection. So, I really need to make it send syslog over the network.

"Just [* ] install syslogd", you say, "how hard can it be?". There's a syslogd applet in Busybox, all I need is something elsewhere on the LAN to receive the messages (hint: not Journald ). But, before I can send log messages over the network, I need the network to be available:

Which in sum is about 96% of everything it needs to do when it boots up, and whether that all goes to plan or not, any log messages it generates will be lost like tears in rain. Forgotten like a politician's manifesto commitments. Cast to the ground like a toddler's breakfast. I wanted something a bit more comprehensive, and didn't want to write the messages to flash because I'm not using any writable flash filesystem.

Avery Pennaruns blog article The log/event processing pipeline you can't have is not only a fun read about log processing at scale, but contains a really neat solution to this problem: instead of having klogd suck kernel messages and push them into syslogd which spits them out to files on disk, why not run the pump in reverse and push all the userland log messages into the kernel printk buffer? We have lots of RAM (I mean, by comparison with how much flash we can spare) and can squirrel all the boot time messages away until the network is up and ready to send them to the loghost.

Copying from /dev/log to /dev/kmsg is either simple or as complicated as you care to make it (the Google Fiber app has clearly encountered and addressed a whole bunch of real-world issues I haven't had to deal with).

Sending messages from the kernel printk buffer is slightly more complicated but only in the incidentals not in the essentials. We need to

1. read from /dev/kmsg and parse the strings we get. The format is documented and the only challenge here is that for reasons of keeping the system size down I felt obliged to write it in C, which is peculiarly suitable for text processing tasks. Emphasis here on "peculiar" not "suitable". Slightly annoyingly, the log entries don't include a timestamp field which can be related to time of day: instead they use a monotonic timestamp which is probably the number of seconds since boot but doesn't account for time while the system is suspended.

2. transform it into something J Random Syslog Server will recognise. There are two contenders here: RFC 5424 says how you're supposed to do it, with options for PROCID, MSGID and STRUCTURED-DATA which I probably don't need, and RFC 3164 says how everyone actually does it, which as you can imagine encompasses a wide variety of exciting brokenness (it's descriptive not prescriptive, and what it describes is little more constrained than "there might be a facility in angle brackets, there might be a timestamp, there's probably some other stuff). Initially I tried 3164 with ISO8601 timestamps instead of the weird legacy date format it recommends, but rsyslog declined to parse the rest of the line, so I switched to 5424. After making this decision I noticed that the author of rsyslog is also the author of RFC5242, so, uh, I guess there's that. I had to add my own timestamps here because see complaint about step 1, and I had to add in the hostname.

3. Send it to the internet. This bit at least is well-trodden ground.

There's only one other thing to say here, which is that the lines you write into /dev/kmsg are whatever you want to write. My klogcollect just writes more or less anything that turn up in /dev/log, without attempting to parse it, which means whatever format the C library syslog() function writes. So when forwarding the messages I have to check the message origin (kernel or userland) before deciding whether to format it for RFC5424 or whether to wing it as-is.

Summarising

After the monolog(ue), the epilog(ue)...

klogforward is on Github, and you can have this working in your NixWRT by adding

(syslog { loghost = "loghost.example.com" ; })

to your modules.

When I next come back to this I am going to play with the PRINTK_PERSIST patch that Avery talks about, and also I should have a proper look at logos - it probably solves problems I haven't seen yet. But more pressing right now is working out why I can't reboot my wireless extender without freezing every other device on the switch it's attached to for a minute. Wireshark says it's "MAC PAUSE" frames, and my working hypothesis is a switching loop.

Configuring Homeplug from Linux#

Thu, 23 May 2019 22:42:08 +0000

The new house doesn't have structured cabling, and I won't be doing anything to address that until we start work on the extension. In the meantime, therefore, we're using Homeplug AV (networking over the power line). I had two plugs, I needed a third so I bought the cheapest one I could find on Ebay.

When it turned up it had no buttons - which made it a little difficult to add to the existing network. Usually you press the "pair" button on the new plug and then on the existing plug and count to ten and wave a dead chicken around[*] and do a little dance, but that doesn't work when there is no button. Here's how to do it, assuming (1) it's an Intellon chipset, and (2) you have a Linux or other Unix-like box with an ethernet adaptor to plug it into.

1. You need faifa . To build it, you need libpcap and libevent: here's a quick and hacky Nix derivation .

2. Pick 8 random bytes to use for your encryption key. I did dd bs=8 count=1 if=/dev/random |od -x. This is a shared secret which you will need to install on all your adaptors, so probably you should save it somewhere until you're done. Note: the faifa source code seems to suggest that the key you provide is further hashed before being used, so maybe any amount of random stuff is OK here and there's no need to be precious about the format.

3. For each adaptor you want to configure, you will need its MAC address. Hopefully this is printed somewhere on the device itself: I don't know how to get it programmatically.

4. Plug the first adaptor into the mains and attach it to the machine where you built faifa. Now run it

$ sudo faifa -i enp0s31f6 -m

5. You should get a long list of "supported frames" which I will assume are about as meaningful to you as they were to me, followed by a prompt to choose one. If you were to choose, for example, a000 (which is "Get Device/SW Version Request), it might respond something like this:

Choose the frame type (Ctrl-C to exit): 0xa000
Frame: Get Device/SW Version Request (0xA000)
Dump:
Frame: Get Device/SW Version Confirm (A001), HomePlug-AV Version: 1.0
Status: Success
Device ID: INT6400, Version: INT6000-MAC-4-1-4102-00-3679-20090724-FINAL-C, upgradeable: 0

6. To set the encryption key, the frame type is 0xa050 (Set Encryption Key Request). It prompts you further for "local or remote" (I have no idea what this means, but "local" worked), for the key itself, and for the MAC address.

Choose the frame type (Ctrl-C to exit): 0xa050
Frame: Set Encryption Key Request (0xA050)
Local or distant setting ?
0: distant
1: local
1
AES NMK key ?0001020304050607
Destination MAC address ?b0:48:7a:b9:00:00
Dump:
Frame: Set Encryption Key Confirm (A051), HomePlug-AV Version: 1.0
Status: Success

7. Repeat for the next adapter, until you have done them all.

I make no claim that this is correct, but it seems to work for me, and now I can plug my new Odroid C2 (I'll write about that another time, but there's little to say so far, it just runs Kodi) into the TV without the use of a 5m HDMI cable.

[*] make sure it's dead. Waving a live chicken is stressful for all involved.