[Ovmsdev] A promiscous wifi client
mark at webb-johnson.net
Sun Nov 19 21:54:26 HKT 2017
Strange. When I tested mongoose, I got a close event (MG_EV_CLOSE) for each open connection, when the interface went down.
> On 18 Nov 2017, at 5:05 AM, Stephen Casner <casner at acm.org> wrote:
> There is more to do on this conversion of the Telnet Console to use
> - When wifi service is shut down by command, my old implementation
> would close the connections to the clients cleanly. The new
> implementation with mongoose leaves them hanging. The way to
> improve this may lie in the shutdown steps in ovms_netmanager.
> - It looks like there may be a memory blocked leaked at each client
> disconnection. I need to find that.
> - I think I can improve how I handle the receive buffer and save
> some more RAM.
> I've also thought more about how to convert the SSH Console and will
> take a stab at that as well.
> -- Steve
> On Fri, 17 Nov 2017, Stephen Casner wrote:
>> On Thu, 16 Nov 2017, Mark Webb-Johnson wrote:
>>> We don't seem to have this issue with the webserver listener; that
>>> uses mongoose (in netmanager). That doesn't have long-lived client
>>> side connections, but the socket listen/accept functionality should
>>> be similar. Not sure how mongoose handles it internally, but the
>>> library seems quite robust.
>> Mongoose wakes up from the select() periodically to do polling so the
>> deletion of the task would not happen while in select().
>>> I'm wondering if we can migrate to use that? It would probably save
>>> a bunch of ram (as it doesn't need a task for each thread). We are
>>> mostly single-user anyway.
>> I have converted console_telnet to use mongoose and netmanager in the
>> same manner as ovms_webserver. This eliminates the TelnetServer and
>> TelnetReceiver tasks and saves about 3KB. I have kept TelnetConsole
>> as a separate task from NetManTask. I'm not convinced that combining
>> the console functionality into NetManTask is a good idea; I'm afraid
>> it would introduce some problems with interference between various
>> operations and may get into trouble with the Log() mechanism. Even if
>> not, much more surgery would be required.
>>> Perhaps a generic extension to ovms_netmanager where you give it a
>>> tcp port and an object type. Then, it listens on that port and
>>> launches objects of that type (pre-configured to receive mongoose
>>> events as appropriate) for each new connection? Have a base virtual
>>> connection class, that gets inherited by each implementation (ssh,
>>> telnet, etc).
>> I didn't do it that way for this telnet conversion, but we could
>> evolve to that if appropriate.
>> Converting ssh may be possible but would be significantly harder. The
>> libtelnet design calls for all the actual I/O (recv/send) to be done
>> outside of the library. That fits with the design of mongoose where
>> it owns that I/O. However, the wolfssh library is designed for the
>> library itself to be in control of the I/O.
>> -- Steve
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev