Computers & Hardware > Other Technologies & Hardware
New 4G USB ‘dongle’ i/f
Weaver:
AA have sent me a new 4G dongle free and a new SIM for my Firebrick. I was moaning about occasional failures of the 3G one that I currently have, which AA supplied. Both are Huawei but I can’t remember the model numbers; the new one might be a 3372. See also :
https://support.aa.net.uk/Category:FireBrick_USB_Dongles
Superb service, that they just swapped it out for free when they couldn’t reproduce the rare ‘disappearances’ of the 3G dongle that I had seen every few months. And after all, they might never see the badness happen, because their network is different: signal strength different and god knows what. So how long do you wait.
I haven’t installed the 4G one yet. I will need to add something to the FB2900 XML config because the new dongle has an ethernet i/f with DHCP, as opposed to the 3G one which speaks PPP. See above URL.
I don’t really understand the remarks about NAT and the 4G dongle. I understand the the Firebrick will get some IPv4 address from the dongle by DHCP. Still doesn’t speak IPv6 >:( :( ??? I’m assuming this is AQL or Three’s fault. What is the NAT thing all about? Will the 4G dongle mangle all the source IPv4 addresses of the hosts on my LAN when they go out onto the internet? All of my LAN IPv4 range is routed through the dongle (secondarily, on a fallback basis) to my LAN so I want the real global routable existing IPv4 addresses of the hosts to go out to the internet unmolested.
burakkucat:
My interpretation, having looked at the link you provided, is that the 4G dongle is a DHCP server and it will hand out an IPv4 address to the connected Firebrick.
But . . . I'm confused. ???
Weaver:
Do we think it is a NAT translator too? Or is it just the FB being a NAT translator, for some reason ?
This because it shows nat="true" in the FB XML example on the website (URL given above). I have emailed AA tech support to ask for confirmation about the ‘nat’ attribute as if I can I would obviously want to avoid it as I don’t want NATing. Perhaps that example just presumed that the AA user only had one IPv4 address for their whole LAN and that was the only reason for it, because one IPv4 is the AA default unless you ask for more addresses, which are free of charge. I have explicitly put nat="false" on the ‘dongle’ element currently as I believe the default is ‘true’ iirc.
One IPv4 address is allocated to the new SIM by AA, and the existing /26 is already secondarily (backup) routed to the new dongle, ie when all DSL lines go down as detected by AA’s PPP LCP pinging then they re-route traffic to the secondary route which is through the two dongles (new and old) whichever is up. I set that up by ticking the appropriate flag check-boxes in clueless.aa.net.uk.
Alex Atkin UK:
I believe the dongles may indeed do NAT in certain modes, though not sure why as it seems completely unnecessary as they could simply bridge.
There does seem to be a few different protocols they can use though RNDIS is probably default, thus the virtual NIC and DHCP. I think ACM mode requires a completely different firmware on the dongle, although you'd think AA might apply that considering?
Weaver:
I’m getting AA to check out my proposed FB XML config before I try the device.
One of the superb things about having readable XML or similar in config files, as I’ve said before - you can diff it, edit it and email it to someone for perusal. And you can process it. I have written a tool to prep it too, with #ifdef-like commands within significant comments.
MTU: I’m changing MTU for IPv6 compared to that with the 3G one, which was 1408 bytes: have added 48 to that to bring it up to 1408+48=1456 which is (n * 48 - 32) as before, for ATM full efficiency, the 32 because 32 bytes is the total ADSL protocol stack overhead, as before. This figure is less than the 4G MTU which is 1500 and less than 1500 - 20 = 1480 which is the MTU with the IPv6-over-IPv4 tunnel overhead subtracted because since before there’s no IPv6 support, we have to use AA’s tunnel for IPv6 traffic during failover-to-4G mode.
I can’t use the next multiple of n, because n * 48 - 32 is too large, since with n=32 : (n=32) * 48 bytes - (ovh = 32 ) = 1504 bytes which is > (1500 - 20)
Navigation
[0] Message Index
[#] Next page
Go to full version