Wrong display for ppp in Interfaces page
I have a ppp link configured with a 3G usb modem Huwaei E372 which is working great.
However there is a bug in the display for "Cell SIM State" and "Cell Service" in the Interfaces page:
Cell Signal (RSSI) rssi:10 level:-93dBm percent:32%
Cell Mode WCDMA, HSUPA Mode
Cell SIM State Invalid SIM/locked State
Cell Service No Service
Cell Upstream 8438 kbit/s
Cell Downstream 20508 kbit/s
It displays that while ppp is up and working great.
Do not report misleading 3G service status (Bug #4287)
If the ^SIMST or ^SRVST info was never received from the device, report missing/unknown states instead.
#1 Updated by Phillip Davis over 4 years ago
What is in /tmp/3gstats.* ?
and what is the output of:
Those things are used by function get_interface_info() in /etc/inc/pfsense-utils.inc to generate those various text status. I guess your 3G Huwaei model is reporting its status strings a bit different to what is expected.
#2 Updated by Jo S over 4 years ago
Here is the output:
ugen0.1: <OHCI root HUB 0x8086> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen1.1: <OHCI root HUB 0x8086> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen2.1: <OHCI root HUB 0x8086> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen3.1: <EHCI root HUB Intel> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen4.1: <OHCI root HUB 0x8086> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen5.1: <OHCI root HUB 0x8086> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen6.1: <OHCI root HUB 0x8086> at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen7.1: <EHCI root HUB Intel> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen3.2: <HUAWEI Mobile Huawei Technologies> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
[2.2.3-RELEASE][firstname.lastname@example.org]/tmp: cat 3gstats.opt3
#3 Updated by Phillip Davis over 4 years ago
The simstate and service fields in your output are the field offsets used by the code, so that is a good start. But the values are the 2 "0" on the end of the comma-separated list. "0" is supposed to mean "Invalid SIM/locked" and "No Service" respectively, so the widget is displaying correctly based on the data in 3gstats.opt3
I have a ZTE 3G device, so I cannot play for you.
Maybe there is someone else with a Huawei 3G device that can also look in 3gstats.* and see what they get in those last 2 fields and give some clues?
#4 Updated by Jo S over 4 years ago
Looked a bit at the source code:
There is 3gstats.php which is retrieving datas from the Huawei monitoring device: https://github.com/pfsense/pfsense/blob/master/usr/local/bin/3gstats.php
And this script is called by https://github.com/pfsense/pfsense/blob/master/etc/inc/interfaces.inc#L2015
Per default, simstate/service is 0 in the $record array, until the monitoring device send ^SIMST or ^SRVST to populate datas.
I launched "cat /dev/cuaU0.3" to watch which datas are coming in the monitoring device, and I only see RSSI , BOOT , DSFLOWRPT , CSNR datas. My device never send SIMST or SRVST, not sure if it depends on the device model or if there is a configurable option on the device to make it more verbose or if it is something else.
A little update to the script and interface display could be to make a difference between "never received this information" and "invalid sim state" to be more accurate.
#8 Updated by Jo S over 2 years ago
I can't test the patch actually because since then I have changed my 3G usb key to an other huawei one, and there is 2 things:
- in 3gstats.php , this call is made to look for huawei usb key : /usr/sbin/usbconfig | /usr/bin/egrep -ie '(huawei)'
but in my case I don't have anymore huawei displayed in the list, only the vendor id (see below), so 3gstats is not even called in the background like before.
ugen0.2: <product 0x14ac vendor 0x12d1> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
- and even if I call it manually with /usr/local/bin/3gstats.php cuaU0.1 opt3 , it seems my new usb key does not report any stats.. even if I do a "cat /dev/cuaU0.1" directly.