@lextm Are you opposed to adding AES support for netcoreapp via Bouncy Castle?
Hi! even if the library supports SNMP v3, is it still compatible with v2c? AFAIK, v3 only adds security on top of the previous version. Is the security layer just an opt-in functionality through configuration?
@mattzink no plan to use Bouncy Castle, but the architecture allows you to implement your own IPrivacyProvider.
@fleed Try it. You can only use v2c if you like. But "v3 only adds security on top of the previous version" is not true, as it has significantly changed the packet format to support USM (similar to v1/v2c) and other security models (which look different).
@lextm I will, thank you. In forced to use v2c (railway industry)
What's the thinking behind not building the BouncyCastle package anymore? This means SharpSnmpLib isn't useful for .NET Core anymore
@lextm I am curious why you decided to change this? .NET Core is the most popular runtime for server applications, SNMP v3 had become the defacto version, and AES/DES are the most common ciphers. So now your project won't support the most common use case for potential users unless they compile something themselves? Since there is no cost for the NuGet storage of the artifacts, and your are going to continue to maintain the code as samples, I just can't fathom why you would make this decision?
@mattzink The decision is that LeXtudio or me won't provide any bug fix support services to that part of the code base. Shipping a NuGet package might give an inappropriate assumption. Besides, any third party can publish such packages on NuGet.org if they like (including you), if such packages are really needed for certain applications, but again technical support should come from the publisher. You should be aware that many NuGet.org packages come in this way (like from Microsoft samples) and are not published by the original vendors (Microsoft for example). I am not creating something new, but simply following the rules.
@lextm I'm using #Snmp and facing an issue of ContextEngineId and ContextName not being set for V3 traps. Some SNMP Manager tools seem sensitive to those two fields with regard to accepting V3 traps. I'm wondering if those two fields could be exposed through TrapV2Message public constructors or whether the internal constructor which is used in unit tests through internal visible, could be made public in next release. Thanks.
@_mrinaldas_twitter You might use your own fork temporarily. There was a pull request to add such, but not yet finished lextudio/sharpsnmplib#8
@lextm Thank you very much. I shall use forked version. Changes in pull request looks fairly safe and adds flexibility of changing EngineId alongside addressing the ContextEngineId and ContextName. It would be great if the PR is completed before next release. Thank you for the great work on the #Snmp library. Much appreciated.