[erlang-bugs] diameter_transport any/loopback atoms not accepted
anders.gs.svensson@REDACTED
anders.gs.svensson@REDACTED
Mon Feb 27 12:56:39 CET 2017
Ah, you're right, I was looking at the wrong address.
There's probably no good reason why any|loopback shouldn't be
accepted, but I'll have to take a closer look.
Anders
Ferrer Guasch Vicent writes:
> Hi,
>
> This is the documentation thread I used to get to that conclusion. The TCP parameter is equivalent.
> Rgds,
> Vicent
>
> According to
> http://erlang.org/doc/man/diameter.html#add_transport-2
> -> Opt = transport_opt()
>
> http://erlang.org/doc/man/diameter.html#transport_opt
> -> {transport_config, term(), Unsigned32() | infinity}
> Term passed as the third argument to the start/3 function of the relevant transport module in order to start a transport process.
>
> http://erlang.org/doc/man/diameter_sctp.html#start-3
> -> Opt = OwnOpt | SctpOpt
> OwnOpt = {raddr, inet:ip_address()} | {rport, integer()} | {accept, Match}
> SctpOpt = term()
> -> Remaining options are any accepted by gen_sctp:open/1, with the exception of options mode, binary, list, active and sctp_events. Note that options ip and port specify the local address and port respectively.
>
> http://erlang.org/doc/man/gen_sctp.html#open-1
> -> Opts = [Opt]
> Opt =
> {ip, IP} |
> {ifaddr, IP} |
> inet:address_family() |
> {port, Port} |
> {type, SockType} |
> option()
> IP = inet:ip_address() | any | loopback
>
>
>
> > -----Original Message-----
> > From: anders.gs.svensson@REDACTED
> > [mailto:anders.gs.svensson@REDACTED]
> > Sent: 27. helmikuuta 2017 13:35
> > To: erlang-bugs@REDACTED
> > Subject: Re: diameter_transport any/loopback atoms not accepted
> >
> > Hi Vincent.
> >
> > Neither diameter_tcp nor diameter_sctp document any|loopback as
> > acceptable that I can see: they require an inet:ip_address(), neither or which
> > is an atom. Where are you looking?
> >
> > That said, I'm not sure offhand why they don't/shouldn't handle these.
> >
> > Anders, Erlang/OTP
> >
> >
> > erlang-bugs-request@REDACTED writes:
> > >
> > > Hello,
> > >
> > > I am using erlang 19.2.3. I have detected that when adding a transport to
> > the diameter service, the options {ip, any} or {ip, loopback} are not
> > accepted, even though it is defined on the spec "IP = inet:ip_address() | any
> > | loopback"
> > > For example:
> > >
> > > Opts = [{transport_module, diameter_sctp},
> > > {transport_config, [ {ip, any]}],
> > > {ok, _T} = diameter:add_transport(?SERVER, {listen, Opts}),
> > >
> > > This happens with both diameter_sctp and diameter_tcp, you can check
> > the errors given bellow.
> > > Rgds,
> > > Vicent
> > >
> > > TCP:
> > > {error,
> > > {invalid_address,
> > > [{diameter_lib,ip,1,[{file,"base/diameter_lib.erl"},{line,287}]},
> > > {diameter_lib,ipaddr,1,[{file,"base/diameter_lib.erl"},{line,270}]},
> > >
> > {diameter_tcp,get_addr,2,[{file,"transport/diameter_tcp.erl"},{line,387}]},
> > > {diameter_tcp,i,1,[{file,"transport/diameter_tcp.erl"},{line,255}]},
> > > {diameter_tcp,init,1,[{file,"transport/diameter_tcp.erl"},{line,195}]},
> > > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}
> > > ]
> > > }
> > > } in diameter_tcp:init/7 line 293
> > >
> > > SCTP:
> > > {error,
> > > {invalid_address,
> > > [{diameter_lib,ip,1,[{file,"base/diameter_lib.erl"},{line,287}]},
> > > {diameter_lib,ipaddr,1,[{file,"base/diameter_lib.erl"},{line,270}]},
> > > {diameter_sctp,'-addrs/2-lc$^1/1-0-
> > ',1,[{file,"transport/diameter_sctp.erl"},{line,325}]},
> > > {diameter_sctp,addrs,2,[{file,"transport/diameter_sctp.erl"},{line,325}]},
> > > {diameter_sctp,open,3,[{file,"transport/diameter_sctp.erl"},{line,312}]},
> > > {diameter_sctp,i,1,[{file,"transport/diameter_sctp.erl"},{line,223}]},
> > > {diameter_sctp,init,1,[{file,"t..."},...]},...]
> > > }
> > > } in diameter_sctp:s/4 line 151
> > >
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > erlang-bugs mailing list
> > > erlang-bugs@REDACTED
> > > http://erlang.org/mailman/listinfo/erlang-bugs
> > >
> > >
> > > End of erlang-bugs Digest, Vol 256, Issue 2
> > > *******************************************
More information about the erlang-bugs
mailing list