[erlang-questions] Diameter client issue
S X
erlangprogram@REDACTED
Wed Mar 27 18:50:21 CET 2013
Hi Anders & Rudolph,
Thanks for your responses.
"5000 sec reconnect_timer is on the long side." I guess I treated milli as
micro. :)
Don't worry about the logging, as long as I can see something from the
erlang debugger window (By the way, I feel that the debugger for Window
version is better than the one for Ubuntu). And I understand that it is
kind of difficult to log everything from the diameter library.
As Anders suggested, I checked on the peer side (the diameter server in
this case) and it seems timed out waiting for CER and disconnecting the
client.
Also, I found that my wireshark wasn't set up properly to work with VPN ( I
am running it with a VPN environment) and that is properly why I didn't see
any packets going outside.
At last, I made the communication work after changing Origin-Host and
Origin-Realm on the diameter client side. And they can talk diameter now.
But don't quite understand why those two options are important for the
initial socket set-up? For the initial step, doesn't it just need server IP
and port information? Or maybe because the special implementation on this
diameter server? Is this common to a diameter application?
The other question is about diameter node, in diameter_sync module:
call(Name, Req, Max, Timeout) ->
call(node(), Name, Req, Max, Timeout).
By default, it is "nonode@REDACTED", is the node used just for representing
the erlang run time or for other purpose? How does the node information is
being used in diameter?
Many thanks!
Samuel
On Wed, Mar 27, 2013 at 5:47 AM, Anders Svensson <anders.otp@REDACTED>wrote:
> Hi Samuel.
>
> > Thanks for your reply. As my understanding also, the erlang diameter
> should
> > not care how the other peers are implemented, as long as the peers follow
> > the diameter specifications.
> >
> > But the erlang diameter library provides limited error information and
> this
> > makes it harder to analyse problems, especially for newbies.
>
> It's usually (it seems) problems with capabilities exchange that trips
> people up, and you're right that these can be a bit difficult to to
> detect: capabilities exchange will fail, the transport connection will
> be broken, and that's that. I'm a bit hesitant of logging ordinary
> (albeit failed) Diameter signaling but I'll see what I can do.
>
> > My set-up is:
> >
> > - Client (192.168.193.58) runs from an erlang run time in a virtual
> machine.
> > Just made some little changes based on the sample code:
> >
> **********************************************************************************************************************
> > -define(SVC_NAME, ?MODULE).
> > -define(APP_RAR_ALIAS, rara).
> > -define(APP_CCR_ALIAS, ccra).
> > -define(DIAMETER_DICT_CCRA, diameter_gen_rfc4006_cc).
> > -define(DIAMETER_APP_ID_CCRA, 16777238).
> > -define(DIAMETER_DICT_COMMON_NEW, diameter_gen_base_rfc6733).
> >
> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ".example.com"},
> > {'Origin-Realm', "example.com"},
> > {'Vendor-Id', 193},
> > {'Product-Name', "Client"},
> > {'Auth-Application-Id',
> [?DIAMETER_APP_ID_COMMON, ?DIAMETER_APP_ID_CCRA]},
> > {application, [{alias, ?APP_RAR_ALIAS},
> > {dictionary,
> ?DIAMETER_DICT_COMMON_NEW},
> > {module, client_cb}]},
> > {application, [{alias, ?APP_CCR_ALIAS},
> > {dictionary, ?DIAMETER_DICT_CCRA},
> > {module, client_cb_ccra}]}]).
> >
> > connect(Name, T) ->
> > diameter:add_transport(Name, {connect, [{reconnect_timer, 5000000},
> {capx_timeout, 50000000} | client(T)]}).
> >
> > client(T) ->
> > client({T, {192,168,193,58}, {10,0,10,71}, 14302}).
> >
> **********************************************************************************************************************
>
> So far, so good. (Although a 5000 sec reconnect_timer is on the long side.
> :)
>
> > - Server (10.0.10.71, port 14302) runs a diameter server remotely on a
> > Linux. It is up and running and being tested with other diameter client.
> >
> > Do the followings:
> >
> > 2> debugger:start().
> > {ok,<0.39.0>}
> > 3> diameter:start().
> > ok
> > 4> client:start().
> > ok
> > 5> client:connect(tcp).
> > {ok,#Ref<0.0.0.1210>}
> > 6> client:call().
> > {error,no_connection}
> > 7>
> >
> > The print information from the runtime doesn't say too much, it shows no
> > connection when call client:call(). In fact, when I check the debugger
> > window, there is no tcp connection being set up properly when calling
> > client:connect(tcp). Meaning the problem happened early without any
> > reminder.
> >
> > It is also wired that the debugger monitor window doesn't allow to
> > copy/paste:(, so I have to type some errors as following:
> >
> > <0.128.0> diameter_peer_fsm:init/1 exit
> > {shutdown,{'DOWN',#Ref<0.0.0.1413>process,<0.136.0>, {shutdown,
> > {tcp_closed,#Port<0.2250>}}}}
> > <0.136.0> diameter_tcp:init/1 exit {shutdown,{tcp_closed,#Port<0.2250>}}
>
> This looks like the peer is closing the connection. We're not even
> getting as far as sending CER. Are you able to see what's happening on
> the peer at all, why it's closing the connection?
>
> /Anders, Erlang/OTP
>
>
> > <0.138.0> diameter_tcp:init/1 exit {shutdown, {stop,<0.136.0>}}
> >
> > I increased the capx_timeout, since I thought might be CER timeout. No
> luck.
> >
> > There was no tcp connection being set up at all. I use the wireshark to
> > watch on the interface with the filter <ip.src==192.168.193.58> and I
> didn't
> > see any outgoing packets.
> >
> > Again, It still might be some configurations are incorrect causing the
> above
> > problem. But with the limited information, it is difficult to figure out
> > what was wrong for newbies.
> >
> > Could you provide some guidances on how to resolve this and any
> suggestions
> > on diagnosing diameter or erlang issues?
> >
> > Thanks a lot for your comments!
> >
> > Samuel
> >
> >
> >
> > On Tue, Mar 26, 2013 at 12:30 PM, Anders Svensson <anders.otp@REDACTED>
> > wrote:
> >>
> >> On Tue, Mar 26, 2013 at 3:48 PM, S X <erlangprogram@REDACTED> wrote:
> >> > Hi, Rudolph & Anders,
> >> >
> >> > Not sure your problem is resolved or not.
> >> >
> >> > I was able to use the diameter sample code with the local/remote mode,
> >> > i.e.
> >> > Start a diameter server in an erts on a pc, and start a diameter
> client
> >> > in
> >> > an erts on another pc (I use virtual machines as pcs here). They can
> >> > communicate different types of diameter messages without problems.
> >> >
> >> > However, when I try to use a diameter client (the sample code) from an
> >> > erts
> >> > to connect a diameter server which is not running within an erts
> (other
> >> > diameter server not implemented in erlang). It doesn't work(can not
> >> > build up
> >> > a connection). I am not quite familiar with the detailed
> implementation
> >> > of
> >> > the erlang diameter library now. I am feeling that the erlang diameter
> >> > relies on the erlang nodes, which means all the peers are built up
> only
> >> > on
> >> > the erts (distributed erlang runtimes). Does the erlang diameter only
> >> > work
> >> > within erlang environment? Or in order to talk to other diameter
> >> > servers,
> >>
> >> No, diameter has no idea how any peers it connects to are implemented.
> >>
> >> > does it need to write another erlang client using some functions from
> >> > the
> >> > erlang diameter library, like encode/decode? The sample client code
> >> > doesn't
> >> > work in this situation.
> >> >
> >> > I am not sure my understanding above is correct or not. Can you
> provide
> >> > some
> >> > guidance?
> >>
> >> Sure, if you provide me with an example of something that doesn't work
> >> as expected.
> >>
> >> Anders
> >>
> >>
> >> > Thanks,
> >> >
> >> > Samuel
> >> >
> >> >
> >> >
> >> > On Thu, Mar 21, 2013 at 9:00 AM, Anders Svensson <
> anders.otp@REDACTED>
> >> > wrote:
> >> >>
> >> >> One more time to the list ...
> >> >>
> >> >> On Thu, Mar 21, 2013 at 12:58 PM, Anders Svensson
> >> >> <anders.otp@REDACTED>
> >> >> wrote:
> >> >> > The problem looks to be that there's an {ssl, false} option being
> >> >> > into
> >> >> > diameter_tcp and then down to gen_tcp, which causes it to raise
> >> >> > badarg. What OTP release is this? I can't say I recall the example
> >> >> > code passing this tuple.
> >> >> >
> >> >> > /Anders, Erlang/OTP
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Mar 20, 2013 at 6:08 PM, Rudolph van Graan
> >> >> > <rvg.mailing@REDACTED>
> >> >> > wrote:
> >> >> >> Hi there,
> >> >> >>
> >> >> >> I'm trying to start up the Erlang diameter demo application
> shipped
> >> >> >> with
> >> >> >> Erlang/OTP. The issue is that, no matter what format I try, I
> can't
> >> >> >> get
> >> >> >> the
> >> >> >> client to connect to a remote diameter server.
> >> >> >>
> >> >> >> In that example, I started the application as follows:
> >> >> >>
> >> >> >> 3> diameter:start(), client:start().
> >> >> >> ok
> >> >> >>
> >> >> >> 4> client:connect({tcp,{10,151,0,166},{10,249,20,174},3868}).
> >> >> >> {ok,#Ref<0.0.0.643>}
> >> >> >>
> >> >> >> 7> client:call().
> >> >> >> {error,no_connection}
> >> >> >>
> >> >> >>
> >> >> >> Here, my local IP address is {10,151,0,166} and the remote one is
> >> >> >> {10,249,20,174}.
> >> >> >>
> >> >> >> TCP to the server is working:
> >> >> >>
> >> >> >> telnet 10.249.20.174 3868
> >> >> >> Trying 10.249.20.174...
> >> >> >> Connected to 10.249.20.174.
> >> >> >> Escape character is '^]'.
> >> >> >>
> >> >> >>
> >> >> >> I traced diameter_tcp and I can see that it is getting a badarg
> >> >> >> error
> >> >> >> somewhere:
> >> >> >>
> >> >> >> (<0.114.0>) returned from diameter_tcp:start/3 -> {ok,<0.115.0>,
> >> >> >>
> [{10,151,0,166}]}
> >> >> >> (<0.116.0>) call
> >> >> >>
> >> >> >>
> >> >> >>
> diameter_tcp:handle_info({'DOWN',#Ref<0.0.0.924>,process,<0.115.0>,badarg},{monitor,<0.114.0>,<0.115.0>})
> >> >> >> (<0.116.0>) call
> >> >> >>
> >> >> >>
> >> >> >>
> diameter_tcp:m({'DOWN',#Ref<0.0.0.924>,process,<0.115.0>,badarg},{monitor,<0.114.0>,<0.115.0>})
> >> >> >> (<0.116.0>) returned from diameter_tcp:m/2 -> ok
> >> >> >>
> >> >> >> Does anyone have an idea what I am doing wrong? My feeling is that
> >> >> >> it
> >> >> >> has to
> >> >> >> do with the local ip address. I don't understand why I even need
> to
> >> >> >> supply a
> >> >> >> local IP address and the documentation isn't very clear.
> >> >> >>
> >> >> >> Thanks,
> >> >> >>
> >> >> >> Rudolph
> >> >> >>
> >> >> >>
> >> >> >> Here is the trace:
> >> >> >>
> >> >> >> (<0.84.0>) call
> >> >> >> diameter_tcp:start_link({monitor,<0.114.0>,<0.115.0>})
> >> >> >> (<0.116.0>) call diameter_tcp:init({monitor,<0.114.0>,<0.115.0>})
> >> >> >> (<0.116.0>) call diameter_tcp:i({monitor,<0.114.0>,<0.115.0>})
> >> >> >> (<0.116.0>) returned from diameter_tcp:i/1 ->
> >> >> >> {monitor,<0.114.0>,<0.115.0>}
> >> >> >> (<0.84.0>) returned from diameter_tcp:start_link/1 ->
> {ok,<0.116.0>}
> >> >> >> (<0.115.0>) call diameter_tcp:ssl([{ssl,false},
> >> >> >> {ip,{10,151,0,166}},
> >> >> >> {raddr,{10,249,20,174}},
> >> >> >> {rport,3868},
> >> >> >> {reuseaddr,true}])
> >> >> >> (<0.115.0>) call diameter_tcp:ssl_opts([])
> >> >> >> (<0.115.0>) returned from diameter_tcp:ssl_opts/1 -> false
> >> >> >> (<0.115.0>) returned from diameter_tcp:ssl/1 -> {false,
> >> >> >> [{ssl,false},
> >> >> >>
> >> >> >> {ip,{10,151,0,166}},
> >> >> >>
> >> >> >> {raddr,{10,249,20,174}},
> >> >> >> {rport,3868},
> >> >> >>
> {reuseaddr,true}]}
> >> >> >> (<0.115.0>) call
> >> >> >>
> >> >> >>
> >> >> >>
> diameter_tcp:i(connect,#Ref<0.0.0.643>,gen_tcp,<0.114.0>,false,[{ssl,false},
> >> >> >> {ip,{10,151,0,166}},
> >> >> >> {raddr,{10,249,20,174}},
> >> >> >> {rport,3868},
> >> >> >> {reuseaddr,true}],[])
> >> >> >> (<0.115.0>) call
> >> >> >>
> >> >> >>
> diameter_tcp:i(connect,#Ref<0.0.0.643>,gen_tcp,<0.114.0>,[{ssl,false},
> >> >> >> {ip,{10,151,0,166}},
> >> >> >> {raddr,{10,249,20,174}},
> >> >> >> {rport,3868},
> >> >> >> {reuseaddr,true}],[])
> >> >> >> (<0.115.0>) call diameter_tcp:get_addr([{ip,{10,151,0,166}}],[])
> >> >> >> (<0.115.0>) call diameter_tcp:addr([{ip,{10,151,0,166}}],[])
> >> >> >> (<0.115.0>) returned from diameter_tcp:addr/2 -> {10,151,0,166}
> >> >> >> (<0.115.0>) returned from diameter_tcp:get_addr/2 ->
> {10,151,0,166}
> >> >> >> (<0.115.0>) call
> diameter_tcp:get_addr([{raddr,{10,249,20,174}}],[])
> >> >> >> (<0.115.0>) call diameter_tcp:addr([{raddr,{10,249,20,174}}],[])
> >> >> >> (<0.115.0>) returned from diameter_tcp:addr/2 -> {10,249,20,174}
> >> >> >> (<0.115.0>) returned from diameter_tcp:get_addr/2 ->
> {10,249,20,174}
> >> >> >> (<0.115.0>) call diameter_tcp:get_port([{rport,3868}])
> >> >> >> (<0.115.0>) returned from diameter_tcp:get_port/1 -> 3868
> >> >> >> (<0.115.0>) call
> >> >> >>
> diameter_tcp:gen_opts({10,151,0,166},[{ssl,false},{reuseaddr,true}])
> >> >> >> (<0.115.0>) returned from diameter_tcp:gen_opts/2 -> [binary,
> >> >> >> {packet,0},
> >> >> >>
> {active,once},
> >> >> >>
> >> >> >> {ip,{10,151,0,166}},
> >> >> >> {ssl,false},
> >> >> >>
> >> >> >> {reuseaddr,true}]
> >> >> >> (<0.82.0>) returned from diameter_tcp:start_link/1 ->
> {ok,<0.115.0>,
> >> >> >>
> >> >> >> [{10,151,0,166}]}
> >> >> >> (<0.115.0>) call
> >> >> >> diameter_tcp:connect(gen_tcp,{10,249,20,174},3868,[binary,
> >> >> >> {packet,0},
> >> >> >> {active,once},
> >> >> >> {ip,{10,151,0,166}},
> >> >> >> {ssl,false},
> >> >> >> {reuseaddr,true}])
> >> >> >> (<0.114.0>) returned from diameter_tcp:start/3 -> {ok,<0.115.0>,
> >> >> >>
> [{10,151,0,166}]}
> >> >> >> (<0.116.0>) call
> >> >> >>
> >> >> >>
> >> >> >>
> diameter_tcp:handle_info({'DOWN',#Ref<0.0.0.924>,process,<0.115.0>,badarg},{monitor,<0.114.0>,<0.115.0>})
> >> >> >> (<0.116.0>) call
> >> >> >>
> >> >> >>
> >> >> >>
> diameter_tcp:m({'DOWN',#Ref<0.0.0.924>,process,<0.115.0>,badarg},{monitor,<0.114.0>,<0.115.0>})
> >> >> >> (<0.116.0>) returned from diameter_tcp:m/2 -> ok
> >> >> >> (<0.116.0>) call
> >> >> >> diameter_tcp:x({'DOWN',#Ref<0.0.0.924>,process,<0.115.0>,badarg})
> >> >> >> (<0.116.0>) call
> >> >> >>
> >> >> >>
> >> >> >>
> diameter_tcp:terminate({shutdown,{'DOWN',#Ref<0.0.0.924>,process,<0.115.0>,badarg}},{monitor,<0.114.0>,<0.115.0>})
> >> >> >> (<0.116.0>) returned from diameter_tcp:terminate/2 -> ok
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> 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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130327/7ed3638e/attachment.htm>
More information about the erlang-questions
mailing list