<div dir="ltr">This isn't the most interesting corner of OTP and I submitted this as R17 was heading out the door, so I can see how this would be forgotten. ;)<div><br></div><div><br></div><div>I could use a hint: When I run the current SNMP tests I get a number of failures...</div>
<div><br></div><div><font face="courier new, monospace">Testing tests.snmp_test: TEST COMPLETE, 359 ok, 15 failed, 46 skipped of 420 test cases</font><br></div><div><br></div><div>... Is this normal, or is there something broken on my system that I need to fix before proceeding?</div>
<div><br></div><div><br></div><div>My erlang is...</div><div><br></div><div><div><font face="courier new, monospace">goertzen@ubuntu64 ~/otp/release/tests/test_server [(detached from OTP-17.0.2)]</font></div><div><font face="courier new, monospace">$ $ERL_TOP/bin/erl</font></div>
<div><font face="courier new, monospace">Erlang/OTP 17 [erts-6.0.1] [source-deacab9] [64-bit] [smp:3:3] [async-threads:10] [hipe] [kernel-poll:false]</font></div><div><font face="courier new, monospace"><br></font></div><div>
<font face="courier new, monospace">Eshell V6.0.1 (abort with ^G)</font></div><div><font face="courier new, monospace">1> </font></div></div><div><br></div><div><br></div><div>Thanks,</div><div>Dan.</div><div><br></div>
<div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 6:58 AM, Henrik Nord <span dir="ltr"><<a href="mailto:henrik@erlang.org" target="_blank">henrik@erlang.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On 2014-06-17 13:16, Raimo Niskanen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Jun 16, 2014 at 08:28:59AM -0500, Daniel Goertzen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ping.<br>
<br>
Has this patch gone anywhere? I was thinking of adding tests and turning<br>
this into a github pull request if that would help this patch get in.<br>
</blockquote>
Yes. Absolutely. Test cases would help us accept the patch.<br>
And a pull request I guess would also not hurt although should<br>
not be essential.<br>
</blockquote></div>
As Raimo stated, it should not be essential. Although this mailing list, and patches sent to it,<br>
are manually handled and could be missed.<br>
Pull requests are automatically added to our backlog of open source contributions.<br>
(if they pass some rudimentary tests, such as compiling etc)<br>
<br>
Our apologies for missing this for so long.<div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Tue, Feb 25, 2014 at 11:56 AM, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
wrote:<br>
The SNMP agent AES initialization vector calculation is definitely wrong.<br>
The IV is composed from the authoritative engine boots, engine time, and a<br>
random locally generated number. The agent is currently always using the<br>
*local* engine to get engine boots and engine time, which happens to be<br>
correct for GET, SET, and TRAP, but is wrong for INFORM.<br>
<br>
The attached patch fixes it. When composing a packet for transmission,<br>
the existing code collects the correct engine parameters, so this patch<br>
just uses those for the AES IV instead of going off and getting the wrong<br>
local engine params. The patch looks bigger than it really is because the<br>
order of packet composition had to be changed slightly.<br>
<br>
With this patch applied, I am able to send AES encrypted informs. AES<br>
encrypted traps also continued to work.<br>
<br>
Cheers,<br>
Dan.<br>
<br>
<br>
On Mon, Feb 24, 2014 at 4:57 PM, Daniel Goertzen <<br>
<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am struggling to get SNMP informs with AES privacy working. I have no<br>
problems with DES privacy on informs.<br>
<br>
In snmpa_usm.erl I see that the *local engine* boots and time is passed<br>
to snmp_usm:aes_encrypt() which forms part of the IV....<br>
<br>
<br>
<br>
However RFC 3826 states that the *authoritative* engine boots and time<br>
should be used, and in the case of informs the authoritative engine is the<br>
inform target engine, not the local engine....<br>
<br>
[from RFC 3826]<br>
<br>
3.1.2.1. AES Encryption Key and IV<br>
<br>
The first 128 bits of the localized key Kul are used as the AES<br>
encryption key. The 128-bit IV is obtained as the concatenation of<br>
the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP<br>
engine's 32-bit snmpEngineTime, and a local 64-bit integer. The 64-<br>
bit integer is initialized to a pseudo-random value at boot time.<br>
<br>
<br>
<br>
Could this be why AES privacy is not working for informs?<br>
<br>
Dan.<br>
<br>
</blockquote>
<br>
</blockquote>
______________________________<u></u>_________________<br>
erlang-patches mailing list<br>
<a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-patches</a><br>
</blockquote>
<br>
</blockquote>
<br>
-- <br></div></div>
/Henrik Nord Erlang/OTP<br>
<br>
</blockquote></div><br></div>