Anyone remember way back when the internet was simple? You could telnet to directly to certain TCP/IP ports and type your email or web requests in pure and natural ASCII text, and it would work. Well those days are gone, replaced by an endless rotation of crypto protocols that seem to rapidly degenerate into obsolescence or expiration. Or maybe time moves faster as you age? I don't know. Anyhow, I expect this post be be all about the dead crypto eating away at my aging computers (and zipits) and my attempts to get things working once again. The well known technical term for this rot is crypto necro nom-nom-nomicus in meme-latin.
We'll have to see where this eventually takes us. For now I'll start it off by re-posting a recent update to an old blog entry about the QEMU compiler setup for IZ2S, because dead crypto is what instigated my renewed efforts there.
After a few years of neglect I decided to put the qemu compiler to work
once again, and make myself a new IZ2S build of the dropbear embedded ssh suite. The old cyphers are
deprecated and the workaround command line args to ssh into the zipit
are painful. I could handle something like
-1, but -
oKexAlgorithms=+diffie-hellman-group1-sha1
is about 40 letters too many to commit to memory. So I resurrected the
qemu chroot and went to work compiling the latest dropbear. It took a
few tries to remember some of the tricky techniques required to produce
"optimal" executables for both the internal flash jffs and for the SD
card. For the jffs, small size is critical, so I built the
dropbearmulti target with minimal features and compressed it with the
lzma version of upx. An IZ2S SD card uses the FAT filesystem, so
individual apps work better than dropbearmulti, because softlinks are
not available on FAT.
I've uploaded a zip file to the usual place, with dropbearmulti for the jffs and the individual apps for the SD.
Meanwhile, I discovered some gaps in the tool set on the IZ2S qemu
image. The upx and sstrip programs were absent, and libcrypt.a was
unavailable. I believe libcrypt is actually in the qemu image with the
older v4.1 compiler, and simply needs to be copied from the older gcc
libs in /usr/local/share/gcc/lib to the usr/lib directory. But it's not
in the v4.4.7 compiler zip or the zips for for the IZ2S libs and
includes. So I think I need to put together a small "toolchain_extras"
zip file with the missing bits.
Also, since I can't seem to remember, I'll point out here that
CFLAGS="-march=armv5te -mtune=xscale" is nice for the zipit processor. And do
NOT
use soft-float on IZ2S. The stock kernel is OABI and the libs are
compiled with default float settings. Back in olden times that meant
hard float instructions with kernel emulation of the FPA via exceptions,
which is why floating point code is so dreadfully slow on IZ2S. If you
run readelf -h libgcc.a you'll see lots of zeros in the flags and ABI
bits, indicating the defaults were used. So if you get hard/soft float
mismatches from the linker (like I did when I accidentally grabbed the
soft-float libcrypt.a from openwrt) then you should compare readelf
header output of the mismatched files to see what's up.
Here's a readelf -h header sample from the IZ2S libgcc.a for reference:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 700 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 9
Section header string table index: 6
Another tip to remember... If you're making an SDL program for IZ2S, don't forget to
link with -pthread before -lSDL and -pthread again after. This prevents a nasty segfault in the startup code -- before it even gets into main().
Meanwhile, almost as soon as I made the new dropbear, I realized that i needed more. At the time I was using putty on Windows PC and for some reason putty requires an sftp-server on the linux side to transfer files, even if you use pscp. Dropbear lets you know that's not gonna work by mentioning it can't find /usr/libexec/sftp-server and then disconnecting. Fortunately bleeding edge openwrt has an
sftp-server package that works just fine for this. So I dug up the bleeding edge recipe that builds a minimal sftp-server executable from openssh and compiled it for IZ2S. To activate it you should install the
sftp-server executable in the libexec directory on the root of the IZ2S sd card, and then edit z2start.sh to make a softlink from /mnt/sd0/libexec to /usr/libexec, similar to the one for /usr/lib.
Unfortunately when I tried to install the sftp-server package on my bleeding edge openwrt zipit, I ran into trouble with
opkg. It no longer worked. Some investigation revealed that opkg was using wget to fetch the packages from mozzwald.com via http. Running the wget command by hand showed the http command got redirected to an https link which failed with an error about libustream-openssl gone missing. Turns out wget on openwrt is actually a softlink to uclient-fetch, and I needed to install the
libustream-openssl package if I wanted it to do https. So I fetched the package manually from mozzwald.com on my laptop, then transferred it to the zipit and installed it from there. At that point I could run
opkg update and see that it now functioned properly. So I used
opkg install to fetch and install the
sftp-server and
ca-certificates packages. Crypto death rot was put off for just a little while longer.
The rot isn't specific to the zipits. My eeepc 900A netbook has also got it bad. It's currently running an old puppy linux flavor (puppeee) specially tailored for the hardware. But it's about a decade old now and the crypto stuff is so outdated that nothing on the internet will even try to talk to the web browser. Git can't fetch code from github. Ssh is crippled. Everything that made this machine fun is now busted and I'd really like to bring it back from the dead. So the search is on for a more recent netbook sized linux that could meet my needs.
Goodby puppeee, you served me well back in the day.
Update Jan 5, 2019
I wound up taking the path of least resistance and installed a newer version of
puppy linux -- specifically the Ubuntu based 32-bit XenialPup 7.5. It went onto a usb stick with relative ease via this command.
sudo dd bs=4M if=xenialpup-7.5-uefi.iso of=/dev/sdb conv=fdatasync
Booting it was a bit more challenging. The eeepc boot screen mentions
F2 for setup and
Tab to see messages, but it's the
Esc key that actually gets you to the runtime boot media selector. I only just stumbled onto the
Esc key functionality with a happy accident when I tried
Tab and got bored watching the memory test count up.
The XenialPup looks pretty darn similar to puppeee, and I like that.
I booted xenial from the usb stick a few times to try it out and quickly decided it was familiar enough with ssh, picocom, and git all pre-installed, just like on puppeee. The only obvious issue was the wifi drivers. Running
lspci -v showed the kernel detected the atheros wifi, but no modules were loaded. Someone left out the atheros drivers from the xenial iso image. Oops. But this was already known and an
atheros_kernel_modules-4.4.95noPAE-xenial32.pet package was already created to patch the hole. So I borrowed the ethernet cable from the TV and fetched the package. I also tried the Pale Moon browser and found it sluggish, but it gets me onto github so I'm satisfied there.
Unfortunately double clicking on the atheros .pet package stubbornly refused to install anything, darn it! However I untarred it manually and had no problems copying the additional driver directories into the lib directory tree. Then I ran
depmod -a and
insmod ath5k and voila the "Connect" gui could now see the wifi.
This was good enough for me so I manually copied the files from the xenial USB stick to the eeepc flash drive for a homemade frugal install. I also added the
devx_xenialpup_7.5.sfs developer tools squashfs for gcc. Then I edited my existing grub menu.lst file to remove some obsolete browserlinux and pup431 options and added xenial instead, keeping puppeee as the default in the menu for now. At this point I ditched the USB stick, and booted into xenial from grub. It takes longer than puppeee, but what can you do, it's got some ubuntu stuff in there. The next step was to get me some emacs. So I ran the pet installer, did an ubuntu package update, and installed the ubuntu emacs package. I'm not sure I'm gonna keep that since it hogs a whopping 80MB whereas an emacs sfs is only about 40MB. I'm not sure if I can use the
emacs-24.5-i486.sfs from the puppy forums because it's not specifically for xenial. So perhaps it's time to howto roll my own sfs.
So far the noticeable differences boil down to a larger font in the urxvt terminal -- I probably need that at my age -- and I don't know if I can set the titles in the urxvt tabs. They don't respond to the old xterm ANSI control sequences, but hopefully I can figure something out. Anyhow, life is good once again with the eeepc netbook.
Update Jan 12, 2019
After using it for a while I noticed another issue. Closing the lid on the eeepc is not detected, so the screen stays lit and the netbook continues to run hot and heavy. I suspect xenial runs a bit hotter than puppeee since I sorta remember tinkering with some special eeepc settings available in puppeee, so this is a bit of an annoyance. I've currently "solved" the problem by creating a small script to echo "freeze" into
/sys/power/state and then placing a convenient icon for it on the desktop. That works ok, but it got me thinking maybe I should keep looking for alternatives. So I'm gonna try
AtomicPupXIX when I get a chance. It's supposed to be a slackware based puppy linux tailored to atom processors in the early eeepc lineup, so it could be a good fit.
Update Jan 21, 2019
I also did some work on the tiny zipit bleeding edge openwrt starter filesystem that gets installed by the latest
flashstock. I updated the certs and installed libustream-openssl to fix up links and wget, and a tossed in few other goodies while I was at it. And very quickly ran out of space.
No room for emacs.
Now the filesystem for this is comprised of a read-only squashfs and a 1MB overlay jffs. All the new stuff goes onto the jffs and that's where we ran outta room. But I sorta remembered checking the squashfs a while ago and discovered that it didn't quite fill up the entire mtdblock3 partition. So I dumped it to a file with dd and copied it over to my laptop where I used unsquashfs to examine the contents. Sure enough there was about 400K unaccounted for. So I figured I could squeeze (squash?) mpg123 and the libustream-openssl package in there. The certificates are likely to change in the future so they'll have to stay with the jffs. I had to simplify to a plain blue background, lose the zz-zipit sound file, and change a few duplicate files into softlinks, but eventually it all fit.
Plenty of room for emacs.
Hopefully I can fit the certs and both ziptuner and emacs onto the now roomier jffs partition.
Here's the fully packed
ultra-bleeding-squashfs.sfs file. I managed to fit everything else I wanted onto the jffs with over 700k to spare. If you boot your zipit from an SD card and your kernel is configured with the right mtd partition sizes you can use dd to upgrade the squashfs installed by flashstock.
root@zipitz2:/tmp# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "uboot"
mtd1: 00010000 00010000 "ubootenv"
mtd2: 00190000 00010000 "kernel"
mtd3: 004d0000 00010000 "squashfs"
mtd4: 00150000 00010000 "jffs2"
root@zipitz2:/tmp# dd if=ultra-bleeding-squashfs.sfs of=/dev/mtdblock3
9856+0 records in
9856+0 records out
And don't forget to upgrade /dev/mtdblock2 with
the latest openwrt kernel while you're at it.
One more tip. If you're like me and get really annoyed by bright or blinking LEDs, especially at night, you might want to edit /etc/init.d/z2leds. Set all three LED triggers to "none" to wrest control away from the kernel and give it to you. Also comment out or delete the bit where it checks the battery and turns on the "charged" LED.
root@zipitz2:~# cat /etc/init.d/z2leds
#!/bin/sh /etc/rc.common
#
# Setup Zipit Z2 LED's
#
START=11
start() {
echo "Setting up Zipit LED's (gimme full control)"
echo "none" > /sys/class/leds/z2\:green\:wifi/trigger
echo "none" > /sys/class/leds/z2\:green\:charged/trigger
echo "none" > /sys/class/leds/z2\:amber\:charging/trigger
# STAT=`cat /sys/class/power_supply/Z2/status)`
# if [ "$STAT" == "Full" ]; then
# echo "255" > /sys/class/leds/z2\:green\:charged/brightness
# fi
}
That didn't completely cure the epic seizures the kernel was having over the "charged" LED on my zipit, so mozzwald made this new
seizure free kernel.
Update Feb 3, 2019
In order to stay out of trouble, the seizure free kernel avoids reading the flaky charge controller status, and so it can't provide a charge full status to gmenu2x. This is a minor annoyance so I thought maybe some small updates to ebindkeys and or gmenu2x could work around it. But the squashfs partition is completely full, right down to the last 4K block. So I've had second thoughts about including the 150K dialog package in there, just to support the sleep timer applet. Especially so, since I had to substitute a slightly smaller non-wide character version of dialog -- It makes a mess of ziptuner on the international internet radio channels.
With this in mind I finally did something useful with my piles of ANSI escape sequence junk code, and made a
6K standalone menu script as a fallback if the sleeptimer applet finds no dialog package installed. Here's what it looks like.
The current code avoids using stty since it's not available in the squashfs, and at 50K I'm not planning to put it there. Eventually I'll redo the squashfs again without dialog, but with more updates and other goodies instead. Perhaps picocom and tinyirc.
...And I ended up replacing the dialog package with qemacs and tinyirc, in addition to the sleepmenu since that was an exact fit sizewise in the squashfs partition.
ultra-bleeding-squashfs-2.0.sfs
