[erlang-questions] Bug in epmd_srv.c?

[Klas Johansson]

Hi,

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 [1]):

* <<0>> instead of <<0, 0>> was returned when extra was <<>>
  (truncated)

* <<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.


Kind Regards,
Klas

[1] http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epmd_extra.erl
Type: application/octet-stream
Size: 2656 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20091220/665c1421/attachment.obj>