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

[Anders Svensson]

Hi Tim.

On Tue, Oct 15, 2013 at 5:32 PM, Tim Watson <watson.timothy@REDACTED> wrote:
> Putting the list back on cc...
>
> So actually, having read through someone else's adventure -
> http://erlang.org/pipermail/erlang-questions/2013-March/072918.html - I see
> that if you have multiple 'Auth-Application-Id' entries, you seem to need
> and {application, Config} tuple for each entry with the relevant dictionary.
> That's not at all what I want. I wish to 'snoop' on the AVPs and relay all
> traffic to the real diameter server. I had hoped that by just setting up
>
> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {application, [....,
> {dictionary, ?DIAMETER_DICT_RELAY}]}
>
> that I could avoid all of that.

Yes, this is the right thing to do.

> But unless I set the same list of values in 'Auth-Application-Id' on the
> erlang relay as I do on the server, the capabilities exchange seems to fail.

How do the CER/CEA messages look when it fails?

/Anders, Erlang/OTP

> Is it in fact possible to be a transparent relay/proxy in this fashion? I've
> spent the best part of 24 hours fiddling around with auth-app-ids in the
> test client / server and that's fair enough - but now the test client and
> server will happily talk directly to each other, but once the erlang relay
> gets in the middle it all falls apart. There must be some rules about how to
> configure a relay agent that I'm missing.
>
> Cheers,
> Tim
>
> On 15 Oct 2013, at 10:32, Ferenc Holzhauser wrote:
>
> Hi Tim,
>
> AFAIK the restrict_connections and use_shared_peers options are internal to
> the diameter app for the case it is distributed when connections may be
> handled on different erlang nodes.
>
> Typically if pick peer doesn't give you anything to pick from (assuming that
> peers are connected) then the remote end didn't announce support for the app
> id you're trying to send to (and/or tell that he is a jolly joker relay
> accepting anything). You being relay is not doing a lot when sending IMO.
> What did your seagull announce when connecting?
>
> BR,
> Ferenc
>
>
>
>
> On 14 October 2013 17:43, QDev <watson.timothy@REDACTED> wrote:
>>
>> Hi folks,
>>
>> Hopefully I'm being a bit dense and missing some obvious configuration
>> here, but how do I get the OTP application to relay diameter messages to
>> another (externally hosted) diameter server? I start my service with
>> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {restrict_connections,
>> false} and {use_shared_peers, true}, and then start a listener and a relay
>> to the upstream using the example peer module:
>>
>> peer:connect(?MODULE, {tcp, loopback, 13868}),
>> peer:listen(?MODULE, tcp),
>>
>> However whilst my callback module's handle_request gets called fine, when
>> it returns {relay, [{extra, [relayed]}]}, in the corresponding pick_peer/5
>> callback there are no remote (or local) peers to select from! Do I need to
>> add additional service configuration in order to relay to another diameter
>> server? The server I am trying to "forward" traffic to is *not* an
>> Erlang/OTP server btw, but some other diameter server (or as it happens in
>> this particular case, a diameter test bed server running on seagull).
>>
>> Cheers,
>> Tim
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>