Re: [lwip-devel] SNMPv3 implementation WIP

[Dirk Ziegelmeier]

Hi Elias,

something like weak compiler symbols or attributes/pragmas is not portable and cannot be used.

It is important that SNMP remains compilable without the crypto stuff, and SHOULD still be compilable as an SNMPv2 stack - the v3 stuff may be too heavyweight for most users - this is the *lw*IP stack.

What I meant by creating a wrapper for mbed TLS is something like a file snmp_crypto_mbedtls.c which is the _only

​_​

file

​ in SNMP agent​

to include mbed TLS specific headers. All functions exported by this file must not have any mbedTLS dependencies. The SNMP stack ha

​s​

 

​s​

nmp_crypto.h which defines function prototypes an actual implementation like snmp_crypto_mbedtls.c has to provide. This (

​hopefully) makes possible that there can be a snmp_crypto_wolfssl.c or

​whatever in the future.

​There is surely snmp_crypto_mbedtls.h which is _only_ inc​luded by application code, since initialization and setting the certs does not need to be abstracted away - the application knows which crypto lib was chosen anyway.

Dirk

--
Dirk Ziegelmeier * address@hidden * http://www.ziegelmeier.net

On Fri, Mar 4, 2016 at 9:35 PM, Elias Önal <address@hidden> wrote:

Hey Dirk,

and thanks for the warm welcome! I feel like having a layer of abstraction is reasonable, especially given that some platforms support many of the algorithms in hardware. So how would you like the wrapper? In my opinion it's of advantage if one can still build SNMPv3 support out of the box and without cryptographic libraries or persistent storage requirements. Therefore I would provide some non-standards-compliant default implementations. I'd suggest using either __weak symbols for those, or a #define to switch over to a user provided header. Though since __weak is a compiler feature it might not be compatible with the goals of LwIP.
Also I didn't really understand what you specifically meant when you said you'd like to avoid including mbedTLS headers in the actual implementation. I guess including them in lwipopts.h would be a bad idea, but I think it could be acceptable to have something along the lines of '#define LWIP_DES_HEADER "mbedtls/des.h"', followed by an "#include LWIP_DES_HEADER" inside the file handling the cryptography. Do you disagree?
Then again I feel a bit like the wrapper is outside the scope of what I'm trying to focus on right now. For a wrapper it would be more appropriate to be part of core instead of apps. In turn the ppp code could make use of it and wouldn't have to hardcode either polarSSL or mbedTLS. I'm open to discussing as well as working on this, though I'd prefer finishing SNMPv3 first.

-Elias

On 05/03/16 03:20, Dirk Ziegelmeier wrote:

Hi Önal,

nice to hear you are working on SNMPv3!

The new version of the stack was mainly developed at Pepperl+Fuchs by Martin Hentschel for a Profinet device. I wrote minor parts of it, but I maintain it in lwIP. I guess mbed TLS is a good lib to use with lwIP. Maybe Sylvain (PPP maintainer) has the time to move over from polar SSL to it, too.

If you want to have an abstraction of the mbed TLS, I would prefer a wrapper around it instead of #defines, since this will be more flexible when you want to use another library. And it would be great to avoid #including mbed TLS headers in the actual implementation.

Maybe even wrapper functions for engine boot count are also better to avoid cluttering lwipopts.h even more. SNMP and especially SNMP with encryption is so resource demanding in code and CPU cycles that you don't need to save a few bytes by substituting a wrapper call by #defines. If someone wants these features, he needs adequate resources for it.

If you have question about the stack, feel free to contact me, maybe even privately if the questions are not

​ interesting or too detailed for the rest of the list.

Ciao
Dirk

--
Dirk Ziegelmeier * address@hidden * http://www.ziegelmeier.net

On Fri, Mar 4, 2016 at 2:20 PM, Elias Önal <address@hidden> wrote:

I did notice the changes, that's why I'd like to avoid conflicts and upstream further additions like the new MIB iteratively. I've started developing against commit 6650eb4cd2f22a081995abb7f1a508fdd57275ac from Tue Feb 23.

-Elias

On 04/03/16 21:05, Simon Goldschmidt wrote:

Elias Önal wrote:

Last week I've started implementing SNMPv3

I hope you started this against master tip, there have been quite a few changes to SNMP recently.

The normal way to go would be to post a patch to http://savannah.nongnu.org/projects/lwip/


Simon

_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel

_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel

_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel

_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel