[erlang-questions] Fwd: A (hopefully simple) diameter relay question

Tim Watson watson.timothy@REDACTED
Fri Oct 18 13:27:45 CEST 2013

Hi Anders,

On 10/16/2013 11:22 AM, Anders Svensson wrote:

How do the CER/CEA messages look when it fails? /Anders, Erlang/OTP

Well, here's a very strange thing. When I run the server on port 10601 and
the relay on 3868, the capabilities exchange never takes place. I just see
an ongoing cycle of TCP traffic that never makes it to full cap-ex stage.
I've attached that as no-capex. The server is configured (using seagull)
like so:

  <define entity="channel"

The relay is configured thus:

    SvcName = ?MODULE,
    SvcOpts = [{'Origin-Host', "service.example.com"},
               {'Origin-Realm', "example.com"},
               {'Vendor-Id', 193},
               {'Product-Name', "Server"},
               {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]},
               {restrict_connections, false},
               {use_shared_peers, true},
               {application, [{alias, ?MODULE},
                              {dictionary, ?DIAMETER_DICT_RELAY},
                              {module, rabbit_diameter_relay}]}],
    ok = diameter:start_service(SvcName, SvcOpts),
    {ok, _Ref} =
          {connect, [{reconnect_timer, 10000},

                     {transport_module, diameter_tcp},
                     {transport_config, [{raddr, {127,0,0,1}},
                                         {rport, 10601},
                                         {reuseaddr, true}]}]}),

    rabbit_diameter_peer:listen(?MODULE, {tcp, loopback, 3868}),

Now, if I swap the ports on which the test server and the relay are running
(both in the diameter:{add_transport,listen}/2 calls and in the seagull
configuration), then the capabilities exchange seems to be fine!!! That is
demonstrated in the attached capture good-capex. Surely that is a bug, but
is it something that I'm doing wrong?

Now when this capex *does* work, the CEA has the result code 2001, and we
get Auth-Application-Id=1, Acct-Application-Id=4. The server is configured
to reply thus:

  <receive channel="channel-1">
    <command name="CER">
    <store name="ven" entity="Vendor-Id"> </store>

  <send channel="channel-1">
    <command name="CEA">
      <avp name="Result-Code" value="2001"> </avp>
      <avp name="Auth-Application-Id" value="1"></avp>
      <avp name="Acct-Application-Id" value="4"></avp>
      <avp name="Vendor-Specific-Application-Id">
        <avp name="Vendor-Id" value="11"></avp>
        <avp name="Auth-Application-Id" value="1"></avp>
        <avp name="Acct-Application-Id" value="4"></avp>
      <avp name="Origin-Host" value="service.example.com"> </avp>
      <avp name="Origin-Realm" value="example.com"> </avp>
      <avp name="Vendor-Id" value="11"> </avp>
      <avp name="Product-Name" value="HP_HSS"> </avp>
      <avp name="Firmware-Revision" value="1"> </avp>

Now the relay and the server seem to be talking to one another, but if I
start the client, pointing to the relay, then the client seems to get
forwarded to the server - I see a new participant in the capture - but
never seems to get a CEA back for its CER. The client is definitely
pointing to the relay:

  <define entity="channel"

I wonder if the server needs to be explicitly configured to handle a CER
*after* initialisation - I have no idea if that's a seagull configuration
thing that I've done wrong, or what... I've attached the client and server
test scenarios, which are pretty short, but I'll head over to the seagull
mailing list to check if I'm doing something silly here, and maybe try
starting a test diameter server on another erlang node to eliminate another
possible issue.

I've attached a capture for the client session (attempt) too, though I'm
not sure if that's useful or not. I'd really like to understand why
capabilities exchange is failing when I swap the server and relay ports

Thanks for helping out with this BTW - I really appreciate it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131018/13b5af44/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-capex
Type: application/octet-stream
Size: 19108 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131018/13b5af44/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: good-capex
Type: application/octet-stream
Size: 4157 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131018/13b5af44/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: session-capture
Type: application/octet-stream
Size: 10627 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131018/13b5af44/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ccr-cca.client.xml
Type: text/xml
Size: 3552 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131018/13b5af44/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ccr-cca.server.xml
Type: text/xml
Size: 3304 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131018/13b5af44/attachment-0001.xml>

More information about the erlang-questions mailing list