3G dongle information has been removed from this page due to 3G being removed from the UK!

Note - installing a dongle

Inserting a SIM into a dongle

To insert a SIM into a Huawei 3G dongle, for example, you will need to have a large-size SIM, so do not pop out a small-size SIM from its enclosing card. You remove a SIM-carrier tray from the dongle, fit the SIM into the tray and reinsert it into the dongle.

4G/5G Fallback

Firebrick configuration is very flexible and allows internet access to fail-over through a variety of different ways. This could be via different ethernet routers (including mobile-data routers) or a USB dongle. By using a mobile-data with one or more FTTC/ADSL lines from AAISP you'll be able to fall back to using 3G in the case of the FTTC/ADSL going down - this includes routing of your public IPv4 blocks and IPv6 blocks (IPv6 via a tunnel)

Nowadays though (2024) An Ethernet mobile-data router is recommended over a USB dongle as ethernet routers would offer faster speeds (eg 5G where available) and easier configuration setup.

The FB2900 models has a USB port that can be used with a 4G dongle for connectivity and/or fallback. Note: 4G dongles and some ethernet devices may have a problem with routing public IPs to the FireBrick as they act as a NAT device. In these cases using a L2TP tunnel will enable the IPs to be routed.

Working 4G Dongles

• ZTE 823 (O2 branding, or direct from Amazon etc work) — this dongle appears to work "out of the box" for failover, but needs specific configuration if you want to route your IP blocks through it. The FireBrick will get an IP address via DHCP from the dongle, eg 192.168.8.100
• Huawei E3372 - cheaper than the ZTE MF823, available from Amazon and others. In ethernet mode (its default) it works with a factory FireBrick configuration once a USB Interface has been added. The FireBrick will get an IP address via DHCP from the dongle, eg 192.168.8.100 - If using an A&A SIM, be sure to set the APN in the dongle, ie via http://192.168.8.1 - Settings - Profile Management - New Profile. (Re-tested November 2019)

Interface for 4G Dongles

A 4G dongle will usually work as an ethernet device, and so the FireBrick will need an interface on the IUSB port, set as a DHCP client. If your config doesn't have an Interface already, then add one such as:

   <interface name="Dongle" port="USB" graph="Dongle">
      <subnet name="DHCP Client" nat="true" comment="Dongle"/>
   </interface>

Unknown or not yet working

• Huawei E3272 LTE Surf-Stick
• Huawei E3276S-920
• Alcatel One-touch L850
• Alcatel One-Touch 800 (Does not work, seems to only support RNDIS Interface which FireBrick does not support)

Many 4G LTE dongles work by acting as an Ethernet device and perform NAT between the mobile network and the interface presented to the FireBrick. These types of dongles should work OK. If your A&A IP blocks need to be routed to the FireBrick whilst on 4G then using L2TP would be a way to achieve this. We’ll be expanding this section with more details and information as we test further dongles.

A Note on Bonding 4G LTE SIMs

Multiple mobile data routers could be used for bonding (eg session-based NAT), however the benefits of bonding multiple SIMs are small, as you’ll typically be contending with yourself and so there will be little or no added bandwidth. Using multiple dongles with SIMs from different providers may provide extra resilience in the case of one having a problem.

Basic Config

If you have an AAISP data SIM, the FireBrick can be configured to use this as a backup connection, by using a dongle plugged into the USB port or by using an mobile-data ethernet router. The example below is all you need to get the dongle configured. If your main broadband connection goes down, the FireBrick will automatically switch to use the 3G connection, then back again once your main connection is back.

<usb>
<dongle username="me@a.2" password="secret"/>
</usb>

Tunneled IPv6 Fallback

If using AAISP, then the options for IPv6 routing on the Control Pages allow an IPv6 block to be routed to a tunnel endpoint if the main routing (i.e. ADSL/FTTC) goes down. This means IPv6 can be routed to the 3G dongle if the main broadband(s) go down. The MTU will be limited though. For more configuration options see FireBrick 2700 Configuration.

Example Config

LAN Interface for IPv6 tunnel over 3G dongle (with MTU 1500):

<interface name="LAN" port="LAN" ra-client="false">
<subnet ip="2001:8b0::1/64 10.0.0.1/24" ra="true" ra-mtu="1480" ra-dns="2001:8b0::2020 2001:8b0::2021"/>
</interface>

LAN Interface for IPv6 tunnel over 3G dongle (with MTU 1492):

<interface name="LAN" port="LAN" ra-client="false">
<subnet ip="2001:8b0::1/64 10.0.0.1/24" ra="true" ra-mtu="1472" ra-dns="2001:8b0::2020 2001:8b0::2021"/>
</interface>

Connect to AAISP over PPPoE session (3G dongle tweaks and NAT):

<ppp name="AAISP" port="WAN" username="me@a.1" password="secret" nat="true" lcp-rate="1" lcp-timeout="5" graph="AAISP" log="default"/>

Connect to AAISP over 3G dongle (with NAT):

<dongle name="AAISP-3G" username="me@a.2" password="secret" nat="true" graph="AAISP-3G" log="default"/>

3G dongle IPv6 default route using IPv4 tunnel:

<route ip="::/0" gateway="81.187.81.6" comment="IPv6 default route using IPv4 tunnel"/>

Configuration and testing

When you plug a usb dongle into the Firebrick, to test if it is working you can use the CLI ‘show dongle’ command in a Telnet session. However, unfortunately this command fails to detect the dongle if <usb> and <dongle> elements have not been added to the XML configuration file. You can at first just add the following to the XML by using the web UI of the Firebrick, under Config > XML Edit:

 <usb>
      <dongle name="AA" />
 </usb>

If you prefer not edit the XML, then you can make the change by using the web UI commands Config > Edit choose ‘Interface’ and then ‘USB and 3G/dongle settings’. Drill down until you see whole lot of options in a number of ‘3G/dongle config settings’ fields. Set the option fields appropriately, at a minimum fill in the ‘Name’ field, and then hit ‘Save’. This will add the <usb> and <dongle> elements for you in the XML configuration.

Following the application of either of these two alternative methods, the CLI ‘show dongle’ command will now work and will detect the presence of the dongle. You will need to fit an appropriate SIM into the dongle. The result will be something like the following:

With no SIM:

 > show dongle
 
 Attached USB devices
 --------------------
 Socket  Vendor Product Name   Functions
 1         12d1 1003/1003 AA   3G(AT-ppp) 
 You do not have any 3G/ppp sessions
 You do not have any 4G/eth sessions

And with a 3G SIM installed:

 > show dongle
 
 Attached USB devices
 --------------------
 Socket  Vendor Product Name   Functions
 1         12d1 1003/1003 Dongle-AA Memory-stick 3G(AT-ppp) 
 
 3G/PPP Dongle Sessions
 ----------------------
 Socket    T Name       MTU Status
 1         0 Dongle-AA 1440 Up           tcp-fix
 You do not have any 4G/eth sessions

Turning the dongle off outside of office hours

Sometimes we don't want the dongle to be online 24x7 and want it turned off outside of office hours. This example brings the dongle online for quick fallback during office hours, and leaves it powered up but disconnected. Fallback still works outside of office hours but takes a few seconds longer to set up. Note that both <usb> and <dongle> elements can be conditional, based on profiles. Leaving <usb> active but disabling <dongle> will leave the dongle powered up but disconnected. Disabling <usb> will physically turn off the USB port and therefore also the dongle. Cold starts take a lot longer!

<usb>
<dongle name="AAISP-3G" username="me@a.3" password="secret" graph="AAISP-3G" profile="AAISP-3G"/>
</usb>

<profile name="Office-Hours" comment="Office hours">
<time days="Mon Tue Wed Thu Fri" start="08:00:00" stop="18:00:00"/>
</profile>

<profile name="No-DSL" ppp="ADSL1 ADSL2" invert="true"/>
<profile name="AAISP-3G" or="Office-Hours No-DSL" comment="Backup active during office hours, or if there is no DSL outside of office hours"/>

This example is taken from a site which has 2 ADSL lines - hence the No-DSL profile being based on ADSL1 and ADSL2 being up. The AAISP-3G profile is then active during office hours, but it will become active if both of the ADSL lines are down outside of office hours.

Ping test example of falling back

Here we ping an IP on the LAN, behind the FB2700, and get the ADSL router to re-sync. The ADSL went down, the 3G kicked in with only a single ping lost, then shortly after the ADSL came back on and took over the routing again.

64 bytes from 81.187.xx.xxx: icmp_req=120 ttl=57 time=17.6 ms
64 bytes from 81.187.xx.xxx: icmp_req=121 ttl=57 time=18.1 ms
64 bytes from 81.187.xx.xxx: icmp_req=122 ttl=57 time=17.0 ms
64 bytes from 81.187.xx.xxx: icmp_req=123 ttl=57 time=20.4 ms
64 bytes from 81.187.xx.xxx: icmp_req=124 ttl=57 time=17.3 ms
64 bytes from 81.187.xx.xxx: icmp_req=125 ttl=57 time=17.2 ms
64 bytes from 81.187.xx.xxx: icmp_req=126 ttl=57 time=17.3 ms
From 90.155.53.12 icmp_seq=132 Time to live exceeded
64 bytes from 81.187.xx.xxx: icmp_req=133 ttl=57 time=792 ms <- Now on 3G
64 bytes from 81.187.xx.xxx: icmp_req=134 ttl=57 time=291 ms
64 bytes from 81.187.xx.xxx: icmp_req=135 ttl=57 time=451 ms
64 bytes from 81.187.xx.xxx: icmp_req=136 ttl=57 time=426 ms
64 bytes from 81.187.xx.xxx: icmp_req=137 ttl=57 time=338 ms

Some successful pings omitted as it took a while to sync again.

64 bytes from 81.187.xx.xxx: icmp_req=180 ttl=57 time=176 ms
64 bytes from 81.187.xx.xxx: icmp_req=181 ttl=57 time=276 ms
64 bytes from 81.187.xx.xxx: icmp_req=182 ttl=57 time=216 ms
64 bytes from 81.187.xx.xxx: icmp_req=183 ttl=57 time=174 ms
64 bytes from 81.187.xx.xxx: icmp_req=184 ttl=57 time=212 ms
64 bytes from 81.187.xx.xxx: icmp_req=187 ttl=57 time=16.3 ms  <- Now back on ADSL!
64 bytes from 81.187.xx.xxx: icmp_req=188 ttl=57 time=16.5 ms
64 bytes from 81.187.xx.xxx: icmp_req=189 ttl=57 time=16.2 ms
64 bytes from 81.187.xx.xxx: icmp_req=190 ttl=57 time=16.5 ms
64 bytes from 81.187.xx.xxx: icmp_req=191 ttl=57 time=16.6 ms
64 bytes from 81.187.xx.xxx: icmp_req=192 ttl=57 time=16.0 ms
64 bytes from 81.187.xx.xxx: icmp_req=193 ttl=57 time=16.8 ms

You can tell when the swap over happened as the latency increases and then decreases again when the DSL came back online.

Telnet Commands

Reset the USB controller and re-detect everything from scratch:

clear usb

Show dongle information:

show dongle