Debugging Wave Server Configuration

Assuming you have gotten your Wave Server up and running, the big problem is managing to federate with other servers. I’ve spent a bit of time talking with various people about this on Google Wave and have had moderate success. With that, let me share a few of my thoughts and experiences with this.

DNS

The first thing that you need to do is make sure you can find both servers that want to federate via DNS. Wave starts off by looking for a DNS SRV record for the server. So, if you want user1@example1.com to talk with user2@example2.com, the wave server on example1.com starts off by doing a DNS lookup for the SRV record for example2.com You can test the lookup with the following command:
dig +short -t SRV _xmpp-server._tcp.example2.com

You should get a response back something like
10 0 5269 example2.com.

This tells the server that the remote server, with a priority of 10 is listening on port 5269 on machine example2.com. There are a few interesting things to note about this. In theory, you could have multiple wave servers with different priorities, so if one server failed you would fall over to the next. In addition, you could use different ports, or perhaps even different domains for the wave servers. However, all of this gets a bit complicated, so it is best to save that for another day.

Some people have been concerned about whether an SRV record is really necessary. According to the documentation, it isn’t. However, it does seem like a good idea generally.

If there isn’t an SRV record, the server does a simple DNS lookup. You can check this with
dig +short example2.com

You should simply get an IP address back. If there is no DNS record, my understanding is that the wave server will try to connect on the default XMPP server to server port, which is 5269.

If all of this fails, the server will try prepending wave to the address and connecting on that.

e.g. dig +short wave.example2.com

Personally, for this sort of stuff, I’m a belts and suspenders sort of guy, so I like to have a SRV record as well as A records for both the full domain and for the wave subdomain.

The Firewall

The next thing you need to check is to make sure that there is a whole in the firewall on the appropriate port. I like to issue the following command

telnet example2.com 5269

This attempts to connect on port 5269. If you can’t connect, either the server isn’t up, or something is blocking the connections. Best place to check is the firewall. If you do get connected, try entering some text and hitting enter. You should get a message back something like </stream>. If not, it may be that something other than your XMPP server is listening on that port.

Discovery

If you can get a connection to the XMPP server, the next thing that happens is that the wave server attempts to ‘discover’ the wave component on the remote server. This is where you want to go to the logs.

When you run run-server.sh, it streams all kinds of data back. Hopefully you are saving that in a log somewhere. When you attempt to connect to a remote server you should see something in your log like:

<iq type="get" id="4500-0" to="example2.com" from="wave.example1.com">
<query xmlns="http://jabber.org/protocol/disco#items"/>
</iq>

If example2.com is listening on the expected port, you will get something back like
<iq type="result" id="4500-0" from="example2.com" to="wave.example1.
com">
<query xmlns="http://jabber.org/protocol/disco#items">
<item jid="pubsub.example2.com " name="Publish-Subscribe service"/>
<item jid="conference.example2.com " name="Public Chatrooms"/>
<item jid="wave.example2.com " name="Google Prototype Wave Server - F
edOne"/>
</query>
</iq>

You will note that the id from the get request should match the id from the result. The list should have all the different services available on the XMPP server, and one of them should be the wave server. If you don’t see the wave server, that would be an indication that the remote wave server hasn’t successfully connected with its XMPP server. If you get a lot of different services, this could be a problem. In theory, the wave server should be able to pick out the appropriate server, but it doesn’t always seem to work.

If for some reason, you get
<iq type="error" id="4500-0" to="wave.example1.com" from="example2.com">
<query xmlns="http://jabber.org/protocol/disco#items"/>
<error code="404" type="cancel">
<remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
</iq>

Do not be mislead to thinking that the remote server actually sent data back to you. This is generated on the local server when a connection times out. As an example wavesandbox.com does not have SRV records. So, an attempt to connect with the wavesandbox will initially generate a get request for wavesandbox.com with a 404 error coming back two minutes later.

This should be followed up by a request to wave.wavesandbox.com. e.g.
<iq type="get" id="9607-3" to="wave.wavesandbox.com" from="wave.example1.com
">
<query xmlns="http://jabber.org/protocol/disco#info"/>
</iq>

Typically, you should get a response back almost immediately with something like
<iq type="result" id="9607-3" from="wave.wavesandbox.com" to="wave.example1.
com">
<query xmlns="http://jabber.org/protocol/disco#info">
<identity category="collaboration" type="google-wave" name="Google Wave Serv
er"/>
<feature var="http://waveprotocol.org/protocol/0.2/waveserver"/>
</query>
</iq>

It is worth noting that according to the documentation, category="collaboration" and type="google-wave" are the two bits of information that are checked to make sure you have the right component.

Once the two servers have discovered each other, they should be able to start a conversation and you should start seeing messages like

<message type="normal" from="wave.example2.com" id="2439-8" to="wave.example1.com">
<request xmlns="urn:xmpp:receipts"/>
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items>
<item>
<wavelet-update xmlns="http://waveprotocol.org/protocol/0.2/waveserver"
wavelet-name="wave://example2.com/w+jK3ezUv4CbcJ/conv+root">
<applied-delta><![CDATA[CvsCCk8KGAgCEhQ5grDcE98oGfLFd/ca48EJ2UDMwRIbbW
Fya3VzQGphYmJlci5mdWxsbW90aW9uLmRlGhYKFGJhckBvcmllbnQtbG9kZ2UuY29tEqcCCoACH/7x6h
qKYu3DAHGvM2Kfckq7n3inVr2NgiQbv3Qq3dUokPZpqKLvnMLW2UUzOt1j/QafcZsBMDM9RAeh3mse+b
1N3a+EH2AjkAGpqw74AM8DobipIOhJIFmHB88snafmES2adexB2W0MZNUVlQA+X82XDXVgFUGc9Tdrn9
t0+O4Da1+5MutL2hYXsvGDXS9ffOpENB4gwze1ot0j/Dq7IfGQKcqJ7UFR0UF5hZuV9xX1LEXo8AGmT9
CRlgrLSGRSqBgs/NAZ3BM8AeUSYGp1byHUbjvclCumPEg24KdddXmXGggh0zezymHDubLrPUyyHZkj0r
poz1Ay+djX6438ThIgSw9rJdqWGnoihhaosD2ytWPr55ds74vyXNdwZnUy8roYARIYCAISFDmCsNwT3y
gZ8sV39xrjwQnZQMzBGAEgvp7I0tUk]]></applied-delta>
</wavelet-update>

Once you start seeing messages like this, you should be connected and start seeing data show up on your clients. I’ve been seeing these sorts of messages, but not seeing them show up in my clients, so I am suspecting that there may be some other issues with the servers.

Does this help? Let me know if you want to test with my wave server or the sort of results you are getting.

(Categories: )