Tag Archives: Linux

RFID Exploration

I recently picked up a USB RFID reader/writer pod to play with, partly to learn enough to be dangerous about the tech, and partly hoping to tamper with the RFIDs in the current university ID cards. I’m pretty sure I failed on the latter point, but am succeeding at the former in the process.


Notes from the first round of fiddling with it follow.

Continue reading

Posted in Computers, DIY, Electronics, General, Objects | Tagged , | 18 Comments

Rescuing Ancient FreeBSD Discs with Linux

The ancient FreeBSD/i386 box that was running cgi.aggregate.org finally keeled over. I just blew my afternoon/evening scraping the data off of it because while the most critical stuff was backed up, not everything was. Some keyword and error string filled notes that will hopefully save others swearing and googling:
Continue reading

Posted in Computers, General, School | Tagged , | Leave a comment

Command Line Bullshittery?

I started responding to Philip Guo’s Helping my students overcome command-line bullshittery that passed through my news feeds today, and my thought quickly outgrew the appropriate size for social media, so it’s going up here.

I understand and often share his frustration, but only selectively agree with his conclusion, and would like to clarify the distinction because I think it is very valuable to understand it.

It is often annoyingly difficult to leverage existing tools, especially the various development toolchains whose install process involves blood sacrifice or perfect replication of the (naturally, undocumented) platform they were developed on, but I object to dismissing all such difficulty as bullshit.

Continue reading

Posted in Computers, General, School | Tagged , | Leave a comment

Inspiron 11-3000 Notes


The KAOS lab recently bought a fleet of five Inspiron 11 3000 3138[PDF Warning] (Celeron N2815/4GB/500GB)laptops. They’re tiny little machines with 8 hour claimed battery lives, they’re pretty cute and sort of obstinate.

I borrowed one to play with, notes:
Continue reading

Posted in Computers, General, Objects | Tagged , , , | 3 Comments

WNR3500L Repair

Some years ago the KAOS lab bought a number of Netgear WNR3500L routers to use as network glue. A pair of them have been in constant service since 2011 in the lab and machine room, and both of those died in the last two weeks. I’ve finally satisfactorily tracked down the culprit, and figure it’s worth a quick write up.

The WNR3500L is a bit of a false-promise machine; it was sold as an “open router” with excellent community firmware support, but it has some pretty extensive blobs that mean it really only runs versions of DD or Tomato with a small range of 2.6 kernels.

I initially just swapped the first one to die out for a spare (which happened to be flashed with Tomato instead of DD, it was an experiment when they were first set up), and reloaded most of the settings by hand (we failed to save or document many of the settings elsewhere. Our fault.) until I had time to investigate. When the second one died, it became urgent.


Conveniently, the WNR3500L has a 3.3V RS-232-like serial port (115200/8/n/1) under an easily removed panel, retained by one small torx screw/pin thing (Both are out in the picture while I was figuring out which side was which).


This leads to another victory for the Bus Pirate. Any 3.3V compatible UART adapter would work, but the bus pirate has much nicer cables for this sort of thing. In retrospect, those headers are correctly sized to just plug the female harness ends directly, but I used clips out of habit.

It turns out they were booting right up with only warnings, but the configuration was sufficiently garbled that neither the WLAN nor the Ethernet ports were coming up. I blew the first one’s settings away (note: at least on the old version these were running, reboot TWICE after clearing the NVRAM to get back to a consistent state: the first time it writes default values, the second time it boots cleanly). With the software-only nature of the problem established, I took more time to investigate the second one, at which point…

nvram show
[1310 lines excluded]
size: 32782 bytes (-14 left)

Well, There’s Your Problem.

Turns out the tiny little log fields for monthly traffic statistics filled up the nvram and were causing configuration corruption, and thus failures.

There are some forum threads and bug reports on the matter, and it was fixed about two years ago with a test to prevent writing past the end of the file, a default setting to automatically delete traff logs after 12 months, and various other enhancements. Now that we’re up and running again it isn’t desperate, but it looks like there is a DD release from mid-2013 with the fixes applied that still supports these things, and they are probably due to be re-flashed to keep this from happening again.


  • My home OpenWRT on a TP-Link 1043ND uses a connected USB key for logging and such. This is a much better behavior (like most things in OpenWRT: DD-WRT appears to be kind of an unmaintainble mess).
  • Keep an eye on appliances like routers, they’re still just computers.
  • Back up your damn configurations, or at least retain copies of the information required to regenerate them. Regenerating settings, especially when it involves manual tasks like MAC address hunting, sucks.

Other notes:

  • These things’ bootloaders appear to always look at through the non-WAN ports for a tftp payload named vmlinuz. There may be a way to disable that, but I think I’d prefer to leave it on, since it only enables local attacks and provides a rescue mechanism.
  • The WNR3500L has a documented weakness about WAN-LAN throughput with various firmwares. Our uplink is actually good enough for it to matter, so perhaps one of the newer versions will improve that.
Posted in Computers, DIY, Electronics, General, Objects, School | Tagged , , , | Leave a comment

Debian init Decision

The Debian ctte init discussion, which has been the drama that keeps on giving, appears to have finally had a decisive vote for systemd [EDIT: I was over-ambitious about decisive. The drama continues.] as the jessie init. Some notes:

  1. I found out that the FLOS neologism that is my fault is being used in the discussion. I’m not sure that I’m entirely happy about that, but I do think that we should be self-aware about building something very different from the Unix tradition.
  2. Even with my well-documented distaste for some of the philosophy (and rider components) in systemd, my experience and taste is that Upstart is the worst possible choice, and nothing else seems to have a chance. Letting the Canonical folks continue to act like Upstart isn’t universally technologically and philosophically unsatisfying to is wasting everyone’s time.
  3. The FDO agenda has largely succeeded, a bunch of the upper layers of the ecosystem are developing dependencies on systemd-coupled interfaces. This is largely because the previous interfaces being used for much of that functionality were the same developers’ now-abandoned earlier projects, which turned out to be disasters. This would be fine if there were even signs of competing implementations of those interfaces, or if the design of those interfaces weren’t such that it would be almost meaningless to attempt one, because the parts were designed as part of an integrated stack. I don’t see, for example, a clean standalone logind implementation (since it assumes things that only sysmted does further down the stack) or a nice healthy syslog-ng/rsyslog arrangement for journald. The FDO folks made an end-run around any kind of discussion of the merits of their plans by implementing quickly, getting a few of them widely adopted (initially by sheer political blustering), then coupling the rest of their design to the parts others were on board with. I’m pretty sure they consider that some kind of virtue.
  4. Related to (3) the integrated service manager over rcconf system discussion seems to have been decided on Linux up and down the ecosystem. I may not like the decision, but we should probably make the best of it and start working on/around the most annoying things about systemd. They seem willing to accommodate at least on cosmetic things like ISO dates.
  5. With that in mind, my preference would have been “We will adopt systemd iff a series of ecosystem assurances/development projects happen,” but that is unrealistic and (AFIK) forbidden by the Debian process. Especially a move from putting dist configs in half a dozen cryptic paths in /usr (which offend me in a variety of ways) to, giving credit to the merits of the “/usr belongs to the package manager” retcon, /usr/etc the way some of the BSDs use /etc/defaults.
    While we’re dreaming, forcing an interface/adapter to use a syslog in place of journald, or at least an alternative journald implementation with a simpler back-end (graceful feature degradation acceptable) would be great. I’m not even necessarily advocating using it, just that I don’t tend to take software without competing implementations as credible. Perhaps pressure from the volume of the Debian community will make some of this happen.

  6. I will agree with their vote in the “Fuck it, go with systemd, get the uniformity and feature advantages, try to mitigate the misfeatures, and leave as much room for coming back to the decision later if someone succeeds in writing and agitating for something more satisfying” sense.

Even with all that said, I’m a little surprised OpenRC wasn’t taken more seriously, since it is the conservative incremental progress choice – objectively, it is currently more featured than Upstart by most metrics – but the developers haven’t been politicking the way the Upstart and systemd folks have, and their incidentally combined efforts managed to discredit it. It has better portability (already runs on Hurd and FreeBSD) than the other options, and is one of two with a (admittedly, less featured) cgroups mechanism. The latter one is interesting because via some impressive politicking the cgroups discussion was at some point re-framed from “makes use of cgroups” to “uses cgroups in exactly the same way as systemd.”

I’m curious how the procd/ubus/hotplug2 stack coming out of OpenWRT is going to interact with the rest of the ecosystem, I suspect we’re going to see that stack meet midway with systed/dbus/udev and some of the light distros using it and shims even for PC-like applications, which will likely be the next time things get really interesting, barring a couple skirmishes where user-level software dictates the stack to the metal.

Posted in Computers, General | Tagged , , | Leave a comment

chdk-ptp PKGBUILD

In another episode of fixing things for the Cameras as Computing Systems class I’m taking, I made a PKGBUILD that apparently correctly builds and installs chdk-ptp on Archlinux systems. Chdk-ptp is a tethered-control application for Canon cameras running CHDK, that hooks a variety of custom extensions to the ptp protocol. Their build system is a little lackluster, is missing things like an install rule, and requires a helper script be installed to do some path munging before running the binary, but the documentation is good enough to sort it out, and the program itself seems to work. My package depends on iup-all-bin from the AUR which also provides the cd dependency (not marked in its provides array, though there isn’t an official package to conflict with). I tried to use the built-from-source AUR packages for cd (Seriously, who thought that was a good name for a piece of software?) and iup, but iup was giving me a hassle and the chdk-ptp documentation suggests the binary distribution will be less trouble anyway.

The PKGBUILD format has changed a bit since I was last making my own- I like most of the changes in terms of clarity and modularity, but it does require a bit of re-learning. It also means I have a couple of pet packages that probably need attention.

The build is a little janky so despite it passing through namcap with only one expected warning, I don’t want to put it in the AUR until I’ve tested it enough to be reasonably sure it works as intended. I expect I will get around to that eventually.

Posted in Computers, DIY, Electronics, General, Objects, School | Tagged , , , , , , | Leave a comment

Udisks2 Misfeature Fix

Apparently David Zeuthen committed a patch back in February (appears in udisks2 >= 2.0.91, afik) that lets you single-point (or selectively) switch Udisks2 back to the nice, sane, predictable “Removable drives mount to /media” behavior instead of the asinine “Drives are owned by some user who happens to be logged in at a local session at the time they are plugged, mounted to /run/media/$USER/$LABEL, and ACL’d to that user” nonsense that has been a near-constant source of inconvenience lately. I’m surprised it took me this long to find it.

Following these instructions, all you have to do is create a Udev rule (ie. /etc/udev/rules.d/99-correct-media-mount-point.rules) with the line ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="1", and storage mounts to /media/$LABEL (You may want to leave out crypto, it actually makes sense for encrypted volumes to be obscured from other users like that) with no funky ACLs by default.

No more tedious user,noauto,nofail fstab entries on all my machines, for all my frequently-used discs to prevent that behavior! Hurrah!

Posted in Computers, DIY, General | Tagged , | 3 Comments

I got into another discussion about Linux init systems. Since I still get a lot of hits about that, I figure I should put a link, as the long two-part post is a reasonably clean and complete explanation of my position.

It always makes a fun topic because it is both interestingly abstract and forces me to carefully evaluate and create specific reference cases for my preferences and positions.

Posted on by pappp | Leave a comment

I want my UNIX groups back

The breakage of permissions under recent PolKit/logind is flabbergasting. They have completely subverted UNIX groups/permissions in a difficult-to-unbreak way. And I get cheerful little update messages saying things like “You no longer need to be in the camera group to use cameras” like it’s a fucking feature (and they’re lying; they mean users logged in locally no longer need to be in the camera group – remote users still need it). If I want a user to have access to some hardware on a machine, I’ll give it permissions. If I don’t, I probably don’t for a reason. Let’s talk use cases: perhaps you would like to hide the camera from a kid’s user. Or you would like to check on something with the camera attached to your remote machine. Or work a music player via SSH. Or generally use the resources on the machine you bothered to log into remotely because why the fuck else would you have logged in there? Every one of those is now more complicated to accomplish. Adding a facility to enable/disable permissions for remote or local users might be reasonable, but just fucking breaking groups for a couple use cases no one uses is moronic. (Seriously, Fast User Switching keeps coming up as a rationale for breaking things. Has anyone, ever used fast user switching on one of the platforms that supports it? There are usually more computer-like-devices than people in a household now, it isn’t relevant.)

Can someone please come up with a straightforward way to just noop all the PolKit bullshit so I can have my UNIX box back from the FreeDesktop assholes?

Posted in Computers, General | Tagged , , , | 10 Comments