<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks Aleksander</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> 于2019年3月18日周一 下午6:24写道：<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 am trying to find a way to use the AT ports or mbim ports that occupied by MM as all the device ports were used by MM. eg. I want send AT command to the modem, but MM occupies the AT port. Is there any way to make MM stop using the AT port for a while but not kill the MM? To do that, maybe the application can send a D-bus signal or request a method to MM, then MM stop the AT port for a while, after application finish its work, send a D-bus info to MM, MM continue use the AT port.<br>
<br>
If the AT port is not the primary control port, you could add the<br>
ID_MM_PORT_IGNORE udev tag on the specific TTY so that MM ignores it.<br>
<br></blockquote><div>Not always ignore the port, just use it temporary. To do this may call the Modem.Command()</div>method not in debug mode.<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> And I know in MM debug mode, mmcli could use --command  to send the AT command. Is there normal mode way to send AT command from MM?<br>
<br>
Right now --command only works while in debug mode, so that the user<br>
doesn't send commands that may interfere with the control logic of<br>
MM...<br>
<br>
But truth be told, we're already allowing QMI and MBIM commands to be<br>
sent through the proxies while MM is running anyway...<br>
<br></blockquote><div>Use the MBIM and QMI commands could fix most situations. And some modem devices support AT commands over MBIM.</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">
@Dan Williams what would you think if we open up the Modem.Command()<br>
method also while not in debug mode? We could explicitly warn that MM<br>
will treat all these commands as transparent, so if the state of modem<br>
changes as a result of these commands, MM may get out of sync. Another<br>
option I'm thinking about is to make it a configure option instead.<br>
Don't know, mixed feelings.<br>
<br></blockquote><div>Maybe MM could separate Modem.Command() method from the MM main logic. Just send AT commands then receive result messages, the main logic do not listen and handle the result messages.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a></blockquote><div><br></div><div>Quincy  </div></div></div></div></div>