WWAN (wireless modem): is PPP appropiate? Howto use the cdce(4) ethernet device?

Hi!

I'm dialing in over WWAN on a laptop w/ ppp(8) on the /dev/cuaU0 serial port of the 3G WWAN card (HSDPA+, no LTE). The drivers involved handle all the magic to route the command and data port automagically (e.g. the line speed on /dev/cuaU0 defaults to 115200 baud, but I have up to 12Mbit bandwidth). This is very unstable, and I'm trying to find a better solution. PPP is usually used on wired lines where the physical parameters are more or less stable (temperature and magnetic fields, everything else: "don't care"; whereas to radio waves e.g. the humidity can have a great impact). But with wireless WAN this is not the case, so I think PPP might not be appropiate at all to handle the lower link layers. E.g. PPP is (usually) not used with WLAN, so why should I use it on a WWAN?
  • The 2nd issue is that ppp(8) needs 20+ seconds to set up the link, whereas from what I see on smartphones (these also have a WWAN card), this takes less than 5 seconds (setting the line speed to 460k makes no difference at all).
  • Should I instead place the modem init commands (AT-style) in some devd(8) file?
  • Should I, and if, how can I make use of the ethernet device provided by the cdce(4) driver?
    ifconfig(8) shows a ue0 ethernet device, but this driver has no man page...
    Do I guess right this is uether(4) (which does not have a man page)?
  • Is there any better way to connect via the serial modem port /dev/cuaU0?
THX in advance!
 
I use pppd for my GPRS Internet connection (3G USB modem). It actually runs on my Debian Linux Raspbian firewall on a Raspberry PI 4 while I wait for OPNSense to get supported on ARM (FreeBSD 13, I think).

I have had pppd working with the USB modem on FreeBSD, pfSense, OPNSense, and Raspbian without too much difficulty. I don't know any other way of doing it if you want to use GPRS direct connect, though tethering via WiFi to an external "personal hotspot" (which would use the same SIM) would be the most common alternative. But that just moves the connection to a device where you have less control...

I monitor the link constantly, and re-dial automatically, as required, any time the connection drops (I'm pretty sure that the phone company kills all long term connections on a semi regular basis).

If your connection is unstable, look at the antenna. 3G is generally better for stability and distance than any of the more recent cell phone standards. I use a directional antenna on top of a 6 m pole.

Sorry, I can't comment on your other questions.
 
There is some good info in this thread. Not sure how to use a cdce device.
I use Sierra modems and they use DirectIP mode with ppp for connection.
net/mpd5 is a good connection daemon for ppp.

Here is some information on cdce and devd:
 
Thx for your answers. Now I know I do what others do, except I use ppp(8) from base and not net/mpd5 fro ports. Maybe mpd5(8) will connect quicker, I'll try. The logs show that some negotiation is done twice...
  • A sub-optimal antenna (itself, or a bad position relative to the access point) is a good explanation for the instabilities I have. My access point is ~500m, I'd say that's not far.
  • Or the provider over-sells it's capacities, thus bandwidth and latency vary heavily depending on how may clients connect to the access point.
  • From the thread Solved - devd in interface ue0 one could conclude ue0 is the name of an ordinary network interface provided by cdce(4), since the OE assigns a IP address to it. According to the man page cdce(4), it is a bridge, e.g. for packet filtering. Is it common to give a bridge an IP address???
 
Knowing your modems make and model would be helpful.
Some modems have different USB Compositions.
This means they support various modem protocols.
There is usually a manufacturers tool or AT commands to switch them to various compositions.

The list here shows some of the different modem protocols.
This can be useful because it shows the proper data channel and control channel.
 
Thx very much, I'm happy to find s/o w/ some deeper insight.
It can be a bridge but in your case it is a modem communication protocol.
Does that mean I can use that instead of /dev/cuaU0? Looks strange to me... after all, it's a network interface. Or can I use that instead of ppp(8)'s tun(4), and the drivers handle all routing automagically?
Knowing your modems make and model would be helpful.
Ericsson N5321 on an M.2 port in a refurbished Lenovo Thinkpad T450s. Latest fix applied to UEFI/BIOS (see my howto), about the firmware for the modem I can only hope the seller applied the latest fixes as of last summer (2019). Unfortunately, the FBSD installer wiped out the Windows recovery partition... and I was too brisk when jingling around with backups on USB thumb drives, now it's lost :) I don't like to do that on FBSD, I shreddered a disk once by applying a firmware update via FBSD camcontrol(8).
Some modems have different USB Compositions.
This means they support various modem protocols.
OK now I know the huge latency I see comes from inserting a gap every 3 frames when I use CDC ECM. Using cdce(4)'s ue0 would solve that, since it supports CDC NCM, wich overcomes this issue of the older ECM? Is that right? And that's the reason why my bandwidth maxes out at ~12Gbit instead of the 20Gbit that my provider supplies? And I need to find out how to enable NCM...
There is usually a manufacturers tool or AT commands to switch them to various compositions.
I guess that's what I'm doing with the AT command +CGDCONT=1 and +CFUN=1
Grabed that from ThinkWiki. I even got the GPS port to work, but did not manage astro/gpsd to read the NMEA stream. I'll patch that when I find the time.
The list here shows some of the different modem protocols.
This can be useful because it shows the proper data channel and control channel.
I'm pretty shure I got these right; besides that, I have the impression the drivers are very relaxed about this and correct innocent user's mis-use of control and data channel. I could play aroud with the AT commands on both /dev/cuaU0 and cuaU1 with comms/minicom.
 
I monitor the link constantly, and re-dial automatically, as required, any time the connection drops (I'm pretty sure that the phone company kills all long term connections on a semi regular basis).
For shure they do that, I'd say it's right to do so. You don't have a leased line, right?! Of course, you want one, but I guess that's not quite what your contract is about... ;)
IMHO it's better to use ppp's auto mode, i.e. re-dial automatically at the time when there's data to transmit. Why occupy a slot on the access point when there's no need to?
I use a directional antenna on top of a 6 m pole.
Do you live on a (sailing) boat? Or is it just that you live in a rural area?
 
IMHO it's better to use ppp's auto mode, i.e. re-dial automatically at the time when there's data to transmit. Why occupy a slot on the access point when there's no need to?
I need to be able to connect in as well as out. Plus all the devices connecting to the internal network (including cell phones) put up a pretty constant chatter.
Do you live on a (sailing) boat? Or is it just that you live in a rural area?
Rural. My only options are cellular mobile or satellite. There's fixed wireless radio reception annoyingly close, and I suspect I might be able to get that if I put a repeater on a hill -- but the required antenna just becomes a lightening rod.
 
To use the ue* interface you need to activate it first. The chat script at the end of that wiki should do the job if that's an Ericsson card. Then just dhclient ue0 to get the IP address.

I've written dhclient scripts to activate the modem when starting dhclient. If you want to use these you need to add script "/usr/local/etc/dhclient-script"; to /etc/dhclient.conf (PIN was never tested though).

But I doubt if the protocol used (PPP or CDC-Ether) makes any difference in connection quality.
 

Attachments

Back
Top