Feb 172013
 

Well, I was half expecting that it’d happen one day. Gentoo Bug 89744, the bug that saw me promoted to developer on the Gentoo/MIPS team, is now a retirement bug in full swing.

To those in the Gentoo community, I say, thank-you for putting up with me for so long. It is probably time that I moved on though. Real life has meant I’ve got practically no time during my working week to do anything meaningful, and after a week of arguing with computers (largely Ubuntu-based) I come home on a Friday evening not feeling like even looking at a computer. Some weekends, the computer has stayed in my backpack, and not been removed until the following Monday when I return to work.

Thus the time has come, I must be going.

That said, I mostly did enjoy the time I had as a developer. I still remain a Gentoo user, as that seems to be the OS that best fits my usage patterns, and I might pop up from time to time, but I’ll probably maintain a fairly low profile from now on.

I actually didn’t notice the account being shut down, only discovered today in fact, that the redhatter@gentoo.org email address was not working from an Amateur radio colleague. It’s then I thought to have a quick gander and found out what had happened.

This does leave me with two Lemote boxes, that technically no longer belong here.

Remember these? They’re looking for a home now!

I shall enquire, and find out where to send the boxes themselves, or a donation to cover their cost. It is not right that they remain here without some sort of compensation.

This leaves some people without a means of contacting me.  I don’t bother with the instant messengers these days, and definitely not Skype.

Plain old email still works though, you can contact me at stuartl at longlandclan dot yi dot org from now on.  As for the old links on dev.gentoo.org, terribly sorry but that’s outside my control now.


Update:

The Lemote boxes now have a home. Thanks Anthony!

Sep 132011
 

Hi all…

I got fed up of restoring my firmware for the Broadcom wireless chip in my late-2008 model MacBook.  Anyone who has one of these might find the current in-tree versions of net-wireless/b43-firmware is missing files needed by the modern b43 driver (namely ucode16_mimo.fw), and net-wireless/b43-fwcutter doesn’t well, cut it, for extracting the newer files.

If you’ve got a newer 802.11n-based Broadcom chip, you might find the following ebuilds handy:

  • net-wireless/b43-firmware-5.10.56.27.3
  • net-wireless/b43-fwcutter-015 and net-wireless/b43-fwcutter-9999

The first is the firmware mentioned in this post.  It needs a newer fwcutter binary than is provided in Portage.  You’ve got the choice of the latest version, or the bleeding edge via git.  Both work at time of writing, although neither are guaranteed.

The ebuilds are not in-tree, I’ll leave that for the actual maintainer for these ebuilds to pick them up if desired, I’ve put them in an overlay accessed via the following command:

git clone git://git.longlandclan.yi.org/overlays/b43.git

Or you can take a squiz via gitweb.

Jun 202011
 

To whoever were responsible for developing this new feature in the latest Portage releases…

zhouman portage # FEATURES=-test USE=-handbook\ -doc emerge -eukDN --keep-going system kde-meta vim poppler =xulrunner-2.0.1-r1 =vim-core-7.3.189 =gvim-7.3.189 gst-plugins-base vim =gst-plugins-theora-0.10.32 =firefox-4.0.1-r1
Calculating dependencies... done!

!!! One or more updates have been skipped due to a dependency conflict:

app-editors/vim-core:0

(app-editors/vim-core-7.3.219::gentoo, ebuild scheduled for merge) conflicts with
~app-editors/vim-core-7.3.189 required by (app-editors/gvim-7.3.189::gentoo, binary scheduled for merge)
(app-editors/vim-core-7.3.219::gentoo, ebuild scheduled for merge) conflicts with
=vim-core-7.3.189

!!! The following update(s) have been skipped due to unsatisfied dependencies
!!! triggered by backtracking:

app-editors/vim:0
[binary R ] x11-proto/xf86vidmodeproto-2.3.1
[binary R ] sys-libs/zlib-1.2.5-r2
[binary R ] sys-libs/ncurses-5.9
[binary R ] x11-proto/xproto-7.0.21
[binary R ] virtual/libintl-0
[binary R *] sci-visualization/gnuplot-4.4.2-r1
[ ... ]
[ebuild N *] kde-base/kdebase-meta-4.6.4 USE="(-aqua)"
[binary R *] media-libs/mediastreamer-2.7.3-r3
[ebuild N *] kde-base/kopete-4.6.4 USE="addbookmarks autoreplace contactnotes highlight history jingle nowlistening pipes privacy sms ssl statistics texteffect translator urlpicpreview v4l2 xmpp zeroconf (-aqua) -debug -gadu -groupwise -handbook (-kdeenablefinal) -latex -meanwhile -msn -oscar -otr -qq -skype -testbed -webpresence -winpopup -yahoo"
[binary R *] media-plugins/mediastreamer-ilbc-2.0.3
[ebuild N *] kde-base/kdenetwork-meta-4.6.4 USE="(-aqua) -ppp"
[ebuild N *] kde-base/kde-meta-4.6.4 USE="accessibility nls (-aqua) -sdk -semantic-desktop"

The following keyword changes are necessary to proceed:
#required by kde-base/kdebase-runtime-meta-4.6.4, required by kde-base/kdebase-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kglobalaccel-4.6.4 **
#required by kde-base/kdemultimedia-meta-4.6.4[mplayer], required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/mplayerthumbs-4.6.4 **
#required by kde-base/kdeedu-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/rocs-4.6.4 **
#required by kde-base/kdegames-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kigo-4.6.4 **
#required by kde-base/kajongg-4.6.4, required by kde-base/kdegames-meta-4.6.4[python], required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/oxygen-icons-4.6.4 **
#required by kde-base/kdebase-runtime-meta-4.6.4, required by kde-base/kdebase-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kdebase-menu-4.6.4 **
#required by kde-base/kdeutils-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)

[...]

NOTE: This --autounmask behavior can be disabled by setting
EMERGE_DEFAULT_OPTS="--autounmask=n" in make.conf.

Use --autounmask-write to write changes to config files (honoring CONFIG_PROTECT).
zhouman portage #

THANK-YOU

You’ve just made my life trying to install and test big collections of software in Gentoo/MIPS much easier. 🙂

Jun 192011
 

Well, I’ve been meaning to get around to fixing up svxlink in Gentoo for a long time now. For those who don’t know, svxlink is a client and server for the EchoLink amateur radio linking system.

We had to stop releasing the Qtel client, as it relied on Qt3 which we no longer ship in Gentoo.  On top of this, the ebuild installed non-Gentoo init scripts, fails to build with gcc-4.6 and fails due to underlinking.  (My thanks go to Diego for pointing these flaws out.)

At the moment I’m working on the first problem, which is that the builds that were in-tree are crusty and old.  svxlink did release version 11.05 not long back, and ohh yes, they’ve changed their versioning scheme too to match Ubuntu.  However, their trunk branch is still dependent on Qt3 if you want Qtel.  There is an experimental Qt4 branch, which is what I’ve been working with.

One irritation I had was trying to make it possible to install the client component or the server component.  svxlink has its own, very custom, build system based on recursive makefiles.  (Yes, I know, considered harmful and all that.)  The build system first builds the core libraries, then it starts looking at Qtel and svxlink’s server components.  The first thing was to try and split these up.

The new ebuilds will introduce a svxlink-libs package.  This is relatively straightforward, and it just builds & installs the libasync, libechlib and liblocationinfo libraries.  The catch is when building qtel and svxlink, the build system looks for the built binaries inside the source tree.

I have submitted a patch upstream that remedies this.  Eventually I’ll look at how we can fix some of the other flaws in the build system.  So far I’m still battling svxlink itself, but I soon will have svxlink-libs and qtel packages available for testing in the Portage tree.  svxlink itself will also need to wait until I can set up a test node on simplex somewhere… my O2 looks like a likely possibility.

I’ll keep you all informed as this progresses.  Qtel appears to be working (although I’m battling some funnies with the sound device on the Apple MacBook)… just a matter of fixing some issues with the build system for svxlink and I should be able to have svxlink back in the tree once again.

May 162011
 

This weekend just gone I was at Imbil helping out with the International Rally of Queensland, reporting scores for the car rally there.  This was my first look at packet radio in action.  Prior to this I had enabled the amateur radio options in the kernels I built, but never tried actually hooking radio to computer.  I shall be posting some notes on how I got this working…

zhouman ~ # uname -a
Linux zhouman 2.6.35.7-lm2f-nb #2 Wed Oct 13 00:42:58 EST 2010 mips64 ICT Loongson-2 V0.3 FPU V0.1 lemote-yeeloong-2f-8.9inches GNU/Linux
zhouman ~ # ifconfig sm0
sm0 Link encap:AMPR AX.25 HWaddr VK4MSL
inet addr:172.31.32.1 Bcast:172.31.32.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:256 Metric:1
RX packets:365 errors:0 dropped:0 overruns:0 frame:0
TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:24236 (23.6 KiB) TX bytes:6850 (6.6 KiB)

zhouman ~ # mheard
Callsign Port Packets Last Heard
VK4EA-9 sm0 6 Mon May 16 17:59:12
VK4NRL-9 sm0 1 Mon May 16 17:58:40
VK4VP-1 sm0 8 Mon May 16 17:58:38
VK4RAI-3 sm0 9 Mon May 16 17:57:58
VK4TIM-9 sm0 14 Mon May 16 17:57:56
VK4TDI-1 sm0 2 Mon May 16 17:57:39
VK4DC-1 sm0 15 Mon May 16 17:57:07
VK4TEC-9 sm0 120 Mon May 16 17:56:08
VK4FY-1 sm0 18 Mon May 16 17:54:38
VK4RMO-3 sm0 1 Mon May 16 17:54:33
VK4RGC-3 sm0 3 Mon May 16 17:52:48
VK4RC-1 sm0 8 Mon May 16 17:51:29
VK4FIL-1 sm0 4 Mon May 16 17:46:44
VK4RIL-13 sm0 4 Mon May 16 17:45:43
VK4RBR-3 sm0 5 Mon May 16 17:42:59
VK2RDO-3 sm0 2 Mon May 16 17:41:19
VK4RRC-13 sm0 3 Mon May 16 17:36:39
VK2JUB-1 sm0 2 Mon May 16 17:34:44
VK4BNQ-1 sm0 1 Mon May 16 17:26:58
VK4LDA-9 sm0 2 Mon May 16 17:24:59
VK2POO-9 sm0 9 Mon May 16 17:21:24
VK2XFL-9 sm0 1 Mon May 16 17:21:09
VK4RSR-3 sm0 1 Mon May 16 17:20:04
VK4IE sm0 1 Mon May 16 17:15:04
VK4ALJ-3 sm0 1 Mon May 16 17:15:00
VK4HPW-9 sm0 5 Mon May 16 17:13:23
zhouman ~ #

Set-up consisted of:
Linux kernel on Lemote Yeeloong, latest soundmodem driver, Yaesu FT-897D, homebrew interface cable plugged into Yeeloong’s onboard sound card, USB serial driving BC547 in interface cable for PTT.

zhouman ~ # cat /etc/ax25/soundmodem.conf
<?xml version="1.0"?>
<modem>
<configuration name="FT897-D">
<chaccess txdelay="150" slottime="100" ppersist="40" fulldup="0" txtail="10"/>
<audio type="alsa" device="plughw:0,0" halfdup="0" capturechannelmode="Mono"/>
<ptt file="/dev/ttyUSB0"/>
<channel name="Channel 0">
<mod mode="afsk" bps="1200" f0="1200" f1="2200" diffenc="1"/>
<demod mode="afsk" bps="1200" f0="1200" f1="2200" diffdec="1"/>
<pkt mode="MKISS" ifname="sm0" hwaddr="VK4MSL" ip="172.31.32.1" netmask="255.255.255.0" broadcast="172.31.32.255"/>
</channel>
</configuration>
</modem>
zhouman ~ #

I’ve shut it down for now, but I’ll give it a bit more work on 145.175MHz tomorrow. Once I get something working, I might set something up using the O2 or one of the Fulongs (probably the latter) and see about getting soundmodem back into Gentoo.

Update: After hand-editing the ebuild to enable APRS support, I can successfully report that not only is soundmodem working, but so is Xastir on my Yeeloong, as can be seen on aprs.fi.

Apr 232011
 

Well, been some time now since I announced the start of some µClibc stages.  So far, not much has happened there other than the fact that I’ve successfully hard-locked the Fulong 2E system that I tried compiling on.  This is despite compiling with binutils-2.21 and using -Wa,-mfix-loongson2f-nop… which is usually enough to prevent lockups.  Clearly there’s further erratum that I’m hitting, I might try later on the Qube and see where that gets us, agonisingly slow might be better than the current pace.

Generic N32 MIPS-III little endian continues to remain unavailable due to an issue compiling Python 2.7, and unfortunately my N32 chroot on the Yeeloong broke when I upgraded glibc (the primary reason why I began doing a generic MIPS3 build on the Qube using Matt’s MIPS4 build).  I will get back onto this eventually.

On other news since the purchase of the MacBook I’ve been able to leave my Yeeloong sit at home running continuously to update the entire system.  Qt 4.7.2 gave me some grief — it seems at least on mipsel, qmake segfaults during the initial build of qt-core …

mipsel-unknown-linux-gnu-g++ -o "/tmp/portage/x11-libs/qt-core-4.7.2-r1
/work/qt-everywhere-opensource-src-4.7.2/bin/qmake" project.o property.
o main.o makefile.o unixmake2.o unixmake.o mingw_make.o option.o winmak
efile.o projectgenerator.o meta.o makefiledeps.o metamakefile.o xmloutp
ut.o pbuilder_pbx.o borland_bmake.o msvc_vcproj.o msvc_vcxproj.o msvc_n
make.o msvc_objectmodel.o msbuild_objectmodel.o symmake.o initprojectde
ploy_symbian.o symmake_abld.o symmake_sbsv2.o symbiancommon.o registry.
o epocroot.o qtextcodec.o qutfcodec.o qstring.o qtextstream.o qiodevice
.o qmalloc.o qglobal.o qbytearray.o qbytearraymatcher.o qdatastream.o q
buffer.o qlist.o qfile.o qfsfileengine_unix.o qfsfileengine_iterator_un
ix.o qfsfileengine.o qfsfileengine_iterator.o qregexp.o qvector.o qbita
rray.o qdir.o qdiriterator.o quuid.o qhash.o qfileinfo.o qdatetime.o qs
tringlist.o qabstractfileengine.o qtemporaryfile.o qmap.o qmetatype.o q
settings.o qlibraryinfo.o qvariant.o qvsnprintf.o qlocale.o qlinkedlist
.o qurl.o qnumeric.o qcryptographichash.o qxmlstream.o qxmlutils.o  -Wl
,-O1 -Wl,--as-needed                           
floatmath auto-detection... ()                                         
/tmp/portage/x11-libs/qt-core-4.7.2-r1/work/qt-everywhere-opensource-sr
c-4.7.2/config.tests/unix/compile.test: line 71: 25542 Segmentation fau
lt      "$OUTDIR/bin/qmake" -nocache -spec "$QMKSPEC" "CONFIG+=$QMAKE_C
ONFIG" "CONFIG-=debug_and_release" "LIBS*=$LFLAGS" "LIBS+=$MAC_ARCH_LFL
AGS" "INCLUDEPATH*=$INCLUDEPATH" "QMAKE_CXXFLAGS*=$CXXFLAGS" "QMAKE_CXX
FLAGS+=$MAC_ARCH_CXXFLAGS" "QT_BUILD_TREE=$OUTDIR" "$SRCDIR/$TEST/$EXE.
pro" -o "$OUTDIR/$TEST/Makefile"                                       
gmake: *** No targets.  Stop.                                          
floatmath disabled.                                                    
... etc for numerous other modules.

qt-4.6.3 builds without issues, but this is not sufficient for KDE 4.6.  I’m still investigating.  hyperestraier also fails to build, but only if you have USE=debug set, disable that USE flag and it builds without issues.

Fingers crossed, I can get Qt 4.7 and KDE 4.6 to build, and that there aren’t any issues.  Previously libkjs used to be quite unstable which is one of the main reasons I have not keyworded any release of KDE 4 for MIPS.  Yes, you could dodge around it and have a usable desktop, but I didn’t consider it working well enough for keywording.

Mozilla stuff will need some loving too.  I hope to upgrade to Firefox 4.0 on MIPS, see how that goes.  One of these days I’ll get onto tackling Thunderbird.  Sadly my life away from Gentoo intervenes and thus my plans frequently get put on the backburner as work demands my attention elsewhere.

Apr 102011
 

Well, I’ve done some tinkering with Gentoo/Prefix on MacOS X.  Not bad so far, although there’s a lot of packages not keyworded… (a bit like MIPS) and some packages I miss from regular Gentoo (e.g. crossdev).  However, we can work on sorting this out over time.

For those of you who aren’t particularly fond of going on a copy/paste fest from the documentation, I decided rather than sit there all night and manually do it, I’d code up a script to do it for me.  Behold: Gentoo MacOS X bootstrap script.

Usage:

$ export EPREFIX="${HOME}/.gentoo/amd64"
$ export CHOST="x86_64-apple-darwin10"
$ mkdir -pv "${EPREFIX}"
$ sh do-bootstrap.sh
Mar 152011
 

Well, one thing I’ll need to investigate… I’ve been battling a slightly broken bzip2 which when compressing some files, would cause the whole machine to lock up.  Environment is µClibc-0.9.31 based, using gcc-4.5.2.

Everything compiled with the CFLAGS: “-Os -pipe -mips1 -Wa,-mfix-loongson2f-nop”.  The latter flag is really for Loongson 2F but I find it helpful on 2E as well.  Things seemed to go well, except that I had no end of problems with the machine locking up when running bzip2 on some files.  I found it reproduceable while building autoconf within Catalyst stage 1.

It would appear it’s a compiler issue, as when I rebuilt bzip2 using the CFLAGS: “-O2 -march=loongson2e -Wa,-mfix-loongson2f-nop”, it worked fine.  I will have to investigate this further.  I don’t think it’s a MIPS-I vs Loongson 2E issue, my hypothesis is that -Os generates some instructions that Loongson 2E doesn’t like, as I normally don’t have any problems running MIPS I binaries… the thing that’s significantly different is -Os vs -O2.

Mar 122011
 

Well, it seems I might have µClibc stages going again, at least for little endian initially, then I might fire up one of the SGI boxes and see about a big-endian version.  For a long while, Gentoo/MIPS support for this lightweight C library was all but missing ever since an ABI change broke the µClibc port back around 2006.

I’ve tried on several occasions to build a new environment, and often I was met with technical difficulties which prevented me from producing a working environment.  Recently, I downloaded Rob Landley’s Aboriginal Linux distribution, both big and little endian variants, and took it for a spin.  Having done that, I’m pleased to report that I now have a µClibc chroot that’s merrily compiling various components of the Gentoo system, and will soon be sufficient to make a seed stage for bootstrapping the port once again.

This should mean new netboot images in the medium term for all little-endian ports (and proper ones too, not glibc-based hacks) and new images for SGI Indy (R4000) and O2.  In theory, support for Octane and Indigo2 R10000 is possible, however the systems I have are no longer functional, only my Indy and O2 still work, thus it’s impossible for me to test media for other systems.  Fingers crossed this initial build will go to plan, and we’ll have shiny new stages shortly.

Feb 172011
 

Hi all,

As promised I’ve put up some of the ebuilds needed to use the YubiKey in Gentoo.   This includes a PAM module for stand-alone authentication with the YubiKey, which I have patched to support concatenated two-factor authentication.  These are in a new overlay:

  • git://git.longlandclan.yi.org/overlays/yubikey.git
  • http://git.longlandclan.yi.org/git/overlays/yubikey.git

Stand-alone two factor authentication: Password + YubiKey with YubiPAM

The procedure for setting this up is pretty simple.  First, grab the overlay:

stuartl@beast /home/portage/overlays $ git clone git://git.longlandclan.yi.org/overlays/yubikey.git
Cloning into yubikey...
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 16 (delta 2), reused 16 (delta 2)
Receiving objects: 100% (16/16), 4.15 KiB, done.
Resolving deltas: 100% (2/2), done.

Now add it to your make.conf as per usual procedure, then unmask and install YubiPAM and ykpers ebuilds.  At last check, you need the live git ebuild for ykpers and libyubikey if you use the latest revision (2.2) keys like those handed out at linux.conf.au.  For the PAM module, I recommend using the non-live version, although a live ebuild is there for the adventurous (I had buffer overflow glitches).

# ( echo =sys-auth/yubipam-1.1_beta1
> echo =sys-auth/ykpers-99999999
> echo =sys-auth/libyubikey-99999999 ) >> /etc/portage/package.keywords
# emerge ykpers yubipam

This will install some tools to personalise the YubiKey and the PAM module.  At this step it’s now time to program the YubiKey.  This will break its ability to be used on the Yubico servers until you upload a copy of your new AES key to their site (see below).

Choose your public and private IDs, then program with the following command.  The fixed parameter should be 6-8 bytes long in hexadecimal.  If you intend to use this on Yubico servers later, it must be 6 bytes long, and must begin with ff.

# ykpersonalize -ofixed=$( modhex -h ffeeddccbbaa ) -ouid=112233445566
Firmware version 2.2.2 Touch level 1283 Program sequence 3
Passphrase to create AES key:
     Type in a long string of gobbledegook with lots of random letters,
     numbers and punctuation (not like this!) to keep people guessing.
     This will seed the AES keygen.
fixed: m:vvuuttrrnnll
uid: h:112233445566
key: h:afaaaa6021303d90740579cd7fc4e87f
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags:
extended_flags:

At the bottom it asks whether you wish to program the key.  It didn’t here because in fact I had snuck in a little parameter which I haven’t shown here.  You’ll want to make a note of the parameters it tells you though, especially the generated key.

Once complete, you then need to tell YubiPAM about it:

# ykpasswd -a -c -f ffeeddccbbaa -k afaaaa6021303d90740579cd7fc4e87f  -p 112233445566 \
        --user stuartl -o vvuuttrrnnlllrgjglvnicujhnhhecfeitjureidlcer
Adding Yubikey entry for stuartl
Using public UID: ff ee dd cc bb aa
Using private UID: 11 22 33 44 55 66
Passcode: Completed successfully.

The last bit should be generated from the YubiKey itself, just type the rest in then press the button and it should add you after asking for a passcode (which can be different to your regular system password).  The final step is to set it up with PAM.  This I’m not 100% sure of, but I achieved working authentication by configuring my /etc/pam.d/system-auth as follows:

vk4mslp2 yubikey # cat /etc/pam.d/system-auth
auth            required        pam_env.so
auth            sufficient      pam_yubikey.so concat_two_factor
auth            required        pam_unix.so try_first_pass likeauth nullok

It should be noted; test the configuration in a new console session, do not log out or else you may lock yourself out.  There is a ykvalidate tool for testing, but it doesn’t seem to work properly with two-factor authentication.

The concat_two_factor parameter to pam_yubikey relies on a patch present in the ebuild, which I have sent up-stream, and is a work-around for (some would say, broken) PAM clients that do not support multiple Password fields such as KDM.

To log-in, type in your username.  In the password field, enter the passcode followed by a space, then tap the YubiKey to enter the OTP.  It should log you in.

Uploading the key to Yubico

First, a warning

The whole point of one-time password generators such as this, is to prevent someone intercepting your password and logging in to your systems.  If a one-time-password is captured, it’s useless because in the ideal case, all systems know it has already been used.  I say in the ideal case.  In this scenario, if you use the key on a public server, it is possible for someone to capture that OTP, and re-play it to the stand-alone system using YubiPAM to gain access.  They of course can only do this once, but that may be enough for them to make themselves at home.

With some care, you can reduce the risk of this … for instance making a point of gratuitously logging in to each system using the key immediately after using it on any of the systems is one way to try and manually synchronise the OTPs.  I’m giving this problem some thought, for my needs it isn’t such a big deal as it’s mostly for fun anyway, but this is a factor that must be considered when using the YubiKey (or any OTP device) in this manner.

How to

Go to https://upload.yubico.com/.  Enter the data as follows.

  • Your email address (needs no explanation)
  • The YubiKey’s serial number: printed on the back, 6 digit decimal code
  • YubiKey Prefix: This is also called the “fixed UID” and appears as the first 12 characters of the OTP.  It should be in modhex format.  In the above example, the prefix would be vvuuttrrnnll.
  • Internal identity: This is also called the “private UID”.  It should be in hexadecimal format.  In the above example, the internal identity would be 112233445566
  • AES Key: Again in hexadecimal… the key used in this example was afaaaa6021303d90740579cd7fc4e87f
  • Finally, an OTP from the device. Don’t fill this in yet.

Below this form there is a Capcha field to stop spambots.  Fill in the challenge and click the “I’m a human” button, and copy the text into the other box as it asks.  Now go back to the other form, click on the OTP field and press the YubiKey button.  You should then be able to test it on their demo server and use the key simultaneously on the web and your local systems.