Hi all,
I'm using ejabberd version 2.1.4 and would like to listen on both IP versions at the same time. While using ejabberd version 2.0.5, the prefered way was to use the inet6 keyword. The keyword is still working with version 2.1.4 but I would like to use the new syntax using the ip options. How can I do this the new way?
I tried the following, but it does not work:
{{5222, [{"::", {0,0,0,0}] }, ejabberd_c2s, [
The only option I found to use the new ip option syntax was to duplicate the code for each service. But I do not want this redundancy of course.
Any other suggestions?
I tried all the cases that
I tried all the cases that you mention, and a few more. I have Debian unstable and Erlang R13B05. In all cases I configured Tkabber to connect to the IP 127.0.0.1
Case 1: 2.0.5 with ipv4
ejabberd 2.0.5
listens in
when a client connects:
Case 2: 2.0.5 with ipv6
ejabberd 2.0.5
listens in
when a client connects:
Case 3: 2.1.4 with ipv4
ejabberd 2.1.4 with
listens in
when a client connects:
Case 4: 2.1.4 with ipv6
ejabberd 2.1.4 with
listens in
when a client connects:
Case 5: 2.1.4 with ipv6 using the old inet6 option
ejabberd 2.1.4 with
listens in
when a client connects:
Case 6: 2.1.4 with two listeners
ejabberd 2.1.4 with
crashes with this error:
While using ejabberd version 2.0.5, the prefered way was to use the inet6 keyword.
Right, it works, at least in my Debian, as seen in case 2. It works exactly the same with 2.1.4 as seen in case 4.
I'm using ejabberd version 2.1.4 and would like to listen on both IP versions at the same time.
As seen in case 4, it works similarly in 2.1.4 than case 2 of 2.0.5
The keyword is still working with version 2.1.4
Right, as seen in case 5, which provides the same result than case 4 and case 2.
I would like to use the new syntax using the ip options. How can I do this the new way?
Use the configuration of case 4, which produces a result similar to case 2.
I tried the following, but it does not work:
{{5222, [{"::", {0,0,0,0}] }, ejabberd_c2s, [
You have much imagination, because that syntax isn't mentioned anywhere. Obviously it doesn't work.
The only option I found to use the new ip option syntax was to duplicate the code for each service. But I do not want this redundancy of course.
In fact, that doesn't work, as seen in case 6.
Case 4 works for me
I would like to use the new syntax using the ip options. How can I do this the new way?
Use the configuration of case 4, which produces a result similar to case 2.
OK. I was wondering if this is the way to go because it seems to be a bit awkward from an network administrator point of view. You enable ejabberd for a port on an IPv6 address and additionally you also get it running on an IPv4 address. This kind of side effect I wouldn't expect or in some cases I even wouldn't want it.
I tried the following, but it does not work:
{{5222, [{"::", {0,0,0,0}] }, ejabberd_c2s, [
You have much imagination, because that syntax isn't mentioned anywhere. Obviously it doesn't work.
Yes ;-) This was something I hoped that it might work. I'm not really familiar with erlang but I hoped that I could specify a list of IPs.
The only option I found to use the new ip option syntax was to duplicate the code for each service. But I do not want this redundancy of course.
In fact, that doesn't work, as seen in case 6.
Right.
Thanks for your detailed explanations! I really appreciate this. I followed your suggestion of case 4 and did a test on a CentOS 5.5 system with ejabberd 2.1.4 and it works like with the inet6 option in the old days.
Kind regards,
Rubypro
It isn't ejabberd or erlang
You enable ejabberd for a port on an IPv6 address and additionally you also get it running on an IPv4 address. This kind of side effect ...
You can see in telnet of case 2 that the erlang program listens only in tcp6, in the IPv6 address.
That feature may be provided by the operating system, or the kernel, who forwards IPv4 connections to the IPv6 listener. Maybe this is a Debian thing and doesn't happen in Fedora or others; or maybe it's a Linux thing and doesn't happen in FreeBSD or others.
whishlist
You enable ejabberd for a port on an IPv6 address and additionally you also get it running on an IPv4 address. This kind of side effect ...
You can see in telnet of case 2 that the erlang program listens only in tcp6, in the IPv6 address.
I guess this is a Linux feature (not depending on the distribution as long as a 2.6 kernel is used).
Now consider an operating system where you have to explicitly specify if you want to use either IPv6 or IPv4 (exclusive or). If you where using such an operating system, then you where out of luck when you want to use ejabberd with both IP versions because you can only bind to _one_ IP address. You would have to decide if you want to bind to either IPv4 or IPv6 since you cannot specify more than one IP address and you cannot replicate the code as indicated by case 6.
Maybe I should file a whishlist entry with this kind of option.
First check Case 6 in non-linux, then report
Now consider an operating system where you have to explicitly specify if you want to use either IPv6 or IPv4 (exclusive or). If you where using such an operating system, then you where out of luck when you want to use ejabberd with both IP versions because you can only bind to _one_ IP address. You would have to decide if you want to bind to either IPv4 or IPv6 since you cannot specify more than one IP address and you cannot replicate the code as indicated by case 6.
Maybe I should file a whishlist entry with this kind of option.
Case 6 failed for me because I have that "IPv address forwarding" (or whatever it's called). In the machine that you refer, maybe case 6 works.
Before you submit a feature request, you must verify that the request makes sense, and for that you need a machine as you describe (maybe FreeBSD or Solaris work that way: find machines, install Erlang, ejabberd and test what happens).
Once you confirm the request is valid, then you can submit it to the proper project; which in this case is Erlang/OTP, which is what ejabberd uses to open the listeners in either IPv4 or 6.