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

[Anders Svensson]

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