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

[Tim Watson]

Awesome, thanks or the input. I didn't realise the origins needed to differ - ill tweak those and get some tracing turned on. Will let you know how I get on come Monday.

Thanks!

Tim

On 18 Oct 2013, at 17:45, Anders Svensson <anders.otp@REDACTED> wrote:
> And one more time to the list ... /Anders
> 
> On Fri, Oct 18, 2013 at 6:43 PM, Anders Svensson <anders.otp@REDACTED> wrote:
>> Hi Tim.
>> 
>> On Fri, Oct 18, 2013 at 1:27 PM, Tim Watson <watson.timothy@REDACTED> wrote:
>>> 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)
>> 
>> Are you sure that's the right dump? There's a CER/CEA exchange in
>> frames 35 and 37, but the relay port is 60104 and the server port
>> 3868. The relay sends CER (frame 35), the server responds with a 2001
>> CEA (frame 37), and then the relay closes the connection (frame 39).
>> 
>> A bit later on there's Diameter traffic between 127.0.0.1:37291 and
>> 127.0.0.1:10601 but it looks pretty much the same: CER (frame 102),
>> CEA (frame 104), close the connection (frame 106).
>> 
>> Later still there's a relay CER (frame 118) that's unanswered and
>> causes the server to close the connection (frame 123).
>> 
>> One thing that's not quite right in your configuration is that both
>> the relay and server identify themselves with
>> Origin-Host=service.example.com. The server is another Diameter node
>> that should have its own identity. Not sure if that could be a problem
>> (don't know seagull for one) but it's not impossible. Similarly, the
>> client should also have its own identity.
>> 
>> The relay closing the connection upon reception of CEA means that
>> there's something it doesn't like. If you trace on
>> diameter_peer_fsm:terminate/2 then we should be able to see why.
>> 
>>> like so:
>>> 
>>>  <define entity="channel"
>>>    name="channel-1"
>>>    protocol="diameter-v1"
>>>    transport="trans-ip-v4"
>>>    open-args="mode=server;source=127.0.0.1:10601">
>>>  </define>
>>> 
>>> 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} =
>>>        diameter:add_transport(
>>>          ?MODULE,
>>>          {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?
>> 
>> I see the same behaviour as above: CER, CEA, close the connection.
>> 
>> Start with fixing you Origin-Host values and let's see how far that gets us.
>> 
>> Anders
>> 
>> 
>> 
>>> 
>>> 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:
>>> 
>>> <init>
>>>  <receive channel="channel-1">
>>>    <command name="CER">
>>>    </command>
>>>    <action>
>>>    <store name="ven" entity="Vendor-Id"> </store>
>>>    </action>
>>>  </receive>
>>> 
>>>  <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>
>>>      <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>
>>>    </command>
>>>  </send>
>>> </init>
>>> 
>>> 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"
>>>    name="channel-1"
>>>    protocol="diameter-v1"
>>>    transport="trans-1"
>>>    open-args="mode=client;dest=127.0.0.1:10601">
>>>  </define>
>>> 
>>> 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 though...
>>> 
>>> Thanks for helping out with this BTW - I really appreciate it.
>>> 
>>> Cheers,
>>> Tim
>>> 
>>>