SoeKris

Category:Sasecurity
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: <BR>
>hardwarekey >/etc/HARDWAREKEY <BR>
Then, in <BR>
>/hj/hardwarekey, <BR>
> >replace the old script with the one below. <BR>
>------------------------------------------- <BR> 
>#!/bin/sh <BR>
>PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin" <BR>
>if [ -f /etc/HARDWAREKEY ] <BR>
>then <BR>
> if [ "`cat /etc/HARDWAREKEY`" != "`cat /tmp/work/ultrakey.cache`"] <BR>
> then <BR>
> cat /etc/HARDWAREKEY >/tmp/work/ultrakey.cache <BR>
> fi <BR>
> cat /tmp/work/ultrakey.cache <BR>
>else <BR>
> 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>
Category:Mesh