<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The bind has to occur in the network.mgr.init handler. That is the point between mg_mgr_init and mg_mgr_poll.<div class=""><br class=""></div><div class="">Perhaps in the handler we can check m_connected_wifi and only bind if wifi is up? But would also need to pickup network.reconfigured and check m_connected_wifi there as well.<div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div class=""><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 29 Jan 2018, at 6:11 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">mg_bind() fails with "failed to open
listener". I haven't traced it further yet, assumed it's the
bind() that fails.<br class="">
<br class="">
Mongoose (now?) uses the standard socket API, so does not need to
handle LWIP details, or does it?<br class="">
<br class="">
I can do some more debugging to get the exact point of failure.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
Am 29.01.2018 um 02:28 schrieb Stephen Casner:<br class="">
</div>
<blockquote type="cite" cite="mid:alpine.OSX.2.21.1801281721340.55836@auge.attlocal.net" class="">
<pre wrap="" class="">Mark,
Back in November we discussed this problem of the client's half of the
connection being left open. Then as now, you commented that mongoose
sends a close event (MG_EV_CLOSE) for each open connection when the
interface went down.
It does send a close event, but not until after the wifi is already
shut down so closing the socket at that point does not send any packet
to the client. I decided to punt on that issue, though, because
manually shutting down wifi is not an important use case. The more
likely case is that wifi connectivity is lost due to motion or other
causes and in that case no close packet can be delivered anyway.
I interpreted Michael's message to be referring to a problem with
ports on the server (OVMS) end. That is, to say that mongoose didn't
clean up LWIP state properly. Michael, can you explain a bit more?
-- Steve
On Mon, 29 Jan 2018, Mark Webb-Johnson wrote:
</pre>
<blockquote type="cite" class="">
<pre wrap="" class="">I suspect that this is timing related:
OVMS > wifi mode client XXX
Starting WIFI as a client to XXX…
…
I (337100) ssh: Launching SSH Server
V (338830) ssh: Event MG_EV_ACCEPT conn 0x3ffee8b4, data 0x3ffee8cc
V (338840) ssh: Event MG_EV_RECV conn 0x3ffee8b4, data received 21
V (338840) ssh: Event MG_EV_SEND conn 0x3ffee8b4, data 0x3ffe5d90
V (338840) ssh: Event MG_EV_RECV conn 0x3ffee8b4, data received 1024
V (338850) ssh: Event MG_EV_RECV conn 0x3ffee8b4, data received 408
…
OVMS > wifi mode off
Stopping wifi station...
I (350580) ovms-mdns: Stopping MDNS service
I (350580) wifi: state: run -> init (0)
I (350590) wifi: pm stop, total sleep time: 0/11930449
I (350590) wifi: n:11 0, o:11 0, ap:255 255, sta:11 0, prof:1
I (350600) wifi: flush txq
I (350600) wifi: stop sw txq
I (350600) wifi: lmac stop hw txq
I (350600) wifi: Deinit lldesc rx mblock:4
I (351340) webserver: Stopping Web Server
I (351340) ssh: Stopping SSH Server
V (351540) ssh: Event MG_EV_CLOSE conn 0x3ffee8b4, data 0x0
V (351540) ssh: Event MG_EV_CLOSE conn 0x3ffeb468, data 0x0
I (357570) event: station ip lost
But ssh client connection is still up on my workstation. Looks like
the MG_EV_CLOSE events came in after the SSH server was stopped.
I repeated the test, but with event logging on:
OVMS > wifi mode off
Stopping wifi station...
I (34171) events: Signal(system.wifi.down)
I (34171) events: Signal(network.wifi.down)
I (34171) ovms-mdns: Stopping MDNS service
I (34171) events: Signal(network.reconfigured)
I (34171) events: Signal(network.down)
I (34171) wifi: state: run -> init (0)
I (34181) wifi: pm stop, total sleep time: 0/9603569
I (34181) wifi: n:11 0, o:11 0, ap:255 255, sta:11 0, prof:1
I (34191) wifi: flush txq
I (34191) wifi: stop sw txq
I (34191) wifi: lmac stop hw txq
I (34191) wifi: Deinit lldesc rx mblock:4
I (34191) events: Signal(system.wifi.sta.disconnected)
I (34191) events: Signal(system.wifi.sta.stop)
I (35131) events: Signal(network.mgr.stop)
I (35131) webserver: Stopping Web Server
I (35131) ssh: Stopping SSH Server
V (35331) ssh: Event MG_EV_CLOSE conn 0x3ffec138, data 0x0
V (35331) ssh: Event MG_EV_CLOSE conn 0x3ffeb768, data 0x0
MDNS exits quicker because it responds to the network.wifi.down message, while ssh uses the network.mgr.stop event. In a clean shutdown there is a difference.
Perhaps we should issue network.mgr.stop earlier? However, even if we close the connections from our end, I’m not sure if the packet would make it through to the other end before the wifi disconnects.
Regards, Mark.
</pre>
<blockquote type="cite" class="">
<pre wrap="" class="">On 29 Jan 2018, at 2:13 AM, Stephen Casner <a class="moz-txt-link-rfc2396E" href="mailto:casner@acm.org"><casner@acm.org></a> wrote:
I handled wifi shutdowns cleanly when I first implemented telnet and
ssh as their own tasks. Now that they are under Mongoose, it is out
of my control. The socket is owned by the Mongoose code.
-- Steve
On Sun, 28 Jan 2018, Michael Balzer wrote:
</pre>
<blockquote type="cite" class="">
<pre wrap="" class="">I've begun working on the webserver and noticed something that may
be correlated to this: sockets don't get closed when losing the
connection. The effect is visible on both web and telnet server (ssh
not tested). To reproduce, switch the Wifi network with an open
connection, the port will not be available until timeout.
Regards,
Michael</pre>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br class="">
<br class="">
<pre class="moz-signature" cols="144">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></div></div></body></html>