Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: Firebrick FB2700 3G dongle  (Read 3588 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Firebrick FB2700 3G dongle
« on: October 23, 2018, 05:00:21 PM »

Has anyone got a 3G or 4G dongle working with a Firebrick?

I can’t seem to get much joy 3G dongle with my Firebrick FB2700. The Brick sees the dongle - it detects it, shows it in dongle status in the web UI.

I don’t know what I am supposed to be seeing, nor how to test whether or not it is actually making a link.

In AA clueless, the ‘line’ for the 3G SIM in the graphs displays is shown as orange, not green. I’m assuming that means it isn’t working. Either that or it is not yet in the 3G-failover state, and is normal. The problem is that I don’t know what normal is supposed to look like.

I am not sure that it is the correct SIM even. I talked to AA about which SIM is which and we decided on a particular one, but I don’t know how to identify it for certain. So I am wondering if I have perhaps activated the wrong one.

I suppose I could just order another SIM, then I will be certain that it is the ‘right one’ in the sense that I will know that it matches the one I am looking at in clueless.
Logged

jelv

  • Helpful
  • Kitizen
  • *
  • Posts: 2054
Re: Firebrick FB2700 3G dongle
« Reply #1 on: October 23, 2018, 05:29:58 PM »

Surely you could plug the dongle in to a PC/laptop to test it?
Logged
Broadband and Line rental: Zen Unlimited Fibre 2, Mobile: Vodaphone
Router: Fritz!Box 7530

vic0239

  • Reg Member
  • ***
  • Posts: 519
Re: Firebrick FB2700 3G dongle
« Reply #2 on: October 23, 2018, 05:41:56 PM »

I have a "Three UK Data only mobile SIM card" from AAISP which I have suspended at the moment. I found it a little unreliable, dropping the connection quite regularly. When it was working the fail-over was quite reliable and after a short interval my connection resumed on the 3g network without issue. It may have been a signal strength issue as I don't get many 'bars' on my phone. When it was working it showed up in Status/Dongle as an active session.

I have the following entries in the FB config:

Code: [Select]
<port name="USB"
       ports=""
       dongle="MyDongle"/>

</interface>
 <interface name="USB"
            port="USB"
            ra-client="true"
            comment="Default USB interface">
  <subnet name="DHCP client"/>
 </interface>

 <usb log="default"
      log-error="default">
  <dongle name="MyDongle"
          apn="m2m.aql.net"
          username="xxxxxxxx@a.3"
          password="AxxxByyyCzzz"/>
 </usb>

I also have a 4g dongle which worked pretty much as described in the AA pages allocating an IP address NATed. I did try the palaver of configuring it in 'serial mode' which crashed the connection unfortunately. I didn't attempt the IPv6 tunnelling.
Logged
Lothian Broadband 900/900 + AAISP VDSL, Vigor2865Vac, MikroTik rb260gsp, ZyXel NWA50AX WiFi AP.

vic0239

  • Reg Member
  • ***
  • Posts: 519
Re: Firebrick FB2700 3G dongle
« Reply #3 on: October 23, 2018, 05:53:53 PM »

Also this appears in the FB log:

Code: [Select]
2018-03-04T09:24:51.499974Z USB Socket 1 connected - vendor:product 12d1:1003
2018-03-04T09:24:51.505989Z usb-man Socket 1 comms opened: in 2 out 1 int 1
2018-03-04T09:24:51.958032Z usb-ppp Socket 1 3G/ppp ready Huawei3
2018-03-04T09:25:05.143794Z usb-ppp Socket 1 3G/ppp connected 81.n.nnn.nnn
Logged
Lothian Broadband 900/900 + AAISP VDSL, Vigor2865Vac, MikroTik rb260gsp, ZyXel NWA50AX WiFi AP.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick FB2700 3G dongle
« Reply #4 on: October 23, 2018, 06:11:11 PM »

Thanks very much indeed, gives me something to look for.

After talking with a few other users, I am now wondering if we have put a tiny SIM into an enormous removable tray. Hence the bewilderment about the seeming unsuitability of the tray because there was no restraint of the tiny SIM’s position. All there was to be seen was a small outline on the flat surface of the SIM carrier. My wife had popped out the smallest possible SIM from its packaging first, before we went on the look at the dongle. So I am wondering if we needed a larger SIM all the time.

Perhaps the SIM is not even working in the dongle at all anyway. I don’t know if we have any evidence one way or the other, as I don’t know how to test whether or not the dongle is seeing the SIM.

Is it possible that I could get a large SIM which fills the removable carrier completely? (By not popping the smallest surrounding SIMS outline out in the plastic SIM holder card that it comes in?) in fact, this picture might support this theory.)

The dongle section in status in the web UI shows:

Attached USB devices
Socket   1
Vendor code   12d1
Product code   1003
dongle config name   AA
Recognized device functions   3G(AT-ppp)
Device descriptor info:
Vendor:product 12d1:1003 (HUAWEI Technology/HUAWEI Mobile), serial
USB spec 2.00 class/sub/proto 0/0/0, maxpacket0 64,  release 0.00; 1 configurations(s)
Config #1: (Qualcomm Configuration) interfaces 2, self powered, remote wakeup, power 500mA
  Interface 0 () alt 0: endpoints 2, class/sub/proto 255/0/0
    Endpoint 1: IN bulk, maxpkt 512, mult 1, interval 32
    Endpoint 1: OUT bulk, maxpkt 512, mult 1, interval 32
  Interface 1 () alt 0: endpoints 2, class/sub/proto 255/0/0
    Endpoint 2: IN bulk, maxpkt 512, mult 1, interval 32
    Endpoint 2: OUT bulk, maxpkt 512, mult 1, interval 32


I don’t know if that tells us anything about SIMs.

I have ordered another SIM from AA anyway.
« Last Edit: October 23, 2018, 06:13:19 PM by Weaver »
Logged

dee.jay

  • ISP Rep
  • Reg Member
  • *
  • Posts: 953
Re: Firebrick FB2700 3G dongle
« Reply #5 on: October 23, 2018, 06:37:50 PM »

Was the small sim part of a bigger "cutout"? You can simply put it back in and use it as a larger SIM again?

Maybe I missed something in your description, though.
Logged
Starlink and AAISP L2TP combo routed by opnSense on proxmox

jelv

  • Helpful
  • Kitizen
  • *
  • Posts: 2054
Re: Firebrick FB2700 3G dongle
« Reply #6 on: October 23, 2018, 07:11:56 PM »

I have a ZTE MF730M dongle with an id Mobile SIM (on the Three network) which I use with my W10 laptop.

It takes a full size SIM. Have you still got the card you popped the micro SIM out of? I have successfully put a SIM back in to the larger size when swapping it to a phone that needed a larger one than the phone I took it out of. Otherwise when you slide it in to the holder you are going to have to be careful how you position it.
Edit: It takes the one on the left - I presume you have the one on the right.
« Last Edit: October 23, 2018, 07:25:11 PM by jelv »
Logged
Broadband and Line rental: Zen Unlimited Fibre 2, Mobile: Vodaphone
Router: Fritz!Box 7530

dee.jay

  • ISP Rep
  • Reg Member
  • *
  • Posts: 953
Re: Firebrick FB2700 3G dongle
« Reply #7 on: October 23, 2018, 07:30:33 PM »

^^ That explains what I meant much more clearly!
Logged
Starlink and AAISP L2TP combo routed by opnSense on proxmox

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick FB2700 3G dongle
« Reply #8 on: October 24, 2018, 04:10:07 AM »

This is correct, I think. Icoukd not see because my eyesight is hopeless, but I think your picture is correct. I doubt my wife kept the outer bit tho and she would not relish the thought of a hunt for it. That’s why I just ordered another SIM. This has been extremely helpful - thanks to all for pics etc
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick FB2700 3G dongle
« Reply #9 on: October 30, 2018, 03:26:29 AM »

A new SIM arrived. My wife having now understood the size issue fitted a large-pop out SIM into the removable SIM-carrier tray of the dongle and it filled it and fitted correctly. Straight away the Firebrick showed a PPP connection.

A lot of faffing about ensued.

1. I had to change a few things in clueless, having not got the routing—of-IPs-to-links tickboxes set correctly.

2. I also realised that I needed to make sure that I handed the dongle one IPv4 address for its local endpoint all the time to make it feel happy during ppp setup. This needed to be a full time thing, it was not just fired up when it was time for failover, it gets fired up when the Firebrick boots. This slows down the Firebrick’s lightning fast boot time by a few seconds.

There were also various things that turned out to be absolutely essential in the Firebrick XML config examples, and you can’t tell from the documentation what is essential and concerned with dongles and what is just accidental stuff which is a random part of the scenario depicted. Why some of these things are essential is a total mystery. I would like to fix the documentation if I knew what was going on.

4. XML config needed nat="false" on the dongle element, which is a non-default, otherwise, err, it does nat and mucks up all the source IPv4 addresses of your clients on your LAN. Well, who knew. Luckily woke up to things and fixed it, as of course it still worked either way, but it introduced a subtle bug in that my identity was wrong and wouldn’t match firewall ‘allow’ rules since it had altered my own iPad’s (say) IPv4 source address.

5. MTU of the dongle is only 1440 ! This is insane. It is advertised as 1500. Not happy. I noticed the same thing with the AA 3G SIM in my iPad itself. I ought to check Janet’s iPad’s AA 3G SIM as this is much older, in case this is something to do with a new batch.

To get IPv6 working unfortunately you have to use 6in4 proto 41 tunnelling which the Firebrick and AA’s routers can take care of. A mysterious command somehow activated the tunnel only when it is needed, during failover. A <route ip="::/0" gateway="81.187.81.6" /> is the magic incantation, but how does it know to involve the dongle? And how does it know to only do the tunnelling thing during the normal, non-failover state?

6. It turns out to be essential to reduce the main MTU to make tunnelled IPv6 work. Thinking about it, it’s not too surprising, since there is no option to fragment things at an intermediate router in IPv6, so just letting the Brick fragment IPv6 after failover is impossible. So this needed to be fixed. Since the 3G MTU is ridiculously low for some reason, I needed to pick a main LAN permanently reduced MTU of 3G_MTU - 20 (20 bytes for the proto 41 IPv4 header) = 1440 - 20 = 1420 or less. I picked 1408, which is less than 1420, since this = n * 48 - 32 and 32 bytes is the DSL PPPoEoA overhead so 1408 + 32 = a multiple of n 48-byte ATM cells, so when using DSL PPPoEoA as normal it has maximum ATM efficiency]

It is a real shame to have to be on a reduced MTU all the time, when I have been enjoying MTU 1500 for everything. Ironic. This is the cost of the stupid AA 3G / 4G not supporting IPv6 so that you need the header overhead of tunnelling. If they would just fix this, then this nonsense would go away. Years have gone by and no news about sorting it out.

7. For some reason I found another magic incantation to be essential. (I think. Need to retest to be certain.) The main lan subnet needed <subnet ra-dns="2001:8b0::2020 2001:8b0::2021" /> for reasons not understood. I don’t know where it was getting its IPv6 DNS servers from before, presumably from PPP. You can not specify IPv4 addresses here, it won’t let you. The documentation suggests that this is the value that the Firebrick sends out in RAs. I hope this is not true, as the Firebrick, I believed, was itself a local DNS relay caching server, so it should surely be advertising itself to clients, not telling them to go straight to AA. That would defeat the whole point of the real cache server, losing the performance gains due to caching of dns results being shared by the clients on the lan. Maybe it is just a confusing name for the attribute. Clients would always be better off using IPv4 for DNS anyway as it’s slightly faster and in this case especially you do not want any clients to be using DNS over IPv6 because of the 6in4 tunnel overhead. So I’m totally confused. If you didn’t need this before why do you need it now? The only thing that I can think of is that the dongle does not obtain IPv6 DNS server addresses by PPP at all, because it doesn’t not speak IPv6CP, which is a bit surprising, but maybe the 3G carrier gets in the way and the clients when using the dongle are not initially speaking PPP direct to AA. But also the Firebrick would have to not give out the IPv4 DNS server addresses to IPv6 users - but maybe that’s a basic protocol limitation. Maybe it starts to make sense after all. Hoping the attribute is wrongly named, maybe you have to use this technique whenever you do not have IPv6CP. I just hope the Firebrick does advertise itself still even when this is in use. I could perhaps test this by somehow checking what DNS values the iPads hear. Not sure how.

Anyway, in the end, absolutely everything worked. Even IPv6. The speed of 3G was awful, only 2.5 Mbps downstream, 0.25 Mbps upstream from the AA speedtester. This is perhaps due to the position of the dongle, stuck in the Firebrick on a shelf at the side of the office. I am hoping it will improve a lot if I move the dongle to the window where it has a direct line of sight to the base station. I have a USB extension cable on order so that I will be able to do this, and the Firebrick can stay where it is. My iPad gets 8Mbps downstream 3.5 Mbps upstream even in a very bad position at the back of the bedroom when I am in bed and it occasionally picks up 4G. The dongle that I have does not speak 4G. There are 4G-capable dongles that sort-of work with the Firebrick, but they force NAT on you which is pretty vile, so they won’t do a transparent seamless switchover maintaining existing connections unmolested as source IPv4 addresses would change. It might be possible to fix all that nonsense by using an L2TP tunnel for everything, IPv4 and IPv6, to hide the NAT nonsense and restore full routed-block capability. I don’t know how to set the Firebrick up for that and I don’t know if anyone else has successfully done this - there is no example with detailed setup for this in the docs. It’s ridiculous that 4G dongles are such a pain and so different to 3G ones - why do we even need to know or care about this? We just want a modem and that’s it.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick FB2700 3G dongle
« Reply #10 on: October 30, 2018, 03:47:25 AM »

I found out that my iPad is indeed hearing the bad thing when the ra-dns attribute is used. An iPad status info program suggests that the Firebrick is no longer advertising itself as the IPv6 DNS server, and clients will be bypassing it and going direct to AA’s servers. Something really wrong going on here. Need a (different) command to set the IPv6 DNS servers for the Firebrick itself, but the Firebrick should just override that as it currently does, and should advertise itself. This ra-dns command can be available as a true override for what is advertised, but I am not sure why you would want to use such a feature.

What happens if the ra-dns feature only tells the clients which IPv6 servers to use, and does not tell the Firebrick itself which servers to use? Does it have the wit to just use IPv4 DNS itself all the time? In that case, it should all just work fine with no problem.

If I put the Firebrick’s own IPv6 address into the ra-dns list as the only entry, the clients will hear the right thing, but will the Firebrick know what to do internally?

I tried doing this: setting ra-dns="<firebrick’s own LAN-facing IPv6 address>". Admittedly it was not a complete test because there was no dongle failover testing. But the iPad said that it did indeed pick up the advertised value that was expected, the Firebrick advertised itself. As a sanity check, I set the ra-dns value to a bad address, and the iPad picked this up, so the ra-dns mechanism does do exactly what it is advertised to do. Also nothing broke, the Firebrick was still capable of doing DNS itself, but it may have been that clients did not use IPv6 DNS so it was not tested. To complicate matters further, there is the question of whether or not the Firebrick was just always using IPv4 DNS internally and so it would still be able to work even if it did not know how to do IPv6 DNS. And it also still had the benefit of the DNS results from IPv6CP anyway, I assume. So not a good test, need to do dongle failover. Could disable IPv4 DNS in a client by perverting the IPv4 values with manually specified bad addresses, that way I could force it to use IPV6 DNS or nothing.

I did a further test. I asked the Firebrick to internally do some DNS lookups, by pinging IPv6-only machines by domain name, with ra-dns set to point to the Firebrick itself. It was all happy. I checked for caching effects by retesting using an AAAA domain name that had not been previously looked up. I then did another test, with a bad value in ra-dns and the Firebrick was still happy, so it appears that it doesn’t need these ra-dns values internally for its own functioning. Which is what you would expect. Makes sense, and it seems to be doing just what has been documented.
« Last Edit: October 30, 2018, 04:16:02 AM by Weaver »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick FB2700 3G dongle
« Reply #11 on: October 30, 2018, 07:16:49 AM »

After some proper retesting it seems the entire ra-dns thing was a total red herring. It isn’t necessary and things work fine even during dongle failover if it’s simply omitted. It was just an evil and confusing example on the website.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Firebrick FB2700 3G dongle
« Reply #12 on: October 30, 2018, 03:27:27 PM »

It reads as if you are getting a grip on what is required.

Unfortunately all FireBrick documentation, that I have read, has been poorly written. I'm sure I've mentioned this before . . . Instead of stating "this and that" is required to achieve the desired result and then following up with a few examples, it becomes a written lecture on some topic that the writer decided provide. ("Look at what I have written. I'm oh so clever.":-X 

[Edited to fix a typo.]
« Last Edit: October 30, 2018, 08:54:29 PM by burakkucat »
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick FB2700 3G dongle
« Reply #13 on: October 30, 2018, 07:10:31 PM »

Examples and individual cases are sorely lacking. Documentation needs to be written by a mixture of people who know nothing and know everything. Unless people who know nothing are involved, things will be assumed to be understood or known or obvious when that is not the case at all. I said at work that writers need a switch on the back of their heads and that we used to hire arts graduates to write and they would be in danger of becoming useless after six months because they might learn too much and become part of the knowledgeable technical community where things are generally ‘obvious’ or well-known too all, unlike the intended audience which is new to the subject. I did a small amount of documentation at work and worked a lot with people who did it full time.

Coming back to the Firebrick. Everything works perfectly with it now and the ra-dns nonsense has been dispelled. The low MTU - see other thread - remains an annoying mystery.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Firebrick FB2700 3G dongle
« Reply #14 on: October 31, 2018, 12:18:53 AM »

I just realised that I made a mistake. I misread the example config in the AA website thinking that it said mtu="1480" but it actually says ra-mtu="1480". It turns out that the latter is very useful, as it is IPv6-only, confirmed from the evidence of experiment, allowing you to set separate IPv6 and IPv4 MTU values. I suppose that you could possibly arrange that anyway, by declaring two subnets, but only if it allows the declaration of IPv4-only and IPv6-only subnets by only mentioning addresses of first the one then the other type. I would think it does as you can certainly have an IPv4-only network.

Anyway, by using this trick, I have full 1500 bytes IPv4 MTU and an IPv6 MTU of 1408, which is low enough to be below 1420 = 1440-20, so good with the stupid low dongle 1440 MTU and a 20 byte IPv4 6in4 header.
Logged
Pages: [1] 2
 

anything