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.


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 to talk with, the wave server on starts off by doing a DNS lookup for the SRV record for You can test the lookup with the following command:
dig +short -t SRV

You should get a response back something like
10 0 5269

This tells the server that the remote server, with a priority of 10 is listening on port 5269 on machine 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

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

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


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, 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="" from="">
<query xmlns=""/>

If is listening on the expected port, you will get something back like
<iq type="result" id="4500-0" from="" to="wave.example1.
<query xmlns="">
<item jid=" " name="Publish-Subscribe service"/>
<item jid=" " name="Public Chatrooms"/>
<item jid=" " name="Google Prototype Wave Server - F

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="" from="">
<query xmlns=""/>
<error code="404" type="cancel">
<remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>

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 does not have SRV records. So, an attempt to connect with the wavesandbox will initially generate a get request for with a 404 error coming back two minutes later.

This should be followed up by a request to e.g.
<iq type="get" id="9607-3" to="" from="
<query xmlns=""/>

Typically, you should get a response back almost immediately with something like
<iq type="result" id="9607-3" from="" to="wave.example1.
<query xmlns="">
<identity category="collaboration" type="google-wave" name="Google Wave Serv
<feature var=""/>

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="" id="2439-8" to="">
<request xmlns="urn:xmpp:receipts"/>
<event xmlns="">
<wavelet-update xmlns=""

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