Can't get Sierra Wireless Aircard 340U to be recognized

[fctr]

That's an understatement!

I guess I'll try to plod through on my own.

[franco]

It may need a hardware quirk or otherwise, but since I don't have the device I think it's a bit futile to continue this although it's nice to have it show up as a modem as expected.

If anybody else wants to confirm they got it working we can talk about including it.


Cheers,
Franco

[fctr]

I've been a computer programmer for over 45 years, but FreeBSD is uncharted territory for me. I would be more than happy to get this thing working, if I can get someone to point me in the right direction and hold my hand for a bit.

This out of production card does work under Linux, so I know it's not unrealistic to make this work with FreeBSD. Anybody willing to help me out with this until we get it working?

[franco]

Have you checked which device responds to AT command?


Cheers,
Franco

[fctr]

I can use minicom on /dev/ttyU0.1 at 115200 baud to successfully issue AT commands.

Can I assume /dev/cuaU0.1 is the correct choice?

[franco]

Yep. I'm assuming SIM card is unlocked so now create a PPP device and pick that particular port and add your provider settings. After that save and go to interface assignments. Create a new interface with the ppp device just created or assign the PPP device to your WAN (whatever you need in this instance). After save go to the new interface, enable and save. Then it wants you to apply and it starts trying to connect. At least the PPP log should fill up now with "something". Let's see what it does there.


Cheers,
Franco

[fctr]

Yep. I'm assuming SIM card is unlocked so now create a PPP device and pick that particular port and add your provider settings. After that save and go to interface assignments. Create a new interface with the ppp device just created or assign the PPP device to your WAN (whatever you need in this instance). After save go to the new interface, enable and save.

Did all that, and all seems OK.

Then it wants you to apply and it starts trying to connect. At least the PPP log should fill up now with "something". Let's see what it does there.

And there's the problem. The PPP log doesn't say anything. It's totally empty. No gateway, or anything. It's like it's stuck or something.

[fctr]

Franco:

I can't imagine you have the free time or desire, but I'm happy to grant you remote access to the machine if you want to see it for yourself.

[fctr]

Here's some more updates:

When creating PPP0, the entry does not save the provider information. I enter everything as I should, and hit save. Then if I click on edit, the provider/country/APN stuff is missing.

When I assign PPP0 to an interface, it complains:
The following input errors were detected:  The field Modem Port is required.

It was on the screen before I hit save, then after hitting save, it disappeared and I get the above message. What's going on? What am I doing wrong?

[fctr]

I GOT IT TO WORK!

A lot more details to follow in the next post.

[franco]

Ok great. I will wait for the full report to arrive before pushing this to FreeBSD but I can add this to our 24.7.3 kernel no problem.


Cheers,
Franco

[fctr]

OK, so let's get this party started! I'm a little inebriated, so forgive my ramblings.

First of all, AT&T came up with the brilliant idea of allocating an IP address to the card in the 10.x.x.x range. That caused routing problems, as you can imagine. More on this later.

The biggest issue I found is in the Point to Point configuration screens.

• Click on "Interfaces->Point-to-Point->Devices->+"
• The link type is set to PPP
• The link interface is set to /dev/cuau0.1
• Description is left blank (I tried filling this in, but it didn't matter)
• Here's the meat of the problem. Service Provider information is set as Country: USA, Provider: AT&T, Plan: Laptop Connect.
• Everything else is left as default.
• Hit Save

All great, right? NO! If you hit edit on the device screen, guess what? Service Provider information is lost. Gone. Not remembered. Poof!

But, for s**ts and giggles, skip editing the device after saving. Y'alls gotta fix that...

• Click on "Interfaces->[WAN]"
• Make sure Block Private Networks is UNCHECKED
• Make sure Block BOGON Networks is UNCHECKED
• Set IPv6 Configuration Type to None. (Not sure if this is really necessary, but it works for me)
• Hit Save and Apply (if necessary)
• Click on "Interfaces->Assignments"
• Change the [WAN] interface to ppp0 (or whatever you created in the previous list)
• Hit Save and Apply (if necessary)

Voila! Aircard 340U now works as expected!

There is a slight delay, but I'm guessing that's due to the Aircard itself or AT&T's service, but it does indeed work! Now here's the bigger issue, with a 10.x.x.x address, things like WireGuard won't work. I guess AT&T put their own NAT in front of their cellular network. T-Mobile does the same stupid thing, but paying for a static IP changes your APN and then you get a real IP address. I can only imagine AT&T does that as well.

By following the instructions in the manual, the setup for the Aircard fails BECAUSE the provider information is lost in the ppp setup, and if you assign the Aircard to the WAN interface before setting up the WAN interface, it's impossible to enable the interface because the save function stops working due to the Provider information being lost, as well as the /dev/cuau0.1 interface info.

So it seems the Aircard 340U (for AT&T) does work with your kernel patch, but the php code needs a little work.

Thanks a lot. All your help saved me THOUSANDS of dollars. And now, more drink, please...

[doktornotor]

All great, right? NO! If you hit edit on the device screen, guess what? Service Provider information is lost. Gone. Not remembered. Poof!

I don't think it's meant to be persistently saved? When you select something there, it fills in Username/Password/Phone Number/APN/... and that's it. Using this file AFAICT. That info is not needed for anything after that step. (See the description "Select to fill in data for your service provider.") Think about it - suppose the linked file is out of date (can happen and probably happens all the time) and some field pre-filled by using those selection dropdowns needs changing. Now what? You save the dropdowns selection state, which no longer matches the configuration it provides - what'd be the use for that? When you click edit, those (required) modifications you have made will get overwritten by the outdated info?

the save function stops working due to the Provider information being lost, as well as the /dev/cuau0.1 interface info.

I cannot reproduce this. The interface (port) is saved just fine, after saving, I can see the created PPP interface available in Interfaces - Assignments just fine. As for the provider info - well, see above.

[fctr]

Now that the effects of excessive alcohol abuse have worn off and the caffeine has kicked in, I can understand a lot more about how the Service Provider stuff is merely a form filler, for convenience. With that being said, how it's presented in the UI is pretty lousy. There's no indication whatsoever that tells the user that. The entire section should be hidden UNLESS the user hits a button that says something like "fill in the boring technical stuff with stuff I already know" or something like that. That way the user won't expect it to be saved, like I did in my drunken stupor.

That also means that the Point-to-Point config stuff should NOT appear in the Interfaces configuration screen at all. Maybe something that shows the data already configured in the Point-to-Point screen, but there's no need to have editing duplicated. It makes configuration all the more confusing.

Now with all that out of the way, the Interface configuration screen with a Point-to-Point assignment still doesn't work.

If remote access is needed to show you this, I'd be happy to set it up.

Also, please note that my ranting and negative energy is really just nitpicking at this point since I was able to get it working, so I'm still really happy.

Do you think there's any chance in H-E-double hockey sticks that I could get a tagline for testing the card after Franco pushes the changes to FreeBSD? I'd love to be able to tell people I contributed to FreeBSD in a meaningful way.

[doktornotor]

There's no indication whatsoever that tells the user that. The entire section should be hidden UNLESS the user hits a button that says something like "fill in the boring technical stuff with stuff I already know" or something like that.

Well, I am sure pretty much noone else would appreciate that section to be hidden by default since it's extremely useful to  - let me quote the GUI description that's already there once again: "fill in data for your service provider." Most users have no idea what to fill in there, really. The ISPs don't provide any howtos with what to fill where for OPNsense.

I don't get the confusion following this pretty straightforward howto or where are you getting stuck: https://docs.opnsense.org/manual/how-tos/cellular.html

You configure the PPP interface.
You need to assign that to some WAN. This really is no different from PPPoE, GIF, VLAN, LAGG or whatever else.