s2s_proxy - S2S Proxying

Name: s2s_proxy
Purpose: S2S proxying support
Author: Evgeniy Khramtsov
Type: Patch
Requirements: ejabberd 1.1.3 or ejabberd 2.0.0
Download:

How to apply the patch

  1. Download the patch to the ejabberd source code directory, for example /home/admin/ejabberd-1.1.3
  2. Apply the patch:
    $ patch -p1<../s2s_proxy-1.1.3.patch
    patching file src/ejabberd_config.erl
    patching file src/ejabberd_s2s.erl
    patching file src/ejabberd_s2s_in.erl
    patching file src/mod_s2s_proxy.erl

Related Links

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Multiple vhosts

There is a bug in the s2s proxy patch that prevents ejabberd from working properly when virtual hosts a re involved. I've tracked the problem down mostly and also have a fix. However I wonder if that fix makes the server vulnerable to dns spoofing or the like.

When running the s2s proxy patch in a setup where there is one host in the local network and two virtual hosts are remote, on the same server, and the connection between the local and remote server goes through an ejabberd proxy, strange things will happen.

This seems to be due to the fact, that in ejabberd_s2s_in.erl a field auth_domain is stored. And that field always contains the name of one virtual host - the first one that made the connection it seems.

Now, the proxy patch ( http://tkabber.jabber.ru/files/contributions/s2s_proxy-2.0.0.patch ) (and also the original code before, but in a different way) will check if the domain mentioned in the xml-message will match the one in auth_domain.

This will obviously fail with the second virtual host and the incoming messages won't be routed htrough.

The following code will fix this. But probably this is the wrong thing to do:

diff -Naur src/ejabberd_s2s_in.erl src2/ejabberd_s2s_in.erl
--- src/ejabberd_s2s_in.erl	2008-04-10 20:42:45.000000000 +0200
+++ src2/ejabberd_s2s_in.erl	2008-05-23 04:14:53.000000000 +0200
@@ -417,9 +417,15 @@
 				true ->
 				    case lists:member(AuthDomain, [LFrom, ProxyServer]) of
 					true ->
-					    route_stanza(Name, From, To, NewEl);
-					false ->
-					    error
+                                           route_stanza(Name, From, To, NewEl);
+                                        false ->
+                                          case ?DICT:find({LFrom, LTo},
+                                             StateData#state.connections) of
+                                          {ok, established} ->
+                                              route_stanza(Name, From, To, NewEl);
+                                          _ ->
+                                            error
+					  end
 				    end;
 				false ->
 				    case lists:member(LFrom, MyDomains) of

Since the original code also checks auth_domain, maybe this could also be fixed in ejabberd itself.

I could probably provide a proper patch, if I had a little more knowledge on how a few things work. Specifically, I wonder why auth_domain is important and how it works or is supposed to work. Also how are connections in ejabberd_s2s_in.erl handled? Is the data structure shared for some connections from the same host? If so, how is this detected?
I guess all s2s connections might be affected if virtual hosts are involved.

Lost Messages

Hi,

has anyone ever encountered a problem when using a jabber proxy configuration based on this patch?
We are seeing that jabber messages (meaning all types of xmpp messages like presence notifications or subscription requests) regularly vanish inside our ejabberd jabber proxy. As a side note, almost all messages that vanish have their origin at google talk. The ejabberd debug log shows that the message is received by the ejabberd_receiver but never reaches the ejabberd_router. This behavior can be reproduces but not always. Sometimes these messages successfully pass the proxy.

Can this be related to our jabber proxy setup? Or, as another possibility, can it be related to the bug mentioned here: https://support.process-one.net/browse/EJAB-219 ?

Best regards

Michael Grüner

Re: Lost Messages

Michael Gruener wrote:

Can this be related to our jabber proxy setup? Or, as another possibility, can it be related to the bug mentioned here: https://support.process-one.net/browse/EJAB-219 ?

Unfortunately this can be checked only if you use original version, e.g. without s2s_proxy patch :(

Re: Lost Messages

zinid wrote:

Unfortunately this can be checked only if you use original version, e.g. without s2s_proxy patch :(

Ok, this is a problem. We need this type of setup, so just evaluating the situation without s2s_proxy is not enough. Any other ideas? I tried to identify the problem from analysing logfiles over tcpdump up to adding additional debug statements in the ejabberd code. Unfortunately I don't really understand Erlang good enough to do further debugging or even find better places to add debug output to.

It would also be really helpfull if someone with a similar setup could veryfy our problem.

Any (even the slightest) information is appreciated. Thanks :)

s2s-clients works only with ejabberd distribution!!

hi, I have one big question. Can I use s2s-proxying using another distribution (non-ejabberd) in s2s-clients servers??

N

Re: s2s_proxy - S2S Proxying

nbetm wrote:

hi, I have one big question. Can I use s2s-proxying using another distribution (non-ejabberd) in s2s-clients servers??

N

No, you cannot.

Re:

xram@jabber.ru wrote:
nbetm wrote:

hi, I have one big question. Can I use s2s-proxying using another distribution (non-ejabberd) in s2s-clients servers??

N

No, you cannot.

It seems other software needs to be patched to support this method of proxing.

Syndicate content