SoeKris

back to http://scratchpad.wikia.com/wiki/Sasecurity

hardware key
> We succeeded in building boxes with soekris boards with some adaptation > as this one is not based with Compact falsh but NOR or NAN memories. > You'll need to boot on a PXE with a Linux or BSD kernel then you'll need > to dd the locust distro on the memory.

little rectification : Jeremy and I (same company) are using net4826 (128mb ram, 64mb hdd solded on the board, 2 mini-pci) soekris boards. the install is done by pxe-booting a minimal os which allow to mount /dev/hda, then you just dd the bflash file, like J. said.

After that, you have to tweak grub.conf to speed up the boot, compile a module fitting the geode hardware watchdog, and then you have a very robust box.

hd key
The ultrakey generation sucks bigtime and it should be changed. Ultrakey changes values on some embedded systems without anything being swapped out. So the first time you boot a meshbox you just do ultrakey > /hj/mykey and then you replace the contents of ultrakey by:

* #!/bin/sh * cat /hj/mykey

That's all. Works great. I reported this problem in february to LW while playing with a Soekris, but of course nothing happened.

>Many of the "my meshAP won't check in anymore" problems are the result of >the hardware key no longer being what it used to be when the unit was first >registered at wiana. This happens because the hardware key is recalculated >on-the-fly every time the meshbox reboots, and if anything goes wrong during >that process (which we have occasionally seen even if none of the network >hardware or CF components are swapped out) your hardware key is suddenly >diferent. > >However this problem is relatively easy to fix. Our Qnode embedded web >interface has a provision for hardware key maintenance which makes the CF >system independent (that is you can move it to any meshAP and it retains its >identity and key). However, you can create the same result by adding a file >by hand as follows: > >SSH into the meshAP and type this command: >hardwarekey >/etc/HARDWAREKEY > >Then, in > >/hj/hardwarekey, > >replace the old script with the one below.

>#!/bin/sh >PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin" > >if [ -f /etc/HARDWAREKEY ] >then >   if [ "`cat /etc/HARDWAREKEY`" != "`cat /tmp/work/ultrakey.cache`" ] >   then >       cat /etc/HARDWAREKEY >/tmp/work/ultrakey.cache >   fi >    cat /tmp/work/ultrakey.cache >else >   a=`ifconfig | grep HWaddr | grep -v '^br' | head -1` >   a="$a`ide_info /dev/hda``head /proc/cpuinfo | grep -v MHz`" >   m=`echo "$a" | md5sum | tr -dc '0-9a-f'` >   echo -n "$m" >   echo -n "$m" >/etc/HARDWAREKEY >   echo -n "$m" >/tmp/work/ultrakey.cache >fi

Once this is in place, if for some reason you want to change the hardware >key, just edit /etc/HARDWAREKEY

>IMPORTANT NOTE: If you reflash the system you will need to redo this >process, as the new version of the LW code will delete the /etc/HARDWAREKEY >and modified /hj/hardwarekey files.

>The wiana problem was fixed earlier by doing a factoryreset >Everything looks good now, ahhhhh :) > >I've moved the meshbox with 2 radio cards in to the loft (it was previously >sat on top of the gateway meshbox) in the workshop. > >So presently its running in the configuration it will be in when I site it >remotely. >I'm able to connect in with a laptop to 3 interfaces in total, all seem to >work and challenge me with the portal >page. >I'm unable to login to this page as a realm 'owner' for some reason? I seem >to recall this being mentioned last >week? The guest login works ok though.

>Forgot to send to the list (or to Mike, who needed it!) >>>There is no ethernet interface connected to this meshbox, however the IP >>>of eth0 is 192.168.1.2 which >>>is the same as a machine on my LAN?

>>Sounds like it could be the problem, depending on which machine >>responds first to the default gateway's ARP query for 192.168.1.2. >>Try changing this address in Wiana to another one on the same subnet >>that isn't currently in use.

>No this is a red herring - if there is no interface connected, then >it won't matter unless you are trying to access that ip from the >meshbox.

>>10.51.13.180@meshbox:~# remotemanagement >>Time cached >>RUN >> % Total    % Received % Xferd  Average Speed          Time >>Curr. >>                                Dload  Upload Total    Current  Left >>Speed >>100  167  100   167    0     0    345      0  0:00:00  0:00:00  0:00:00 >>0 >>Download okay >>Key exists >>RUN COMPLETE >>

>I've seen this a few times where there seems to be a lock between >wiana and the meshbox. The way to get around it is to delete >/etc/certs/local.*

>Then, reboot and recheck in to wiana.

>It should regenerate a key, and then check in again to download the >wiana settings.

>SSH into the meshAP and type this command:  >hardwarekey >/etc/HARDWAREKEY  Then, in 

>/hj/hardwarekey,  > >replace the old script with the one below.  >---  >#!/bin/sh  >PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin"  >if [ -f /etc/HARDWAREKEY ]   >then  >   if [ "`cat /etc/HARDWAREKEY`" != "`cat /tmp/work/ultrakey.cache`"]   >   then   

>       cat /etc/HARDWAREKEY >/tmp/work/ultrakey.cache    >   fi   >   cat /tmp/work/ultrakey.cache    >else  >   a=`ifconfig | grep HWaddr | grep -v '^br' | head -1`   <BR> >   a="$a`ide_info /dev/hda``head /proc/cpuinfo | grep -v MHz`"   <BR> >   m=`echo "$a" | md5sum | tr -dc '0-9a-f'`    <BR> >   echo -n "$m"    <BR> >   echo -n "$m" >/etc/HARDWAREKEY     <BR>

>   echo -n "$m" >/tmp/work/ultrakey.cache     <BR> >fi    <BR> <BR> >Once this is in place, if for some reason you want to change the   <BR> hardware >key, just edit /etc/HARDWAREKEY <BR>  <BR> >>IMPORTANT NOTE: If you reflash the system you will need to redo this <BR> process, as the new version of the LW code will delete the   <BR> /etc/HARDWAREKEY and modified /hj/hardwarekey files. <BR> <BR>