<div dir="ltr">Thank you, that info will help a lot. I have to postpone looking at these tests; things just got really busy here.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 5:00 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 bgcolor="#FFFFFF" text="#000000"><div class="">
<br>
<div>On 2014-06-17 16:44, Daniel Goertzen
wrote:<br>
</div>
<blockquote type="cite">
<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>
</blockquote></div>
Current build runs clean here (apart from one windows that
apparently failed all yesterday).<br>
So there might be something funky going on on your side.<br>
It would help if you list the test cases that are failing. <br>
<br>
probably a configuration issue<div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<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><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><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>
_______________________________________________<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/listinfo/erlang-patches</a><br>
</blockquote>
<br>
</blockquote>
<br>
-- <br>
</div>
</div>
/Henrik Nord Erlang/OTP<br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div><span class="HOEnZb"><font color="#888888"><pre cols="72">--
/Henrik Nord Erlang/OTP</pre>
</font></span></div>
</blockquote></div><br></div>