[Ovmsdev] A promiscous wifi client

[Mark Webb-Johnson]

Strange. When I tested mongoose, I got a close event (MG_EV_CLOSE) for each open connection, when the interface went down.

Regards, Mark.

> 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
> mongoose:
> 
>  - 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
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171119/bc7bfe95/attachment.htm>