[erlang-questions] Bug in epmd_srv.c?
Sun Dec 20 23:06:39 CET 2009
On Thu, Sep 3, 2009 at 11:24 PM, Dave Smith <dizzyd@REDACTED> wrote:
> Hi all,
> I've been working on a helper module to enable usage of epmd
> for things other than just nodes (i.e. poor man's zeroconf
> service). In the process, I've found some discrepancies in the
> epmd documentation and server code. I _think_ there is a bug or
> two there, but would appreciate validation by the OTP team --
> it could just be a lack of understanding on my part. :)
> First off, the docs for the distribution protocol state that
> the ALIVE2_REQ has the field "LowestVersion" followed
> by "HighestVersion". However, the implementation in
> erl_epmd.erl has them reversed as does the documentation for
> the PORT2_RESP packet. This is, I believe, a minor
> documentation bug.
Now I too have been bitten by this. This patch places the
`highest version' field before the `lowest version' field in the
docs, just as in the source code:
git fetch git://github.com/klajo/otp.git epmd_alive2req_version_ordering
> Secondly, in erts/epmd/src/epmd_srv.c:628 (R13B01), there is
> the following line:
> offset += (strlen(node->extra)-1);
> Unfortunately, if the length of the extra field is zero, this
> causes the last byte of the packet to disappear as it winds up
> decrementing "offset".
> Reading through epmd, it looks like the expectation is that the
> extra field is null-terminated --- but the docs make no mention
> of it. This is somewhat odd to me as that field is prefixed
> with a 2 byte length value in the protocol, so I see no reason
> for the implementation to require the data to be a C string. Of
> course, this may be for backwards compatibility purposes; it's
> hard to know for sure.
I stumbled upon this one as well and had a go at fixing it.
Before the change I discovered that (according to docs, fields
are a two-byte length followed by the value itself ):
* <<0>> instead of <<0, 0>> was returned when extra was <<>>
* <<0, 4, 4, 1, 2>> instead of <<0, 4, 1, 2, 3, 4>> was returned
when extra was <<1, 2, 3, 4>> (truncated and garbled; actually
the second byte of the length is duplicated)
The fix tries to address that. I'm not too sure about the fix
though, since this is in some sense not a backwards compatible
fix (since extra and it's length will be different). However,
since the previous version truncated (and garbled) the "extra"
field and erl_epmd.erl doesn't seem to care about it it might not
be that big a deal. Perhaps for some other third-party libraries
or other parts of Erlang/OTP (ei, jinterface, ...; I haven't
checked)? Also, I'm not that confident in modifying the
epmd... :-) I've attached a test case which illustrates the
problem. Get the code here:
git fetch git://github.com/klajo/otp.git epmd_port2resp_trunc_extra
I'd be happy to hear from someone who's more well-versed in the
epmd and the distribution protocol.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2656 bytes
Desc: not available
More information about the erlang-questions