Support use general modem (e.g SIM800 with CMUX) in the driver cellular modem #78269
Comments
|
Hi @chihosin! We appreciate you submitting your first issue for our open-source project. 🌟 Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙 |
|
This frame is not a valid as it is not encapsulated: The frame should be: This may be because of some special rules in the PPP protocol, or it is just a bug in the simcom firmware. In either case, the modem subsystem expects all PPP packets to be encapsulated at this time. |
|
I found this spec https://datatracker.ietf.org/doc/html/rfc1661#section-2 of the PPP protocol, maybe you can find something in there which allows for unencapsulated packets, which we can then implement in |
Thank you for your response. It seems that I have found the function causing the PPP connection process to stall. The issue appears to be the unrecognized PPP protocol at this point. I’ll try to resolve it when I have time.
|
|
Hi @chihosin, This seem that ppp frame is invalid |
I have resolved the issue, but this PPP problem is caused by Simcom’s Modem PPP program design being different from the general protocol. The 0x03 instruction was not correctly encapsulated. The method I am currently using is not very elegant and requires further research before submitting a PR. |
|
Thank you so much for your explanation! |
@bienxanh1901 Try this patch? I already use the PPP function of the A7680C normally. |
|
@chihosin @bjarki-andreasen @bienxanh1901 PS. Sorry for all of the edits, it's been a rough morning for me 😅 . We're not configuring LCP Async-Control-Character-Map (ACCM) (https://www.rfc-editor.org/rfc/rfc1662.html#section-7.1) and based on the specification it doesn't need to escape The modem actually sends that ACCM is set to We reject this Configuration-Request, however, it is possible they are using It shouldn't be too difficult to add LCP ACCM negotiation to LCP Configure-Request (https://datatracker.ietf.org/doc/html/rfc1661#section-5.1) as we already do this for MRU. |
|
Modem: SIMCOM A7680C The same chipset is used in Quectel EG915N and Quectel EC200N. Maybe this will be helpful. |
|
Here's the patch to negotiate ACCM. |
|
Same issue here with other SIMCOM modem (A7672SA): #89455. I wish I found this issue earlier. Also had to disable PAP ( My understanding is that the zephyr driver expects Does the zephyr PPP driver explicitly send an ACCM option telling the modem that Actually a weird thing is that the driver is "expecting" 0x7d, which doesn't make a lot of sense to me. Normally, you don't have a way to know in advance that the next byte will necessarily be an escape byte ( I basically learned about PPP today so I might be wrong... |
|
Here's my attempt at a small refactor of the modem PPP code: olalonde/sdk-zephyr-old@v3.7.99-ncs2-1...olalonde:sdk-zephyr:fix-78269 Escaped bytes are handled at the top since they can appear anywhere within a frame (at least, that's my understanding). I tested the updated code with my SIMCOM modem and it works :) If @bjarki-andreasen can confirm my understanding of escaped bytes and my approach is correct, I could write a pull request on the main Zerphyr repository. |
|
According to RFC:
My patch does not yet do the first part yet (removing bytes flagged by ACCM) but it implements the second part: "each Control Escape octet is also removed, and the following octet is exclusive-or'd with hexadecimal 0x20, unless it is the Flag Sequence (which aborts a frame).". The current code doesn't handle escaped byte for the address field and for the control field, it ONLY accepted the escaped sequence |
|
The default ACCM is 0xffffffff, which means all control characters MUST be mapped. To catch issues early, we adhere strictly to this in the modem_ppp module. The SIMCOM modem apparently uses a different ACCM. The optimal solution is to keep things simple, if the modem tries to configure an ACCM different than default, reject it, and on the other side, we should probably support configuring it, and ensure the modem uses the default ACCM. Changing the modem_ppp module to be even more permissive (we already don't check FCS, which we probably should) is an ok compromise for now I think, but really, we should be enforcing ACCM to the default, and be checking FCS. With the changes in olalonde/sdk-zephyr-old@v3.7.99-ncs2-1...olalonde:sdk-zephyr:fix-78269 we are just assuming that the byte probably did not need to be escaped, as opposed to, "this is an obvious bit error" :) Nice work figuring this out BTW :) One note, bit errors are very unlikely when receiving PPP packets if we use CMUX, given there, we are definately checking FCS to make "more" sure that the data we receive over UART before unpacking and passing it to modem_ppp is what we expect. |
If we don't have a handler for a specific option, it is rejected by default. Modems generally try to set The modem I have doesn't have this issue and the OP has disappeared for a few weeks. @olalonde perhaps you could test if my ACCM patch solves your issue? I have pre-tested on my board and it negotiates it correctly: |
|
Ublox and Quectel modems seem to stick to 0xffffffff, guess there is a reason there is an option to negotiate it :) |
|
@vytvir sorry I missed your patch earlier. I tested it and it works 👍 (simcom A7672SA). |
|
It seems that using an ACCM of [0] assuming uniform distribution of bytes, transmitting all 256 bytes requires 256+2 bytes (because 0x7D, 0x7E are always escaped regardless of ACCM). with ACCM set to |
Just to confirm, does this fix your original issue without applying your changes to handling escaped bytes? I guess it still makes sense to apply these changes to be a bit more explicit with regards to which ACCM we want, but I am also interesting if this fixes the problem that you and OP described originally. It would give some logic to how these modems operate. |
Yes, it does. Presumably the modem accepts the ACCM config and escapes the bytes as expected right? |
Yes, this was my suspicion all along. Created the PR here #89580. |
Is your enhancement proposal related to a problem? Please describe.
Support use general modem (e.g SIM800 with CMUX) in the driver cellular modem.
Describe the solution you'd like
In version 3.6, the gsm_modem driver worked correctly, but now it is not functioning properly with the cellular_modem. I tried adding a code snippet based on the SIM7080 to support SIM800’s initialization commands, but even after removing the PAP authentication part, it still fails to connect to the network.
Describe alternatives you've considered
Additional context
Here is the log after running the modified code.
The text was updated successfully, but these errors were encountered: