Huawei E3372 will not reconnect PPP after manual disconnect under status-->interfaces
-
Hi AndrewZ,
I apologise, that's a mistake in my post, I copy and pasted that from a list where I had tried a few different SETPORT configurations. I am in fact using the string you suggested as it won't connect with 10 missing.
I've edited the above post to show the correct info for my config.
AT^SETPORT="FF;10,12,16" ^GETPORTMODE: TYPE: WCDMA: huawei,,modem:0,pcui:1,ncm:2
-
You are most probably out of luck here.
These ppp sticks don't behave well. I have played with a few in the past.
When they work, performane is nice etc.
However reconnecting was always a nightmare.
At some point everything worked, however if the stick was removed and pf was rebooted
then it would detect an interface missing and require a new text based interface setup.
I ended up using a small mikrotkik router housing the usb stick and providing pure ethernet to the pf. Rock solid -
I hope we're not out of luck! I went with the direct PPP method as I require this device to host services over this interface and don't want the headache and pitfalls associated with double NAT if I were to put the pf box behind another router. To that end I initially configured the stick working hilink mode which presents itself to the pf box as a network interface, however there's no way to configure a DMZ in the stick firmware to pass through all the external traffic. In hilink mode the stick takes care of the 4G connection and the whole disconnect/reconnect through the firmware's webui in the stick works fine; however double NAT just doesn't cut it for this application.
Has anyone had similar experience with current 4G dongle successfully connecting, disconnecting and reconnecting using PPP?
-
@bradtpt Yes, its true that hilink mode doesn't have a dmz feature and that's a pitty. The thing is that usb management relies on the os and I doubt there is much to be done at the pf level.
I never found a reliable solution anyways.
And as you are at it, make sure that you get a working ip from 4g. Nowdays 4g carriers often do cgn, or just firewall their networks not allowing incoming connections. -
I was hoping it was just something not quite right with the way the PPP session was being terminated as the logs show the modem no longer responding to commands after the session is terminated. You're correct regarding the NAT'd addresses most mobile providers dish out. I'm in Australia and in this example I was connecting using an Optus prepaid sim and that's exactly what we get, an IP of 10.x.x.x which isn't a public routable address. This box will end up with a Telstra sim in it using the 'telstra.extranet' apn which does provide us a public routable address which I have tested and does work. The headache is though they can't give us static IP so we'll be relying on dynamic DNS updates
In my further investigation I have found that I can terminal into the com ports it presents prior to making a connection (/dev/cuaU0.0 and /dev/cuaU0.1) and can query the modem with commands like ATI and get a response. Once the connection is up I can no longer terminal into the port the modem is using with a 'device is busy' error, this is expected behaviour. Whilst the connection is active I am able to cu -l /dev/cuaU0.1 and query the modem as this is the other port the modem presents and isn't used for the data connection. In the 0.1 port the modem reports network connection type, RSSI and a few other parameters every 20 seconds or so like follows:
[2.4.4-RELEASE][admin@pfSense.localdomain]/root: cu -l /dev/cuaU8.1 Connected ^HCSQ:"LTE",45,35,111,20 ^HCSQ:"LTE",44,35,111,22 ^RSSI:17 ^RSSI:19 ^RSSI:19 ^RSSI:18 ^RSSI:19 ^RSSI:18 ^RSSI:19 ^RSSI:18 ^RSSI:18 ^RSSI:18 ^RSSI:19 ^RSSI:19 ^RSSI:19 ^HCSQ:"LTE",47,35,116,18 ^RSSI:18 ^HCSQ:"LTE",44,34,106,20 ^HCSQ:"LTE",45,34,116,18 ^HCSQ:"LTE",48,40,116,24 ^HCSQ:"LTE",45,34,116,18 ^HCSQ:"LTE",48,39,121,22 ^HCSQ:"LTE",44,34,121,20 ^HCSQ:"LTE",49,40,116,24 ^HCSQ:"LTE",46,35,121,18 ^HCSQ:"LTE",46,36,121,20 ^HCSQ:"LTE",47,37,116,20
After bringing the connection down I can reconnect to /dev/cuaU0.0 with the following message about a stale lock:
[2.4.4-RELEASE][admin@pfSense.localdomain]/root: cu -l /dev/cuaU8.0 Stale lock on cuaU8.0 PID=34457... overriding. Connected
However the modem doesn't reply to any command I issue eg ATI or AT&F etc. Those commands illicit a response when I connect to the .0 port prior to connecting, connecting to 0.1 after the disconnect works fine too.
My thought here is perhaps the PPP client is forcefully terminating the connection rather than sending a valid "hangup" code to the modem. Should I maybe have a dig around in the chat script that ppp runs to do the connection / disconnection? I've had a quick look as I recall finding where I could change a dial string from atdt to atd a few days ago but I can't seem to find it now (any hints? I've looked in places like /usr/local/sbin/ppp-linkdown)
I'll keep messing with it, but if anyone has any suggestions I'd be happy to hear them.
-
@bradtpt Lets hope there is a solution. (do try to reboot pf after removing the stick and see if it comes up nicely in any case. I have reasons to believe it will kick in into interfaces configuration mode).
As for dynamic dns, opt for an rfc2136 based solution. It requires administration over your ns's but works splendidly fast and reliable.
https://www.netgate.com/docs/pfsense/dns/rfc2136-dynamic-dns.html
I'm using it for years on a linux box with a simple script. On pf, no need for scriptNow as for your further investigation, ppp by design talks to the modem with at commands asking it to make a dial connection. When the modem is connected it enters "transparent" mode and starts passing data
The modem is theoretically unaware of the data protocol used after that.
Sometimes there is an escape sequence that takes the modem into command mode and then you can issue an ATH (for hangap if i recall). However I doubt is used by ppp because it is device specific and due to the fact that ppp has a solid disconnection mechanism in place.
Supposedly, the modem would detect loss of carrier due to far end disconnection and return into command mode.
But in the wonderfull world of emulating things for backwards compatibility, this doesn't happen as it seems.So, apart from disconnecting the stick physically or rebooting, is there a manual command that resets the modem into a working state? If yes, perhaps it can be scripted.
Long term even if it works this would need to be maintained among version updates. I'm not holding my breath.
-
If I reboot the box after disconnecting, it will boot up and connect without issue as the interface address remains at /dev/cuaU0.0 after the reboot. I'm up to about 8 or 9.0 now with my testing in my spare time today but with a reboot it'll come back to 0.0. So for a use case scenario where it's deployed and configured at 0.0, after a dropout a simple reboot will bring it back online.
That RFC2136 solution looks lovely, I run my own DNS server so this would tie in a treat, thanks for the tip!
Yes thinking back to my dialup days ATH or ATH0 will hangup the line, I'm not sure what's issued by the dialler script to terminate it but I've managed to find a Huawei based reference AT command set so I was hoping to check.
As for manually bringing the modem back online through software I need to do a "usbconfig -d 0.2 reset" which will increment the base device number by +1. This means that the PPP config needs updating with the link interface /dev/cuaU[x+1].0 (eg for the first disconnect from cuaU0.0 to cuaU1.0). Doing this brings it back without a reboot but it'd hardly what I'd consider ideal. I have visions of looking in the config one day and seeing it trying to connect on link interface /dev/cuaU28463.0 If I can work out a way to delete the stale locks on the ports after the reset, but prior to FreeBSD detecting the device after reset and it allocating interfaces to it the device should come back at the same address and if this were the case the PPP dialler would just pick it up and reconnect... I'll keep digging.
-
@bradtpt The thing is that ppp would never talk to the local modem. Disc will go to the far end.
Fiddling with low level usb detection on freebsd isn't very helpful to begin with.
ppp can't support full speed 4g speeds thus the "new" emulated ethernet interfaces.
But the hilink implementation om huawei sucks for not having a dmz, or port forward capability.
I would either opt for a mikrotik 4g router that might handle 4g better and provide an ethernet interface, or I would just create an outbound openvpn client connection to a reliable host and backhaul that traffic -
Yeah I tore my hair out for far too many hours last night playing with init strings etc. I now know far more than I ever wanted or needed to about the GPRS AT command set. I actually implemented the openvpn idea a few weeks ago and it works for what we need, I was really just hoping for a much nicer solution.
Part of my frustration comes from the fact I can pull this stick from the pfbox and shove it into my Windows machine and it'll connect/disconnect/connect just fine using the Windows PPP client, likewise I can then throw it in an Ubuntu laptop I have here and it works flawlessly with the whole c/d/c cycle using the Ubuntu's built in PPP client in the network manager. Beside the laptop on my desk is a Draytek Vigor2862ac which I was setting up for another client that I decided to test it on and no surprise here, it works too. Just shits me I can't get pf to play ball on what I thought would be pretty simple functionality.
As for the speeds, I was expecting a max of about 20 - 25mbps, however I have seen 45mbps through it on the pfbox using PPP which is higher than what I'd read they were capable of using PPP. Do you have any experience or feedback regarding speeds as this far exceeded what I had been lead to believe I could achieve with PPP for the reasons you stated above.
-
@bradtpt I recall having stability i issues and in hilink mode. Probably something to do with usb at the bsd level. As for speed, when testing I could get up to 80/30 in hilink mode. It would max out at about 40-45 in ppp during my tests too.
I suspect processor speed might play a role here In practice, speeds over 20-30mbits are rare in 4g networks in urban areas due to heavy usage anyway. -
I believed the maximum throughput was 42MBps for PPP lining up with HSDPA but I recently saw a report of >60Mbps so I guess it's possible if your carrier and hardware support it. I've personally seen ~32Mbps using a Sierra m.2 modem and PPP.
Steve