PPP log weird things: "omdentGGeneeriicc" "atMoeCmd" "laabeell" [Solved]

mmkkoo

Hello All,

My unit is SG-2100 + EM7455 modem. It's in M.2 slot with two antennas attached. In-house.
Modem is after https://github.com/danielewood/sierra-wireless-modems procedure - thank you Daniel.
I see ttyU0.0; ttyU0.1; ttyU0.2 under /dev/. I am able to talk to /dev/ttyU0.2.
VID:PID is 1199:9071.

Modem is flashed with SWI9X30C_02.38.00.00.cwe SWI9X30C_02.38.00.00_GENERIC_002.082_000.nvu.

I see weird things in pfSense's ppp log, as in subject:

Sep 20 00:12:01 	ppp 	53490 	[wan_link0] CHAT: line 358: label "omdentGGeneeriicc" not found
Sep 20 00:12:01 	ppp 	53490 	[wan_link0] MODEM: chat script failed
Sep 20 00:12:01 	ppp 	53490 	[wan_link0] Link: DOWN event
Sep 20 00:12:01 	ppp 	53490 	[wan_link0] LCP: Down event
Sep 20 00:12:01 	ppp 	53490 	[wan_link0] Link: reconnection attempt 339 in 1 seconds
Sep 20 00:12:02 	ppp 	53490 	[wan_link0] Link: reconnection attempt 339
Sep 20 00:12:04 	ppp 	53490 	Label 'omdentGGeneeriicc' not found
Sep 20 00:12:04 	ppp 	53490 	[wan_link0] CHAT: line 358: label "omdentGGeneeriicc" not found
Sep 20 00:12:04 	ppp 	53490 	[wan_link0] MODEM: chat script failed
Sep 20 00:12:04 	ppp 	53490 	[wan_link0] Link: DOWN event
Sep 20 00:12:04 	ppp 	53490 	[wan_link0] LCP: Down event
Sep 20 00:12:04 	ppp 	53490 	[wan_link0] Link: reconnection attempt 340 in 2 seconds

also, at different occasion:

Sep 19 23:02:04 	ppp 	89489 	[wan_link0] Link: reconnection attempt 22 in 1 seconds
Sep 19 23:02:05 	ppp 	89489 	[wan_link0] Link: reconnection attempt 22
Sep 19 23:02:20 	ppp 	89489 	[wan_link0] CHAT: The modem is not responding to "AT" atMoeCmd: laabeell.
Sep 19 23:02:20 	ppp 	89489 	[wan_link0] MODEM: chat script failed
Sep 19 23:02:20 	ppp 	89489 	[wan_link0] Link: DOWN event
Sep 19 23:02:20 	ppp 	89489 	[wan_link0] LCP: Down event
Sep 19 23:02:20 	ppp 	89489 	[wan_link0] Link: reconnection attempt 23 in 4 seconds
Sep 19 23:02:24 	ppp 	89489 	[wan_link0] Link: reconnection attempt 23
Sep 19 23:02:37 	ppp 	89489 	[wan_link0] CHAT: The modem is not responding to "AT" atMoeCmd: laabeell.
Sep 19 23:02:37 	ppp 	89489 	[wan_link0] MODEM: chat script failed
Sep 19 23:02:37 	ppp 	89489 	[wan_link0] Link: DOWN event
Sep 19 23:02:37 	ppp 	89489 	[wan_link0] LCP: Down event

I guess those atMoeCmd: laabeell. should be more like atModeCmd: label (as I saw in other topics) and omdentGGeneeriicc should be something different, yet somehow it's like that.

I searched for location of those "chat scripts", that are producing this output, on the SGs file system, so I could run the sequence manually from terminal, but with no sucsess.

[22.01-RELEASE][root@pfSense.home.arpa]/root: usbconfig -d 0.2 dump_device_desc
ugen0.2: <Sierra Wireless, Incorporated EM7455> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x1199 
  idProduct = 0x9071 
  bcdDevice = 0x0006 
  iManufacturer = 0x0001  <Sierra Wireless, Incorporated>
  iProduct = 0x0002  <EM7455>
  iSerialNumber = 0x0003  <LF81311433021022>
  bNumConfigurations = 0x0001

My response to at!gstatus? from SG-2100 shell's cu :

!GSTATUS: 
Current Time:  2888             Temperature: 44
Reset Counter: 1                Mode:        ONLINE         
System mode:   LTE              PS state:    Attached     
LTE band:      B3               LTE bw:      10 MHz  
LTE Rx chan:   1599             LTE Tx chan: 19599
LTE CA state:  NOT ASSIGNED
EMM state:     Registered       Normal Service 
RRC state:     RRC Idle       
IMS reg state: No Srv  

PCC RxM RSSI:  -79              RSRP (dBm):  -109
PCC RxD RSSI:  -81              RSRP (dBm):  -109
Tx Power:      0                TAC:         CEA3 (52899)
RSRQ (dB):     -11.1            Cell ID:     01F69234 (32936500)
SINR (dB):      0.6

Tired one or two "init strings" from other topics with no success.

Is this anyhow possible that serial port configuration in FreeBSD needs adjustment? I mean some letters appears twice, some are missing.

Any thoughts, comments or help appreciated.

Best regards,
MK

stephenw10

Try the init string: &F&C1&D2E0S0=0${temp}

The ppp script/mpd5 throws those odd logs messages when it fails to recognise the modem and falls through to a code path that seems suitable for like a 2400 modem from 1988!

I've spent some time looking at it previously but never pinned it down. That init string works for me using an em7305 in a 2100.

Steve

mmkkoo

Thank you @stephenw10. It surely moved me forward as my WAN received IP and I am able to connect.

The connection however is unstable and i need to search some more about this log entry:

Sep 20 20:13:34 	dpinger 	54245 	WAN_PPP 10.xx.xx.0: Alarm latency 0us stddev 0us loss 100%

and this:

Anyway,
PPP log changed entirely.
Could you please recommend any resources to read about this input strings configuration? In order for me to know what is the meaning of this config and how to compose them? Perhaps optimize or at least feel little more comfortable ;).

Thank for you time and help.

Best regards,
Mike

stephenw10

The carriers gateway may not respond to pings, mine doesn't. So set the monitoring IP to something external like 8.8.8.8 or 1.1.1.1. I also set the monitoring pings to a much higher interval to reduce the data used since I pay per MB there.
https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html#advanced-gateway-settings

When mpd5 runs to connect the ppp session it runs the script at /usr/local/sbin/mpd.script with the conf file created. That's probably /var/etc/mpd_wan.conf since you're using it for your WAN.

By setting an init script there you make the script run 'ModemIdentCustom' rather than 'ModemIdentGeneric' which seems to be what causes the problem. I only saw it on aarch64 so it's probably something odd with ARM. I never went deeper than that after it started working.

Steve

mmkkoo

@stephenw10 Many thanks.

I followed your advice: monitoring WAN gateway by means of 1.1.1.1 - my comfort level surely is higher:

My cellular connection is rather weak, thus elongate timings:
probe interval=1500
loss interval=2000
alert interval=2500

Also marked Use non-local gateway - as I understand this should be the case for 10.64.64.0 gateway, which is out of my WAN single-IP (Subnet mask IPv4 255.255.255.255) subnet.

Currently when probing
wget -O /dev/null -q --show-progress https://speednld.phoenixnap.com/nld-1gb.test

I see this:

Which is below typical speeds (~15-25M) I saw on ISP's LTE router, but is totally sufficient for the purpose.

Stability issues are also gone, at least tor this few hours I am sitting here its all good.

Other than above only added/removed some traffic shapers (saw in other topic that it can solve some stability issues) currently there is no shaping ongoing.

So thank you again Steve, I think this topics requires further reading from me and in case of any further questions it would be new thread, I believe.

Your feedback was very informative and interesting to me.

I would already add [Solved] to the topic, but do not know how to do so.

Best regards,
Mike

johnpoz

@mmkkoo said in PPP log weird things: "omdentGGeneeriicc" "atMoeCmd" "laabeell":

I would already add [Solved] to the topic, but do not know how to do so.

Done

stephenw10

Nice!

You shouldn't need to set 'Use non-local gateway' on a PPP connection. It's Point-to-point and doesn't care. It's common to be passed a gateway on a private IP like that and a WAN IP with a /32 subnet. That's exactly what I see here.

Steve

mmkkoo

yeah, I found this thread yesterday on forum.level1techs.com and switched it off, as you said, only to see no difference.

"PPP is weird if you’re used to LAN and ethernet addressing. There’s only a single IP on the other side, and peers are originally meant to be symmetrical and not really ask for IPs using DHCP - instead, they’d just announce what IPs they have using IPCP and expect the other side to ack.
Then the whole ip address discovery thing was bolted on, so you as a peer can say, “I have 0.0.0.0”, and ISP can say “no you don’t, you have 2.64.x.x”. ISP peer can still say “I have 10.64.64.0” and you’d typically use that as a gateway.
In your routing tables, you’d have a directly attached 10.64.64.0/32 route via ppp0 as well as a 0.0.0.0/0 (default gateway) route via 10.64.64.0/32 .
[well something along those lines anyway … ppp itself is dying … but you might end up having /32 on ethernet interfaces these days instead]

My PPP log says the same now.

Thanks and best regards,
Mike