Feb 152011

Amongst playing with the YubiKey, I also had a look at DHCPv6.  As people well know, IPv4’s days are numbered, and given we’re all going to have to jump across to IPv6 fairly soon, I figured I had better get acquainted with the newer protocols that come with it.

I’ve had my network running dual-stack for some time now.  This has been achieved using stateless autoconfiguration and router advertisments, which work fairly well.  Today though I decided I’d give DHCPv6 a crack.  For this, you will need the latest ISC dhcp package, net-misc/dhcp-4.1.0, which is hard-masked.

I hope to get something more mature going, but here are some notes who may wish to try this at home.

Setting up DHCPv6

Start by installing the net-misc/dhcp-4.1.0, on both server and clients…you will need to unmask it first:

# echo =net-misc/dhcp-4.1.0 | tee -a /etc/portage/package.unmask >> /etc/portage/package.keywords
# emerge -a dhcp

The -4 and -6 flags

Now, that will install the DHCP server and client.  The catch that initially caught me is that ISC dhcpd cannot run on IPv6 and IPv4 simultaneously. Neither can the client, but we’ll get to that.  Both server and client are put into IPv4 mode by running with -4 in the options, or -6 for IPv6 mode.  Documentation says it defaults to IPv6 mode, but my experience has been the opposite (maybe a Gentoo patch does this).

Server set-up

Needless to say, if you’ve got your network running IPv4, at most you might have to edit /etc/conf.d/dhcpd to add -4 to the start-up options (DHCPD_OPTS to be exact).  Easy.  It’ll work as before. If you want IPv6, okay, make that -6 in DHCPD_OPTS, no sweat. But what if you want both? Ohh fun, we need a second dhcpd instance.

My solution; copy each /etc/init.d/dhcpd and /etc/conf.d/dhcpd to /etc/init.d/dhcpd-v6 and /etc/conf.d/dhcpd-v6 respectively.  Make the necessary changes to /etc/init.d/dhcpd-v6 and /etc/conf.d/dhcpd-v6.  So that the two don’t clash, I thought it wise to substitute DHCPD with DHCPDV6 using a text-editor (replace all).

You’ll also want to rename the leases file (dhcpd.leases, I chose dhcpd-v6.leases) and the PID file.  In addition the init script calls dhcpd to check the configuration in checkconfig(), so add -6 there too.  To save you going back and adding it in /etc/conf.d/dhcpd-v6, you can also add the -6 flag to the start-stop-daemon call in in start().  Do similar manipulations to /etc/conf.d/dhcpd-v6.

As for the server configuration file itself, I called my IPv6 config file /etc/dhcp/dhcpd-v6.conf to differentiate it from v4.  The two will need separate configuration files.  At the top of the v6 configuration file, you’ll want to point it to new PID and leases files:

pid-file-name "/var/run/dhcp/dhcpd-v6.pid";
lease-file-name "/var/lib/dhcp/dhcpd-v6.leases";

Adding that to the top of dhcpd-v6.conf will take care of this.  If you’ve done everything right, you should be able to start the DHCPv6 daemon, and add it to your runlevels as per normal.  DHCPv6 listens on port 547/UDP — look for it in netstat.

Client set-up

Client set-up isn’t too difficult, the fun bit is integrating dhclient into the init scripts.  OpenRC knows how to drive dhclient in v4-mode, but not v6.  It too, cannot run in both v4 and v6 mode simultaneously.  The solution: a new net module.  Copy /lib/rc/net/dhclient.sh to /lib/rc/net/dhclientv6.sh.

Rename all the functions changing dhclient to dhclientv6 (don’t use replace-all this time), and change the “provide” line in dhclientv6_depend to dhcpv6.  In dhcpclientv6_expose, do likewise, rename the variables dhclientv6 and dhcpv6.  Finally,  in each  call to the dhclient binary itself, add -6 to it to put it in IPv6 mode, and rename the PID file to add -v6 to the file name.

Save the new file.  Now in /etc/conf.d/net, use the following:

config_eth0=( "dhcp" "dhcpv6" )

Things that I have not yet figured out

Dynamic DNS

This is one of the reasons why I wanted DHCPv6 in the first place.  Remembering IPv4 addresses is bad enough.  IPv6 is a pain.  I have more success citing Pi than remembering the IPv6 address of all my computers.  The statically assigned ones aren’t too bad since the prefixes are all the same, it’s the autoconfigured ones that are a nuisance.

It should be doable, but I haven’t yet worked out how to make dhcp update the nameserver with AAAA records.  This is still in its infancy though.  Lots of rough edges.  I note dhclient doesn’t seem to be passing on the hostname of the computer, which could be part of the problem.

Address pools and class-based assignment

Address pools are handy things.  In ISC dhcpd, I can classify each of the computers I have by their MAC address and assign each class an address pool.  Or at least I could when it’s in IPv4 mode.

I have a nice set-up on IPv4 where if the DHCP server knows the MAC address, it’ll put that computer on the right subnet.  We have three IPv4 subnets here; one for my computers, one for my father’s and a “de-militarised zone” where any foreign computers get put (along with the web server, well actually it exists on all three).  Below is an example:

subnet netmask {
  pool {
    range dynamic-bootp;
    allow members of "stuartslan";

  ddns-domainname "redhatters.yi.org.";
  ddns-rev-domainname "in-addr.arpa.";
  ddns-updates on;
  update-conflict-detection off;
  allow client-updates;

  /* ... */
/* ... */
subclass "stuartslan" 1:6c:f0:49:ef:84:7c; # beast eth0
subclass "stuartslan" 1:6c:f0:49:ef:84:7e; # beast eth1
subclass "stuartslan" 1:08:00:27:ab:7c:b9; # Win2K VirtualBox
subclass "stuartslan" 1:08:00:27:27:bf:55; # uClibc VirtualBox
subclass "stuartslan" 1:00:08:0d:5c:08:51; # Laptop "vk4mslp2" ethernet
subclass "stuartslan" 1:00:12:f0:bd:de:06; # Laptop "vk4mslp2" wireless
/* ... */

I haven’t figured out how to replicate this in DHCPv6.  The following does not work:

subnet6 2001:388:d000:1153::/64 {
  pool {
    allow members of "stuartslan";
    range6 2001:388:d000:1153::1000 2001:388:d000:1153::ffff:ffff;

  ddns-domainname "redhatters.yi.org.";
  ddns-rev-domainname "ip6.arpa.";
  ddns-updates on;
  allow client-updates;
  /* ... */

I plan to keep researching these things, and I’ll see what I can do about getting the updates into Gentoo’s init scripts so that DHCPv6 is handled.  A lot of what I did today were quick hacks that will likely make people shudder, but it’s working for now, we’ll see how it goes.

Jan 242011

Well one Lemote Fuloong 2F system has already been given away, and the new owner has been asked to try and find out about them.

Some of you may be aware of some Lemote related resources on my devspace.  I’ll try to get some Fuloong 2F stuff up there,  but I’m flying blind as I don’t have one of these systems.  The netboot and LiveUSB image you see online is for its older cousin based on the Loongson 2E CPU, and won’t work on the Yeeloong or the newer Fuloong, as the graphic chipset and northbridge differ substantially. The stage 3 tarballs (MIPS I or MIPS III little-endian) will work however.

I’ve got one of the Fuloong 2Es onto the case now however, we’ll see what we can get achieved over the next few days.

Jan 242011

Well, here I am.  Just registered and watching the stream flowing into the rego desk.  It’s not a queue, it’s the whole alphabet.  The only queue I’ve seen longer recently was the one to the checkout at the local shopping centre just before the flood peak.

Journey between The Gap and Kelvin Grove along Waterworks Road/Musgrave Road (to the Normanby Fiveways) took a bit over an hour, had a good conversation on the Mt. Cotton repeater, but evidently I’ve got a connection issue with the antenna.  That, and a bump just severed the connection between the battery and fuse holder, so I shall be riding home in silence tonight.  (Not the first time this has happened either.)

Not sure what to expect today, being my first time, guess I’ll find out.

On other news, Gentoo/MIPS I Big-endian stage 3 got uploaded last night.  Builds for other ISA levels continue.

Jan 172011

Well, that pretty much explains me the last few days.  Haven’t really done much planning, just been taking it one day at a time.  Ironically, it’s exactly what I recall seeing as the theme for linux.conf.au this year.  The very same year that the Brisbane and Bremer rivers decided to get out of bed and visit the neighbourhood.  Pity neither river thought to wipe their feet before flowing through peoples’ houses, leaving a trail of smelly mud behind.

Saturday and Sunday were spent over at Kenmore helping out my grandparents with the clean-up effort there.  As I was home alone, I relied on my one and only form of transport, the bicycle, riding (and walking) Gap Creek Road between The Gap and Brookfield.  Surprisingly, I can do that run in a bit over 1:20 or so, not bad for pedal power alone, and with a trailer loaded with gas bottle and camp stove to boot.

And of course today, seems I was a glutton for punishment, fronting up to Graceville State School and signing up to volunteer there along with my father.  So very little time spent in front of the computer this weekend.  Apart from the nasal assault the mud inflicted as we drove around Graceville area and the tiredness from all the running around, things aren’t too bad.  Our house here in The Gap suffered no ill effects from the floods.

Gentoo/MIPS builds have plodded along, I had to re-start the Qube2 building MIPS4 little-endian builds as it crashed for some unknown reason.  The O2 is busy building MIPS1 Stage 3 now as I type this.  The little-endian builds for MIPS1 and MIPS3 are already online in my devspace.  I’ll see about getting these moved to mirrors when the others are up too.  Cobalt users;  MIPS4 builds will be some time yet, if you’re desperate, the MIPS3 ones will work.

I’ve only uploaded the stage 3’s for now, since the stage 1’s gave me a slight hiccup with regards to python-wrapper, if you really want a stage 1 or 2 image, just throw the stage 3 at catalyst.

I did plan to try and at least get something going on the netbook as a bit of show-and-tell for linux.conf.au, which is rapidly approaching.  I probably won’t get time, but at least it’s working, so I’ll leave it for now.  I will definitely be there next week.  Those in the Gentoo community, we should definitely meet up at some point.  If you see someone riding in, looking like a postie with a bike downgrade, it’s probably me, particularly if the bike in question has an antenna or two mounted on it.

VK4MSL/BM on 2m

VK4MSL/BM on 2m: side view, will probably be seen at LCA2011

I’ve been ambushed by people lurking around it before.  I probably won’t have the coolie hat with me (too awkward to carry on a bicycle, and of course I can’t wear it with the helmet) so in terms of visual queues, that’ll have to do.  I’ll likely also be on the 2m band a lot whilst in-transit between The Gap and QUT where LCA2011 is to be held, so expect to hear me on 147.075MHz (VK4RAX) and 146.875MHz (VK4RBS) repeaters.  Sadly, no APRS yet, so you won’t be able to track me that way for now.

This week, a lot of nets and club activities also resume, including the Brisbane Amateur Radio Club, who meet at the Queensland Maritime Museum just across the water from LCA2011 at 7:30PM that Friday (the 21st)  for a business meeting.  Despite it being largely for business, we welcome anyone wishing to come across and say ‘ello.  Amateur Radio and the Open-Source community do have a lot in common.

In short, I’m cracking the whip on the O2, and hoping to have at the very least, MIPS1 big-endian builds up by the start of LCA2011, and I hope to meet a lot of you at this year’s LCA, which will be the first time I’ve attended one of these events.

Dec 292010

Recently, a new version of binutils was released.

I had reported earlier about some patches needed to work around errata bugs in the Loongson CPUs.  There were also some other big updates since.  GCC 4.5 and Perl 5.12 have both been unmasked, enough has changed to warrant a rebuild before things get too far out of date.

This release will come with binutils-2.21 which incorporates many fixes for linker issues on MIPS, as well as the Loongson errata.  I have successfully compiled KDE 4.5 using a CVS HEAD version of binutils snapshotted around the time that the 2.21 branch was created, and found that it has fixed quite a few issues.

If you haven’t upgraded just yet, hold on a few weeks and I’ll have new stages up for all to try out.  MIPS-I Little-Endian is building now as I type this, I’m in the process of building seed stages for big-endian builds.  MIPS-III and MIPS-IV little endian builds will begin very soon too (before noon AEST).

I expect I should have most of the little-endian builds up before new year, and the whole release out in early January 2011.

Dec 122010

Well, binutils-2.21 has been released. Amongst the changes were some fixes for Loongson 2E and 2F systems, and a whole host of MIPS related commits.

I tried experimenting with one of the binutils CVS releases, and had good success building Qt and the KDE desktop on the Yeeloong. I still have issues with JavaScript in Konqueror, and some other apps are glitchy, but the desktop is usable on MIPS, and is reasonably responsive.

It is my plan to fire up the MIPS systems for a new round of stagebuilds for the O32 port of Gentoo/MIPS. These will hopefully include the latest binutils release, latest Perl and gcc.

Nov 092010

32-bit Gentoo/MIPS stages for both big and little endian systems are now available for MIPS-I, MIPS-III and MIPS-IV.  For now I’ve got these on my devspace, but I hope to get some of them out to mirrors as soon as possible.  I’d appreciate any feedback on this release.

The little-endian stages should work on Loongson systems.  All stages include a patched binutils binary (see bug #338405) which adds some fixes for errata in the Loongson 2F CPUs and the little-endian stages for MIPS-I and MIPS-III have this fix enabled in the CFLAGS, enabling their use on Loongson hardware.  They will also work on non-Loongson systems.

I’ve been doing quite a bit of testing with the little-endian stages in particular, and have had few problems with getting many software packages to work.

binutils-2.21 already includes the fixes needed, along with lots of other MIPS-related fixes… and so when that is released (they’ve already done a branch freeze for 2.21) I plan to build new stages based on this newer toolchain, and with the newer Perl release.  Current stages use Perl 5.8.8 since I found I hit a few snags at the time which I thought were better dealt with later (some package complained there was “something funny about this Perl version” and bombed out) as the primary concern for the Gentoo/MIPS port at the time revolved around gcc.

I downloaded and installed binutils last night, based on that day’s CVS snapshot.  I’m now trying to see if I can get qt-webkit to build (the biggest sticking point so far) using that, with the view of having a workable KDE-based desktop going on the Yeeloong and the Fulongs here before LCA 2011.  (For now I’ve got FVWM.)  In the meantime I’ll be keeping an eye on the binutils mailing list.

On the LCA front… I got formal confirmation of my payment on the weekend… so I’m definitely a go-er… I’m still trying to find out if I’ll be helping out with any stalls…

There’s a social meeting of the Brisbane Amateur Radio Club this Friday, wherein our involvement in LCA will probably be discussed — club president was supportive of the idea when we discussed it on our 2m net last Wednesday evening… we just need to figure out what we can do, who can do it, and what needs to be done.

I’ve managed to get fldigi going on Gentoo/MIPS, and so maybe interfacing one of the computers I have (either one of the Fulongs or the O2) to a radio transceiver… (perhaps one of the ships’ radios on the HMAS Diamantina… nice mix of old+new-er) decoding some RTTY or PSK31, is an option.  We’ll have to decide this formally.

Those who wanted to drop in… we meet at the Queensland Maritime museum this Friday (and every second and fourth Friday except fourth in December and second in January) at 7:30PM — entrance is via “Service Gate 2” off Lower River Terrace.  We meet in the lunch room under the bridge.  If anything is decided, we will likely make our final decision at the following business meeting, which happens a fortnight later.

BARC Meeting entry point

BARC Meeting entry point... via Service Gate 2 off Lower River Terrace

If Gentoo has a stall, it’d definitely be worth setting up one of the Fulongs there… and for that I’d want a reasonable desktop going (KDE, or maybe XFCE… I know people have done some stunning work with FVWM, but I’m not that good).  I look forward to LCA regardless… if neither Gentoo nor BARC are running a stall in the open day, then I’ll just have a look around and see what it’s all about.  I look forward to the event anyway. 🙂

Oct 282010

Hi all,

I’m in the process of registering for LCA2011… since it’s in my home town, I figure I may as well show up. 🙂 This will be the first LCA that I’ve attended, last one I was looking at going to was the one in Sydney a few years back … however at the time I just didn’t have the funds.

Now, with it in Brisbane (therefore no need for a hotel room), and having some money in the bank, there’s no excuse for me.

I’m not certain if Gentoo is organising a stall there or not this year, and there’s mention of the Brisbane Amateur Radio Club (of which I am a member), not sure what activities are going there either (this could be in error… I’ll inquire with the group and see what’s doing). If we have a stall… figured it’d be a good opportunity to get one of the Fuloong computers up and running as a bit of a demonstration of Gentoo/MIPS… maybe get my O2 running fldigi with my FT-897D decoding some PSK31 as well if BARC are involved. We shall see.

What is certain though, is that I’m taking the plunge this year… before the earlybird pricing expires in early November.

Oct 132010

Hi all,

The O32 stage builds for little-endian MIPS systems are now complete, and you will find the stages on my devspace for now at http://dev.gentoo.org/~redhatter/mips/cobalt/stages/.  There you will find stages for:

  • MIPS-I: Suitable for all little-endian MIPS hardware
  • MIPS-III: Best for Loongson-based hardware
  • MIPS-IV: Best for Cobalt Qube2 and RaQ2… Possibly the earlier Qube/RaQ as well.

Note that for the latter two, there are also N32 stages in the pipeline.  N32 overcomes a lot of shortcomings of the O32 ABI and offers better performance overall.  For many years, Gentoo/MIPS has primarily used O32 as the default ABI, with N32 being considered “experimental”.  Zhang Le and others have done a lot of work in the field, and now many applications run fine on N32.  Gentoo will therefore be transitioning over to this newer ABI, leaving O32 available for legacy system support and for experimental targets.

And yes, I’ll have to get to and update the documentation.

Some erratum notes however… These stages all feature a binutils patched for Loongson 2F support.  In the case of the MIPS-I and MIPS-III stages, these were also built with the -Wa,-mfix-loongson2f-nop set in CFLAGS so that these stages will work on Lemote hardware.  (And I needed to do that, otherwise we’d be waiting until Christmas for the Qube2 to finish building.)  So Loongson users should find these stages will work without further patching.  MIPS-IV was not built with the changes to CFLAGS, however these stages will also not run due to incompatibilities with ABI.

Secondly, the issue with /dev still exists… I’m not sure where the bug is, I’m still investigating this.  The following run inside the chroot should correct this issue:

# rm /dev/null
# mknod /dev/null 1 3
# USE=build emerge --oneshot makedev

I’d be naïve to think it probably won’t happen on the big-endian stages… we shall see. Stage 1 for MIPS-I big-endian is already up, with stage 2 well underway. The O2 is just a little quicker than the Qube2 in that regard. 😉 I hope to have big-endian stages up by November.

Oct 122010

Hi all…

It’s been a long time since I took over the maintenance of svxlink in Gentoo, and to be frank, I’ve done basically nothing with it because for the most part, it worked. Much development has gone on upstream, however no newer releases have been made, the only way to get the latest stuff is via SVN. This includes the somewhat experimental Qt4 branch.

Since Qt3’s demise, we’ve had to drop Qtel from the package… prompting bug #336993. There are also issues with initialisation scripts (bug #335307).

Consequently, I decided to try out this new Qt4 branch from SVN. For those playing along at home, the installation instructions are simple enough:

$ svn co https://svxlink.svn.sourceforge.net/svnroot/svxlink/branches/qt4/
$ cd qt4/src
$ make
$ sudo make install

At first, I found it wasn’t working… completely deaf and mute.  Vox didn’t show any sign of hearing my audio from the microphone… and I couldn’t hear anything back.  I tried some other ALSA devices… at this point Qtel only supported one audio device at a time.  Some tinkering, I found I could get it to hear me, but audio was very scratchy.

I had noticed this with aplay too… the problem being that the audio CODEC on the Yeeloong runs at 48kHz, and does not support other rates.  I managed to set up dmix to enforce a 48kHz rate (and give me software mixing as a bonus), then set up a rate converter atop this… but a snag, you can’t record from dmix, and Qtel (or rather libasyncaudio) expected a two-way device.  I suggested to Tobias that having separate microphone and speaker devices would be a good idea.  In double quick time he had updated the Qt4 branch to support this.

Some tinkering, and I managed to get it to hear me, but I was still effectively deaf.  It took some more investigation to track down some of the other issues, but eventually this morning I cracked it.  I had working audio both ways… but received audio was still very scratchy.  Further testing with aplay, after thinking I had solved the problem confirmed this.  More fooling around with .asoundrc ensued.  I finally tried an upgrade of the kernel to 2.6.36-rc7 (linux-loongson-community git HEAD).  Voila, rate converted sound out of aplay came through crystal clear.

I started Qtel and tested it initially on *ECHOTEST*, then on a local repeater (VK4RBR-L node 284321 / 147.950MHz FM) listening via RF as well. No problems there, it seems to be able to make contacts no problems at all. I will have to try svxlink itself at some point to see if I can successfully construct a node using the software, but for now my own node is back on the air after a long hiatus… and I hope to have new ebuilds in the tree.

In particular, svxlink will be split into a few packages.

  • dev-libs/libasync: Asynchronous I/O Library
  • net-libs/echolib: Echolink Communications Library
  • media-radio/svxlink: svxlink and remotetrx
  • media-radio/qtel: Qt Echolink client

I should probably try it on the O2 as well, but Qtel, libasync and echolib will probably get keyworded ~mips too, since they work fine on the Yeeloong   The others… well, I’ve got the parts to make an interface cable for the FT-897D here, in fact, enough for two.  The plan is to make up this interface cable, and try setting up a node on FM simplex.

There’s a second ‘897D as well… however it has a burnt out microphone preamp after a storm blew it up (and a blown up DDS chip, so no SSB or AM TX on this rig).  Miraculously, its finals seem intact as it’ll happily blast out 50W RF on 2m (with no modulation).  If the data interface works okay though, it may work well enough for a temporary 70cm node on one of the local repeaters, VK4RBC Mt. Coot-tha.

In the meantime, my personal node is now up and running again after a long hiatus… Look for VK4MSL in your client or dial  37 37 40 via RF.

Obligatary screenshot of Qtel in action

Obligatary screenshot of Qtel in action on the Yeeloong