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/
Inga kommentarer:
Skicka en kommentar