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