<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

And can't the modem report the disconnection status right away, and only<br>
let the bearer afterwards decide whether it wants to disconnect right<br>
away or defer the disconnection a bit? That would still keep the logic<br>
within the bearer; and the modem object is just the receiver of the<br>
unsolicited message which forwards the info to the bearer, which is the<br>
one applying the logic.<br>
<br></blockquote><div><br></div><div>I'd like to address the deferred disconnection in a follow-up patch. How do you think about patch v3?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


If we get a NDISSTAT saying we're disconnected by the network and we<br>
cannot act right away, maybe we can NDISTATQRY? ourselves for some time<br>
to see when we really got disconnected? Or are the responses of these<br>
NDISSTATQRY? queries also unreliable? Or maybe we could set the bearer<br>
in 'disconnecting' state until we make sure that the bearer is fully<br>
disconnected after some seconds?<br></blockquote><div><br></div><div>Probably. I need to run some tests to see if NDISTATQRY? can be used to confirm ^NDISSTAT.</div></div></div></div>