For starters:
I know the device works, because I can get it working in other computers; none of them are running FreeBSD, however.
VID: 0x1199
PID: 0x9051
When running a root shell on OPNsense, I can see the device is plugged into the USB port, and it's recognized, but no drivers are loaded. I've tried switching the config to 1 (from 0), and the Aircard tries to act as a hard drive (probably with Windows drivers), but FreeBSD will have none of that and refuses to mount it.
Switching back to config 0, stops FreeBSD from trying to mount the hard drive, but nevertheless no network card, serial port, or anything useful I can work with.
FreeBSD lists this device as something it works with, but OPNsense refuses.
What am I doing wrong?
kldload u3g maybe (https://man.freebsd.org/cgi/man.cgi?query=u3g&sektion=4&manpath=freebsd-release-ports).
I'll give that a try. Thanks!
No such luck!
interface u3g.1 already present in the KLD 'kernel'!
Now what?
Quote from: fctr on August 22, 2024, 07:58:47 PM
interface u3g.1 already present in the KLD 'kernel'!
Well, then it works I'd say. Configure some PPP connection with that.
The closest ones in the kernel are:
product SIERRA EM7430_2 0x81cc Sierra Wireless EM7430 Qualcomm Snapdragon X7 LTE-A
product SIERRA EM7455 0x9078 Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A
Can you dump more info?
# usbconfig
# dmesg | grep usb
Thanks,
Franco
This should give you what you asked for.
Oh nevermind. After going through reams of source code, this one-off Sierra POS isn't supported by FreeBSD whatsoever.
Thanks AT&T. Thanks for nothing. I'm going with T-Mobile, next time.
And a sincere thank you to all those who've tried to help me. Next time I'll read before posting.
Well we can patch it. Expect a kernel to test later today :)
https://github.com/opnsense/src/commit/ed71ffba8d
# opnsense-update -zkr 24.7.2-sierra
and reboot. Let me know how it goes.
Cheers,
Franco
To be totally honest, I didn't expect this to go any further. But I will test. Perhaps tonight or tomorrow. You guys (and gals and whatever...) are the best!
OK, so major things have been happening since the patch.
1) FreeBSD now recognizes this is a serial device, and I can now see /dev/cuaU0.[0-3], /dev/cuaU0.[0-3].init, /dev/cuaU0.[0-3].lock, ttyU0.[0-3], ttyU0.[0-3].init, and ttyU0.[0-3].lock, as expected.
2) I can user minicom on ttyU0.1 at 115200 baud to successfully issue AT commands.
3) ATDT*99# does start a connection, but I can't seem to do anything with it
4) I can setup a Point-to-Point connection in the OPNSense interface, but I'm not sure what to do from here.
I could really use a little more hand holding at this point.
Quote from: fctr on August 25, 2024, 11:22:08 PM
4) I can setup a Point-to-Point connection in the OPNSense interface, but I'm not sure what to do from here.
I could really use a little more hand holding at this point.
https://docs.opnsense.org/manual/how-tos/cellular.html
Wow. RTFM. OK, touche.
I get all the way to step 3 without issue. Step 4 fails. Nothing in the PPP log (as expected) and no gateway from the 340U.
I tried entering the init string provided (thinking, it may help), but still nothing.
I feel I'm so close, I can taste success. Tell me where to look for more debugging info. And don't say https://www.freebsd.org/doc/handbook/ppp-troubleshoot.html (https://www.freebsd.org/doc/handbook/ppp-troubleshoot.html).
That link is of little help.
Unfortunately, cannot really assist with that, no hardware. Last "dial-up" thing I got my hands on was CDMA and it was a complete nightmare.
That's an understatement!
I guess I'll try to plod through on my own.
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
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?
Have you checked which device responds to AT command?
Cheers,
Franco
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?
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
QuoteYep. 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.
QuoteThen 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.
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.
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?
I GOT IT TO WORK!
A lot more details to follow in the next post.
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
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...
Quote from: fctr on August 28, 2024, 04:00:24 AM
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 (https://github.com/opnsense/core/blob/stable/24.7/contrib/mobile-broadband-provider-info/serviceproviders.xml) 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?
Quote from: fctr on August 28, 2024, 04:00:24 AM
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.
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.
Quote from: fctr on August 28, 2024, 11:07:17 PM
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.
At this point, we're getting into personal preference, so let's do the simple thing and leave well enough alone. If it's always been this way, then leave it this way.
But there still is a bug in the editing of the Interfaces once a ppp assignment has been made. I'd be happy to make a cinematic masterpiece and post it, if you'd like, showing you what I mean.
A fix for editing PPP in interface settings was put into 24.7.3 BTW.
I plan to move the whole PPP device thing to MVC as it really needs a refactor anyway, but as far as utility goes it works fine minus that bug I introduced in 24.7.2:
https://github.com/opnsense/core/commit/090c6518d762
Last but not least the modem support is in FreeBSD now:
https://cgit.freebsd.org/src/commit/?id=4b6e76eff8
Cheers,
Franco
I would like to personally thank everyone who made my problem their priority. I'm really happy everything works now. If you need me for any kind of beta testing or hardware information, do not hesitate to reach out.
OPNSense and their support is the best!
Quote from: franco on August 30, 2024, 10:57:39 AM
A fix for editing PPP in interface settings was put into 24.7.3 BTW.
I plan to move the whole PPP device thing to MVC as it really needs a refactor anyway, but as far as utility goes it works fine minus that bug I introduced in 24.7.2:
https://github.com/opnsense/core/commit/090c6518d762
Last but not least the modem support is in FreeBSD now:
https://cgit.freebsd.org/src/commit/?id=4b6e76eff8
Cheers,
Franco
OPNSense is the best!
Well it seems all this work has been for nothing. AT&T has discontinued PPP support for its "Broadband" APN, so now unless someone has a better idea, I've got another paperweight.
I'm not really surprised given the low efforts around PPPoE coding and perpetual issues in the last decade and all the bugs we did address in our own scope to make it more bearable.
So does anyone have any idea on how to make this dinosaur work now?
Or is this just another piece of e-waste that's eventually going to end up in a third world country for supposed "recycling"?
Does it have a proprietary protocol that allows it to work in Linux or *GASP* Windows?