<div dir="ltr"><div dir="ltr"><div>Hi,<br><br></div>So I did the requested testing: Logs attached.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 10, 2022 at 10:13 AM Aleksander Morgado <<a href="mailto:aleksandermj@chromium.org">aleksandermj@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey<br>
<br>
> I'm trying to configure a SIMCOM7070G modem to work with ModemManager/NetworkManager.<br>
><br>
> I've observed there is already a plugin and some support, but unless I'm mistaken, it looks like the current support expects this modem to be connected via USB (4 ports provided by usb: AT cmds, data, gnss, etc).<br>
><br>
> My problem is I'm using it in a board where the modem is NOT connected to the CPU via USB: The regular UART (UART1) provided by the modem is used.<br>
><br>
> So far, I already have some signals of life:<br>
><br>
> 1. MODEM is detected by ModemManager as Generic GSM modem: I added the following rule to /etc/udev/rules.d/ and works fine:<br>
><br>
> ACTION!="add|change|move|bind", GOTO="mm_whitelist_end"<br>
> KERNEL=="ttyS4" ENV{ID_MM_DEVICE_PROCESS}="1"<br>
> LABEL="mm_whitelist_end"<br>
><br>
<br>
There are several things missing here.<br>
<br>
The "simtech" plugin only expects USB modems right now. It should be<br>
updated to have MM_PLUGIN_ALLOWED_VENDOR_STRINGS, so that after the AT<br>
probing phase is run, ModemManager tries to guess the modem vendor<br>
based on the given string. Once that works, the simtech plugin will<br>
take control of your modem, with the simcom-specific features if any<br>
needed.<br>
<br>
Then given you're using a pure RS232 port, please note that you should<br>
explicitly configure how the TTY is supposed to work, in particular,<br>
you need to define ID_MM_TTY_BAUDRATE and ID_MM_TTY_FLOW_CONTROL<br>
explicitly. If your modem works fine AT-control wise, then probably<br>
the default baudrate MM uses was good (57600), but you should better<br>
explicitly define it. And if the data connection over PPP is not<br>
working as expected as in your case, it may indeed because of the<br>
missing ID_MM_TTY_FLOW_CONTROL (either "none", "xon-xoff" or<br>
"rts-cts").<br></blockquote><div><br></div><div><br></div><div>New udev rules as follows: <br></div><div><br></div><div>ACTION!="add|change|move|bind", GOTO="mm_whitelist_end"<br>KERNEL=="ttyS4" ENV{ID_MM_DEVICE_PROCESS}="1", ENV{ID_MM_TTY_BAUDRATE}="115200", ENV{ID_MM_TTY_FLOW_CONTROL}="rts-cts"<br>LABEL="mm_whitelist_end"</div><div><br></div><div>As you can see I'm setting ID_MM_TTY_BAUDRATE to 115200. Reason for this is, the modem is capable of autobauding up to a maximum speed of 115200bps, later on (during ppp) higher bps rates can be set.<br></div><div>I can see ModemManager talking to the modem on the AT stage without issues. So I'm assuming baudrate/flow control are fine.<br></div><div><br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> 2. I Added a gsm connection to set the APN: (<a href="http://iot.t-mobile.nl" rel="noreferrer" target="_blank">iot.t-mobile.nl</a>)<br>
> I can see in ModemManager logs how it exchanges a lot of AT commands, etc to finally launch PPP. And this is where I'm stuck.<br>
> After ppp gets launched, if I check the status of the connection using nmcli I can see it is "getting ip address" and stays like that forever.<br>
><br>
> I'm attaching the whole log of ModemManager (debug mode). Not sure what I'm missing/doing wrong.<br>
><br>
<br>
You're controlling the connection through NetworkManager, though,<br>
right? Can you reproduce it and gather both MM and NM debug logs? See<br>
<a href="https://modemmanager.org/docs/modemmanager/debugging/#daemon-debug-logs" rel="noreferrer" target="_blank">https://modemmanager.org/docs/modemmanager/debugging/#daemon-debug-logs</a><br>
<br>
-- <br>
Aleksander<br><br></blockquote><div><br></div><div>So I performed the requested test<br></div><div>Steps as follows:<br></div><div>1. Just boot my board and switch on the modem (Manual operation using GPIOSET & friends)<br></div><div>2. Start modemmanager and let it detect the modem.</div><div>3. Using nmcli I can see how the modem is detected and identified. Nmcli displays DEVICE = ttyS4, TYPE=gsm<br></div><div>4. Setup a new connection using nmcli, as follows:<br>   nmcli c add type gsm ifname ttyS4 con-name 7070_connection apn <a href="http://iot.t-mobile.nl">iot.t-mobile.nl</a><br></div><div>5. Connection now stays in "connecting (prepare)" status :(</div><div><br></div><div>Some clarifications:</div><div><br></div><div>1. The GPIO operations discussed in previous posts: This is required only before using the modem. NOT during normal operation. For now I added a systemd service which starts before modemmanager and simply performs the required operations to guarantee the modem is operational whenever modemmanager boots.<br></div><div>2. I'm attempting to connect to a "cat-m" network: Not sure how to "explain" this to ModemManager so it selects the proper band/network before attempting ppp<br></div><div>3. Baudrate: As it can be seen in the logs, AT commands are working fine at the configured baudrate, but would be great to change baudrate when starting ppp. Is this doable?<br></div><div>4. Following the "AT Commands Only" section on this site: <a href="https://docs.iotcreators.com/docs/simcom-sim7070g-waveshare-dev-kit">https://docs.iotcreators.com/docs/simcom-sim7070g-waveshare-dev-kit</a>. I can manage to ping a host from the modem.</div><div><br></div><div>So, as usual: Ideas, suggestions and test requests welcomed!<br><br></div><div>Thank you very much for your help.<br></div><div><br></div><div>     <br></div><div><br></div><div> </div></div></div>