Or even better: Fix the other side of the equation.
I have no idea how difficult that is, but it would be nice to have more robust scripts if this is a known problem
Looking at a ncm.json file, there were other modems which made less verbose if you look at some of them. Or at least some of the commands seems familiar... Non the less I agree with you: relying on scripts that fails based on how verbose a modem is (and I have seen large variations when it comes to different vendors) is not a good idea, but I am not skilled enough to fix this system level issue with NCM. Hell, I am still not sure how this supposed to work. For example if the NCM "interface" is talking to /dev/ttyACM0, how it will bring up the RNDIS interface? Or it will crate some extra artificial interface? And how? With what commands? I have not seen a single working example of NCM, and the wiki is also very short on that end...
I assume the vendor specific AT+ZGACT will bring up the connection, and allowi you to use the existing RNDIS interface as if it was the mobile network interface. You should be able to test this by entering the AT commands manually.
There is nothing special about a USB function like RNDIS or ACM. They are just protocols the host (OpenWrt router) and device (LTE modem) uses for communicating over USB. How these are related is up to the modem firmware to decide.
For the troublesome modem, it may be worth giving ModemManager a try: https://github.com/openwrt/packages/blob/master/net/modemmanager/Makefile instead of comgt.
It has more dependencies, but more features as well.
I support the ModemManager recommendation in general, but I'm not sure it helps in this specific case.
Mikrotik modems are quite uncommon, and rarely found outside a few Mikrotik routers. I don't think MM has any plugin support for the vendor specific management protocol. Can't find any "ZGACT" anywhere in the ModemManager repo.
So I guess using MM means that you have to implement the Mikrotik plugin. Probably not too hard, but it will be work,..
Hi
Have you tried +CMER Mobile Equipment Event Reporting, to turn of URC?
+CMER - Mobile Equipment Event Reporting
Set command enables/disables sending of unsolicited result codes from
TA to TE in the case of indicator state changes
I think you should use small capitals for the ncm.json file.
The ncm.sh script use tolower for the manufacture name.
manufacturer=$(gcom -d "$device" -s /etc/gcom/getcardinfo.gcom | awk 'NF && $0 !~ /AT\+CGMI/ { sub(/\+CGMI: /,""); print tolower($1); exit; }')
@dchard Also, apparently you can configure which indicator changes will cause URCs to appear via AT+CIND command as well.
So, at the moment the modems lists this data right after startup:
*SIMDETEC:2,NOS
*SIMDETEC:1,SIM
*ICCID: 8988211000000073653
*EUICC: 1
+CREG: 0
$CREG: 0
+CESQ: 99,99,255,255,255,255
*CESQ: 99,99,255,255,255,255,0
+CGREG: 0
+CEREG: 0
+CESQ: 99,99,255,255,255,255
*CESQ: 99,99,255,255,255,255,0
*RADIOPOWER: 0
*ADMINDATA: 0, 2, 0
+CPIN: READY
*EUICC: 1
*ECCLIST: 5, 0, 112, 0, 000, 0, 08, 0, 118, 0, 911
+MMSG: 0, 0
+MMSG: 0, 0
+MMSG: 1, 0
+MPBK: 1
The AT+CIND is set to +CIND: 0 by default.
The AT+CMER is set to +CMER: 3,0,0,0,0 by default.
+CEREG: 3,0 by default
+CGEREP: (2,0) by default.
You could try to set +CMER=0,0,0,0,0
AT+CMER[=[mode[,keyp[,disp[,ind[,bfr]]]]]]
Set command enables/disables sending of unsolicited result codes from
TA to TE in the case of indicator state changes (n.b.: sending of URCs in
the case of key pressings or display changes are currently not
implemented).
Parameters:
mode - controls the processing of unsolicited result codes
0 - discard +CIEV Unsolicited Result Codes.
1 - discard +CIEV Unsolicited Result Codes when TA-TE link is reserved(e.g. on-line data mode); otherwise forward them directly to the TE.
2 - buffer +CIEV Unsolicited Result Codes in the TA when TA-TE link is reserved (e.g. on-line data mode) and flush them to the TE after reservation; otherwise forward them directly to the TE.
3 - forward +CIEV Unsolicited Result Codes directly to the TE; when TA is in on-line data mode each +CIEV URC is replaced with a Break (100 ms), and is stored in a buffer; onche the ME goes into command mode (after +++ was entered), all URCs stored in the buffer will be output.
keyp - keypad event reporting
0 - no keypad event reporting
disp - display event reporting
0 - no display event reporting
ind - indicator event reporting
0 - no indicator event reporting
1 - indicator event reporting
(Couldn´t find anything about bfr)
AT+CMER=0,0,0,0,0 yields:
+CME ERROR: 50
Just AT+CMER=0 ?
Yields:
ERROR
I also tried to set:
AT+CGEREP=0,0
Modem accepts, but nothing changes in terms on reporting.
AT+CMER=
Or will AT+CMER=1 work?
Yields:
+CME ERROR: 50
Also tried AT+CEREG=0, modem accepts, no change in reporting.
Also tried AT+CMEE=0, modem accepts, no change in reporting.
AT+CGEREP=1
0 buffer unsolicited result codes in the MT; if MT result code buffer is full, the oldest ones can be discarded. No codes are forwarded to the TE.
1 discard unsolicited result codes when MTTE link is reserved (e.g. in online data mode); otherwiseforward them directly to the TE.
2 buffer unsolicited result codes in the MT when MTTE link is reserved (e.g. in online data mode) andflush them to the TE when MTTE link becomes available; otherwise forward them directly to the TE.
Modem accepts, no change in reporting.
Then I think we need to follow @bmork ´s suggestion:
Can you add this script: /etc/gcom/getrun_at.gcom
# run AT-command from environment
opengt
set com 115200n81
set senddelay 0.02
waitquiet 1 0.2
flash 0.1
:start
send $env("COMMAND")
send "^m"
get 1 "" $s
print $s
:continue
exit 0
Run this from command line and paste the outcome:
COMMAND="AT+CFUN=1" gcom -d /dev/ttyACM0 -s /etc/gcom/getrun_at.gcom
COMMAND="AT+ZGDCONT?" gcom -d /dev/ttyACM0 -s /etc/gcom/getrun_at.gcom
COMMAND="AT+ZGDCONT=?" gcom -d /dev/ttyACM0 -s /etc/gcom/getrun_at.gcom
COMMAND="AT+ZGACT=1,<one of your profiles>" gcom -d /dev/ttyACM0 -s /etc/gcom/getrun_at.gcom
I am not sure what is the purpose, but if you need the correct snytax of what we need to, then here it is:
AT+ZGDCONT=5,"IP","internet",0
AT+ZGPCOAUTH=5,"","",0
AT+CFUN=1
AT+ZGACT=1,5
Where "internet" is the APN. The above 4 commands will give the outcome we need (dynamic IP address present on the RNDIS interface with working routing).
MOD: actually I think the AT+ZGPCOAUTH part can be skipped, as most mobile operators are not authenticating based on PPP for a long time now...
The intention was to understand the output of the AT-commands and make the ncm.sh script more robust against URC garbage. But, then I realized that it is just two commands that are crucial, the manufacturer name and the PINcode, and the Pincode could be turned off.
Can you run:
gcom -d /dev/ttyACM0 -s /etc/gcom/getcardinfo.gcom
to verify your modem name.
+CGMI: "MikroTik"
OK
And question arises: what happens if we just blindly do AT+ZGACT before the modem is actually attached? MikroTik's own "modem manager" does seem to wait for the attach to be successful, before it issues AT+ZGACT=1,5