ejabberd - Comments for "Listen on IPv4 and IPv6 interface"

First check Case 6 in non-linux, then report

mfoss — Mon, 02 Aug 2010 14:24:23 +0000

rubypro wrote:

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.

whishlist

rubypro — Sat, 31 Jul 2010 20:24:42 +0000

badlop wrote:

rubypro wrote:

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).

Maybe I should file a whishlist entry with this kind of option.

It isn't ejabberd or erlang

mfoss — Wed, 28 Jul 2010 09:19:23 +0000

rubypro wrote:

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.

Case 4 works for me

rubypro — Fri, 23 Jul 2010 16:37:42 +0000

badlop wrote:

rubypro wrote:

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.

badlop wrote:

rubypro wrote:

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.

badlop wrote:

rubypro wrote:

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

I tried all the cases that

mfoss — Fri, 23 Jul 2010 11:15:54 +0000

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

{5222, ejabberd_c2s, [

listens in

$ netstat -nl | grep 5222
tcp        0      0 127.0.0.1:5222          0.0.0.0:*               LISTEN

when a client connects:

=INFO REPORT==== 23-Jul-2010::12:45:50 ===
I(<0.290.0>:ejabberd_listener:116) : (#Port<0.4227>)
Accepted connection {{127,0,0,1},38674} -> {{127,0,0,1},5222}

Case 2: 2.0.5 with ipv6

ejabberd 2.0.5

{5222, ejabberd_c2s, [ inet6,

listens in

$ netstat -nl | grep 5222
tcp6       0      0 :::5222                 :::*                    LISTEN

when a client connects:

=INFO REPORT==== 23-Jul-2010::12:48:18 ===
I(<0.262.0>:ejabberd_listener:116) : (#Port<0.4160>)
Accepted connection {{0,0,0,0,0,65535,32512,1},38691} -> {{0,0,0,0,0,65535,32512,1},5222}

Case 3: 2.1.4 with ipv4

ejabberd 2.1.4 with

{{5222, "0.0.0.0"}, ejabberd_c2s, [

listens in

$ netstat -nl | grep 5222
tcp        0      0 0.0.0.0:5222            0.0.0.0:*               LISTEN

when a client connects:

=INFO REPORT==== 23-Jul-2010::12:40:45 ===
I(<0.387.0>:ejabberd_listener:232) : (#Port<0.4018>)
Accepted connection {{127,0,0,1},59667} -> {{127,0,0,1},5222}

Case 4: 2.1.4 with ipv6

ejabberd 2.1.4 with

{{5222, "::"}, ejabberd_c2s, [

listens in

$ netstat -nl | grep 5222
tcp6       0      0 :::5222                 :::*                    LISTEN

when a client connects:

=INFO REPORT==== 23-Jul-2010::12:41:14 ===
I(<0.390.0>:ejabberd_listener:232) : (#Port<0.4034>)
Accepted connection {{0,0,0,0,0,65535,32512,1},59673} -> {{0,0,0,0,0,65535,32512,1},5222}

Case 5: 2.1.4 with ipv6 using the old inet6 option

ejabberd 2.1.4 with

{5222, ejabberd_c2s, [ inet6,

listens in

$ netstat -nl | grep 5222
tcp6       0      0 :::5222                 :::*                    LISTEN

when a client connects:

=INFO REPORT==== 23-Jul-2010::13:07:45 ===
I(<0.368.0>:ejabberd_listener:232) : (#Port<0.4059>)
Accepted connection {{0,0,0,0,0,65535,32512,1},48339} -> {{0,0,0,0,0,65535,32512,1},5222}

Case 6: 2.1.4 with two listeners

ejabberd 2.1.4 with

{{5222, "0.0.0.0"}, ejabberd_c2s, [
{{5222, "::"}, ejabberd_c2s, [

crashes with this error:

=ERROR REPORT==== 23-Jul-2010::12:36:25 ===
E(<0.388.0>:ejabberd_listener:463) : Failed to open socket:
  {5222,ejabberd_c2s,[inet6,{ip,{0,0,0,0,0,0,0,0}}]}       
Reason: IP address and port number already used: :: 5222

rubypro wrote:

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.

rubypro wrote:

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

rubypro wrote:

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.

rubypro wrote:

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.

rubypro wrote:

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.

rubypro wrote:

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.