multi dhcp range on Untangel / Vodafone Sure Signal

 

So this evening on my way home from work I purchased a 'Vodafone Sure Signal' unit to sort out the phone signal coverage problem I have for Vodafone.

Upon reading through the manual it turns out that the Sure Signal configures itself from what Vodafone tell it when it connects to them over the web and then all management of the device is done via the Vodafone website, no mention is made to any local management portal for the device (I'll have a look and see if there is one some other time).

Having seen this, I though it best to put it on its own network segment away from everything else (network monkey anyone ?? (hak 5 reference )), probably over cautious of me but better safe than sorry hmm + it gives me chance to practice setting up things for when I add a guest WiFi lan later.

That decided I looked for how to set up the extra dhcp ranges and firewall rules, that lead me to this page on the Untangle site. That nearly completely sorted things for me but I found out that just doing that is not enough.

First, the 'dhcp-range=192.168.5.10.....' commands must come first in the custom DHCP/DNS config field.

Second, the interfaces you want to use for the new dhcp ranges must be configured to match their static IPs to the dhcp ranges
ie. for dhcp range 10.55.1.100-250 the interface's IP needs to be manually set to a compatible address eg. 10.55.1.1 , as this does not happen automatically when you specify the dhcp range.
Also the NAT Policies need the line 0.0.0.0 / 0 adding you do this by just clicking the add button for that section and leaving the result alone (see image below)

Ubuntu touch (Saucy Salamander)

Ubuntu touch (Saucy Salamander) is getting ever closer to being a fully featured phone/tablet OS.

Currently the phablet tools (you can get them here https://wiki.ubuntu.com/Touch/Install) are not working for 'Saucy' installs. you just get a 404 error on the download phase. (correct as of 11 pm (GMT) 24 Jul 2013).
However this is not a huge problem as (if you have already bootstrapped the device) you can install the 'Saucy' update manually.

Note. Need I say that you do this install entirely at you own risk and by following this post you agree to hold both myself and the people at Ubuntu totally blameless for what ever happens

First run the 'phablet-flash' command from a root level terminal on your Ubuntu pc, this (though it fails to do the install) will give you the device type.

That done you need to download the right images for your device type (you can get them here). The two bits you need are the 'saucy-preinstalled-touch-armel+XYZ.zip' (where XYZ is the device type ie. saucy-preinstalled-touch-armel+maguro.zip) and 'saucy-preinstalled-touch-armhf.zip'

The next thing to do is to get the device specific bit installed, to do this boot the device into recovery mode using 'adb reboot recovery'.
Then push the device spresific bit over to the phone/tablet with the command 'adb push   ./saucy-preinstalled-touch-armel+XYZ.zip /sdcard/autodeploy.zip ' (assuming you are running the adb command from the directory you downloaded the .zip files to)

The device now needs to be rebooted into recovery mode again to install the image, so issue the 'adb reboot recovery' command, this will cause the phone/tablet to reboot and show the 'installing android' animation and progress bar. (
When this is done you may need to put the phone/tablet back into recovery mode manually using the device's specific hardware button combo, before moving onto the next step (this happened to me on the nexus 7))

Now back in the recovery mode on the device its time to push the main OS payload over so issue 'adb push   ./saucy-preinstalled-touch-armhf.zip /sdcard/autodeploy.zip' (again assuming you are running the adb command from the directory you downloaded the .zip files to).

Now to finish up issue the 'adb reboot recovery' command one last time, this will cause the phone/tablet to reboot and show the 'installing android' animation and progress bar again, but this time it will take longer to complete, so sit back and let it do its stuff.

Once the install is complete, the device will restart all on its own and after a couple of moments will show the Ubuntu touch interface.

Congrats you're ready to go.

Remember. To turn off the device you have to use the 'sudo poweroff now' command from the terminal app as the power off buttons have yet to be implemented (but you have to remember this is beta software that gets daily changes/upgrades)

Its worth noting that the normal Ubuntu command line update commands 'apt-get update and apt-get upgrade' can be used from the terminal app to provide on-the-go updates right over the WiFi strait to the phone/tablet, no pc required  

dd where are you upto ?

Just wanted to copy a USB drive to another one this evening (due to upgrading a USB 3.0 unit) and found the dd was taking quite a while (due to the USB 2.0 stick it was coming off, that and the fact the drives were 32GB) and so I looked for a way to see what dd was doing.

It turns out that to get dd to spit out its state you have to do a special trick with the kill command (usually used to stop un-responsive/runaway processes).

---

To get the info you will need two terminal windows (or you could use screen to hold the dd process).
In one terminal session start the dd process ie. dd if=/dev/sdX of=/dev/sdY.

Then in the other terminal session do this;
Lookup the process id of dd by doing typing in

pgrep -l '^dd$

This will net you the process id of dd, now put the process id in the following command (in this example I got "3479 dd" as the output of "pgrep -l '^dd$")
then type in

kill -USR1 3479

don't miss the -USR1 bit or you will kill the dd session.

each time you use the above command it causes dd to spit out its status into its running terminal session (that's the one you ran dd in at the start of this process), so switch over and have a look, you should see somthing like this

shadow@webX$ sudo dd if=/dev/sdX of=/dev/sdY
0+14 records in
0+14 records out
204 bytes (204 B) copied, 24.92 seconds, 0.0 kB/s

just hop back to the other terminal session and run the kill -USR1 ... command again each time you want to see where its up to