<div dir="ltr">Hi Anders,<div class="gmail_quote"><div bgcolor="#FFFFFF" text="#000000"><code><div class="im"><br>
      <br>
      On 10/16/2013 11:22 AM, Anders Svensson wrote:</div></code><div class="im">
    <blockquote type="cite"><code>How do the CER/CEA messages look when it fails?
        /Anders, Erlang/OTP
      </code></blockquote>
    </div><code><br>
      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:<br>
      <br>
    </code><code>  <define entity="channel"<br>
          name="channel-1"<br>
          protocol="diameter-v1"<br>
          transport="trans-ip-v4"<br>
          open-args="mode=server;source=<a href="http://127.0.0.1:10601" target="_blank">127.0.0.1:10601</a>"><br>
        </define><br>
      <br>
      The relay is configured thus:<br>
      <br>
          SvcName = ?MODULE,<br>
          SvcOpts = [{'Origin-Host', "<a href="http://service.example.com" target="_blank">service.example.com</a>"},<br>
                     {'Origin-Realm', "<a href="http://example.com" target="_blank">example.com</a>"},<br>
                     {'Vendor-Id', 193},<br>
                     {'Product-Name', "Server"},<br>
                     {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]},<br>
                     {restrict_connections, false},<br>
                     {use_shared_peers, true},<br>
                     {application, [{alias, ?MODULE},<br>
                                    {dictionary, ?DIAMETER_DICT_RELAY},<br>
                                    {module, rabbit_diameter_relay}]}],<br>
          ok = diameter:start_service(SvcName, SvcOpts),<br>
          {ok, _Ref} =<br>
              diameter:add_transport(<br>
                ?MODULE,<br>
                {connect, [{reconnect_timer, 10000},<div class="im"><br>
                           {transport_module, diameter_tcp},<br>
                           {transport_config, [{raddr, {127,0,0,1}},<br></div>
                                               {rport, 10601},<br>
                                               {reuseaddr, true}]}]}),<br>
      <br>
          rabbit_diameter_peer:listen(?MODULE, {tcp, loopback, 3868}),<br>
          ....<br>
      <br>
      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?<br>
      <br>
      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:<br>
      <br>
      <init><br>
        <receive channel="channel-1"><br>
          <command name="CER"><br>
          </command><br>
          <action><br>
          <store name="ven" entity="Vendor-Id"> </store><br>
          </action><br>
        </receive><br>
      <br>
        <send channel="channel-1"><br>
          <command name="CEA"><br>
            <avp name="Result-Code" value="2001"> </avp><br>
            <avp name="Auth-Application-Id" value="1"></avp><br>
            <avp name="Acct-Application-Id" value="4"></avp><br>
            <avp name="Vendor-Specific-Application-Id"><br>
              <avp name="Vendor-Id" value="11"></avp><br>
              <avp name="Auth-Application-Id"
      value="1"></avp><br>
              <avp name="Acct-Application-Id"
      value="4"></avp><br>
            </avp><br>
            <avp name="Origin-Host" value="<a href="http://service.example.com" target="_blank">service.example.com</a>">
      </avp><br>
            <avp name="Origin-Realm" value="<a href="http://example.com" target="_blank">example.com</a>">
      </avp><br>
            <avp name="Vendor-Id" value="11"> </avp><br>
            <avp name="Product-Name" value="HP_HSS"> </avp><br>
            <avp name="Firmware-Revision" value="1"> </avp><br>
          </command><br>
        </send><br>
      </init><br>
      <br>
      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:<br>
      <br>
        <define entity="channel"<br>
          name="channel-1"<br>
          protocol="diameter-v1"<br>
          transport="trans-1"<br>
          open-args="mode=client;dest=<a href="http://127.0.0.1:10601" target="_blank">127.0.0.1:10601</a>"><br>
        </define><br>
      <br>
      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.<br>
      <br>
      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 though...<br>
      <br>
      Thanks for helping out with this BTW - I really appreciate it.<br>
      <br>
      Cheers,<br></code></div><div bgcolor="#FFFFFF" text="#000000"><code>Tim<br><br><br>
      
      
      
      
      
      
      
    </code></div></div></div>