lördag 23 mars 2013

Using ADSL and 3G concurrently

ADSL has its limitations but is, at least, ubiquitously available and comes with flat-rate. 3G subscriptions are usually only flat-rate up to a threshold of so and so many GB, over which you have to pay extra. But a cheap 3G subscription is a good backup against ADSL outages. Of course, both of them have the drawback of asymmetrically lower upstream bandwidths compared to the downstream speed.     

Thus, when you have a lot of data to upload (for instance after an extensive photo-session) you might very well want to concurrently upload on both types of network connections to keep the overall upload time down.

This is one recipe on how to achieve that (you will have to adopt to your own IP addresses and connection types below):

  • Connect 3G dongle and initiate the connection on it
  • Check your particulars:
$ ifconfig 
eth1      Link encap:Ethernet  HWaddr c8:0a:a9:a6:5f:c1  
          inet addr:192.168.1.150  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::ca0a:a9ff:fea6:5fc1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:90315 errors:0 dropped:0 overruns:0 frame:0
          TX packets:51128 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:122726916 (122.7 MB)  TX bytes:5513301 (5.5 MB)
          Interrupt:42 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1356 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1356 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:239907 (239.9 KB)  TX bytes:239907 (239.9 KB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:83.180.203.199  P-t-P:10.64.64.64  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:130 (130.0 B)  TX bytes:181 (181.0 B)
  • Add a routing table for the 3g: 
# sudo echo 2 3g >> /etc/iproute2/rt_tables
  • Add to and fro routes for the 3G connection to the new table (my 3G gives me a ppp0 interface). Notice the priority of 1000, chosen to lie in between 0 and 32766:
# ip route add default via 83.180.203.199 dev ppp0 table 3g
# ip rule add from 83.180.203.199 table 3g prio 1000
  • Check what you've got: 
$ ip route show table 3g
default via 83.180.203.199 dev ppp0 
  •  And your complete routing rules:
$ ip rule
0: from all lookup local 
1000: from 83.180.203.199 lookup 3g 
32766: from all lookup main 
32767: from all lookup default 
  •  Now you can use the 3G interface concurrently with your normal network (without packet in one direction getting confused and ending up where not intended). You can, for instance, verify it by ssh:ing out on the 3G interface with  ssh -b 83.180.203.199 <some machine> and on that machine, you can verify where you're actually coming from with, for instance, w. You probably don't have wired and mobile internet from the same provider, so it should be easy to tell them apart.
  •  But what about the concurrent uploads, then? Well, I use  (in different terminals, of course):
$ rsync -e 'ssh -b 83.180.203.199' --progress -ha Pictures/2013-03* <remote-machine>:Pictures/
$ 'rsync -e 'ssh -b 192.168.1.150' --progress -ha Pictures/2013-02* <remote-machine>:Pictures/

Naturally, I would get better network utalization if I uploaded huge tar-balls of the content than rsync:ing perhaps many small files - however, I'm after rsync's capability to determine exactly what's new and needs to be uploaded and what's already there.

Also, a common use-case is, of course, to just upload the latest, massive folder of photos. Then you can use a little bash-fu to make each concurrent connection upload different files - for instance on the one the odd and on the other the even numbered photos:

$ rsync -e 'ssh -b 83.180.203.199' --progress -ha Pictures/2013-03-23/*{1,3,5,7,9}.jpg <remote-machine>:Pictures/2013-03-23/
$ 'rsync -e 'ssh -b 192.168.1.150' --progress -ha Pictures/2013-03-23/*{0,2,4,6,8}.jpg <remote-machine>:Pictures/2013-03-23/




onsdag 20 mars 2013

Screen as a serial console software

How cool is that? Old, honest screen can actually be used to connect to a serial console. Typically, you nowadays have some fancy usb-to-serier converter and when you connect the usb, you'll probably find the right tty with

$ dmesg | grep ttyUSB
[1384486.485394] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB3

Then you can use screen to access the serial console (it's good to know the Baud rate, too):

$ screen /dev/ttyUSB3 115200

Neat!

(And, yeah, screen is old and the code-base is not maintained, so one should really migrate to tmux some day.)