OK, I can now Ping your server, but I think you still have issues. If I add you to a wave I get:
INFO: received XMPP packet: <iq type="result" id="8808-132" from="rackandpin.com" to="wave.ukwave.org"> <query xmlns="http://jabber.org/protocol/disco#items"/> </iq> 20-Aug-2009 19:38:18 org.waveprotocol.wave.examples.fedone.federation.xmpp.XmppDisco$DiscoItemIterator run INFO: Couldn't find wave on rackandpin.com 20-Aug-2009 19:38:18 org.waveprotocol.wave.examples.fedone.federation.xmpp.XmppFederationHostForDomain$1 run SEVERE: rackandpin.com does not appear to have wav Also this is what I get when I do this: $ dig +short -t SRV _xmpp-server._tcp.rackandping.com $ And: $ dig +short -t SRV _xmpp-server._tcp.wave.rackandping.com $ So, from where I am, it looks like you have missed something in XMPP setup, and/or do not have any SRV records set up... HTH, Tom 2009/8/20 .M. <[email protected]> > > > I think DNS and IP address is correct. > > I had ping blocked but have enabled in case that related. Doesn't seem > to be but anyone can now ping. > > > On Aug 20, 12:01 am, Tom Dyer <[email protected]> wrote: > > I am unable to ping either wave.rackandpin.com or rackandpin.com. > > They both resolve to the same IP, but I get no response. > > > > Is this the correct IP? Do you need to update your DNS? > > > > Tom > > > > 2009/8/19 .M. <[email protected]> > > > > > > > > > I think I'm having the same problem > > > > > Pings back to my server always look like > > > > > <iq type="error" id="7865-0" to="wave.rackandpin.com" > > > from="220.233.26.91"> > > > <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> > > > > > I've set common name in my cert, xmpp_domain and xmpp server name to > > > be rackandpin.com and to wave.rackandpin.com. Neither work. > > > > > Unclear what is generating 404 > > > > > Any advice? > > > > > .M. > > > > > On Aug 19, 3:29 pm, > > > "[email protected]<david.c.hubbard%[email protected]> > <david.c.hubbard%[email protected] <david.c.hubbard%[email protected]>> > > > " > > > <[email protected]> wrote: > > > > Hi, > > > > > > > The client->server stuff doesn't require DNS setup. You can very > easily > > > > > use a raw IP Address (which is what I do, my client is on my laptop > and > > > > > my server is on a vm). > > > > > > > Hope that clears things up. > > > > > > > -- > > > > > James Purser > > > > > > This is a good point. > > > > > > wave.domain will not be used by a client. The DNS setup is all for > > > > federation server-to-server. > > > > > > The google wave federation server assumes that a component will be a > > > > subdomain; so the DNS for the subdomain must point to the same IP > > > > address for the main xmpp server (listening on port 5222) for > dialback > > > > to work. But the XEP-0114 spec (http://xmpp.org/extensions/ > > > > xep-0114.html#proto) does not put any limitations on how the > component > > > > can be named. The assumption is that the component name is unique, so > > > > that it can be used for routing (to and from attributes). And > > > > component names ultimately become Jabber IDs, so the domain part of > > > > the JID must resolve - hence the DNS requirement. > > > > > > So I see two options: > > > > > > 1. It isn't broke, so don't fix it. Everyone must register a > subdomain > > > > per component, so that the JID->DNS mapping works. > > > > > > 2. Write a new implementation of org.xmpp.component.ComponentManager > > > > (or submit changes to openfire whack) so that the component JID does > > > > not necessarily have to be a subdomain. > > > > > > As far as I can tell, option #1 presumes the ability to administer a > > > > DNS zone (and create subdomains). This increases the barrier to entry > > > > for a federated server, and leads to more user problems with their > DNS > > > > setup. Use of a subdomain makes the service more scalable: messages > > > > for wave will automatically separate at the DNS level from regular > > > > jabber IMs. > > > > > > Option #2 has a couple other advantages: it works even using IP > > > > addresses; current federated servers don't need to change (it's > > > > backwards-compatible); and, it's closer to the established SMTP or > > > > Jabber protocols -- listening for connections on a single port is the > > > > minimum required for a company to "set up a server." > > > > > > David > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
