Looking for some feedback/ information on trying to allow users to register a new account using Spark (2.9.4) connecting to OpenFire (4.6.3). I have done a lot of research the past few days and have noticed a lot of people posting of forums not entirely knowing how XMPP works with DNS and setting improper SRV records or not having DNS records set up at all. I hope I’m not creating another topic about an issue that someone else has already addressed.
A quick backstory of how my environment looks before I get to the issue I am having: I have an enclosed network with a few different sites (all using Windows). Some sites have their own OpenFire server that on-site administrators manage and use DNS Federation to connect to a “Hub” server. Users are able to log in and chat across servers. SRV records and firewall policies are properly created and things are working as intended for the most part. I have Inband Account Registration enabled to allow users to create accounts without having to go through lengthy administrative processes. I am happy to provide more detail if necessary.
Issue: A few sites cannot access DNS servers (due to restrictions on their network) and primarily use XMPP chat to communicate to other sites. The only way users at these sites can connect to my OpenFire server is by IP and not by DNS. If an account already exists on the server, Spark clients have no issues logging into the server by IP. If they try and register an account they receive an error stating “Account could not be created”. I used Wireshark to see what was happening between server-client and saw the client send XMPP packet [IQ xmlns=‘jabber:iq:register"] to the server. Server responds with [type="modify’ code=“400” condition=‘bad-request’]. This is not a problem with clients that can query DNS. In Spark I have turned off the setting for “Automatically discover host and port” and input the server IP and port 5222. I also tried adding the server IP/Hostname in local Hostfile to see if it would use that in place of DNS but it did not work.
From what I have read on the forums it is HIGHLY recommended to use DNS for logon (which I agree) but sadly for a few of my remote sites, it is not an option. I feel I am on a wild goose chase with this issue and it may be that Spark just cant support my specific requirements. If anybody has some tips on getting account registration to work with spark via IP I would appreciate it.
I can’t see how DNS and inband account registration (which is disabled by default) relate. This smells like a bug to me. Are you able to provide more of the data that is exchanged please?
@wroot, I am able to use Pidgin (2.14.1) to register an account using IP. As an administrator I love using Pidgin because of how versatile it is and it would have been my solution, but when given to users it got "too complicated’ due to how our environment is set up. (Multiple servers using federation and each server having multiple sub-domains). Spark was able to present sub-domains and MUC in a neat easy manner for end users.
@guus, I also agree that DNS doesn’t make sense to the account registration issue that I am having. I don’t think it is related to OpenFire but more to Spark itself. I did forget to mention an extremely important detail in my original post that I only have this issue with Spark. I wish I could throw up my Wireshark captures for you but since its on an enclosed network I cant transfer it to here. A quick run down of what packets are exchanged. Client successfully goes through TCP syn-ack with server. Next packet is XMPP from client presenting language, version, “to” server, and “from” username@serverIP. Server replies XMPP with id, version, language, and “from” server FQDN. Next packets are the XMPP exchange I originally posted and then connection is closed. I can do a packet analysis with Pidgin and compare results and post them here if you want when I get the chance.
There is a total disconnect between TCP/IP-based network naming, and the XMPP domain name (which is used in the application layer / in the XMPP protocol). The only overlap is where DNS SRV records are used to map the XMPP domain name (“service name”) to DNS names (A records) to determine what host is providing what XMPP server.
In XMPP stanza addressing, you always use the XMPP domain name as configured for the server, and never use the IP address of the XMPP server (unless the XMPP domain name is configured to be equal to the IP address of the host, which syntactically is valid, but a rather silly thing to do).
If a client sends a stanza to the server using an incorrect name, the server should reject that stanza. I’m not sure why Pidgin’s implementation is working - it might construct a stanza that does not include the address at all (which is permissable under circumstances), which would prevent it from sending an invalid value.
I’m not very well versed into the inner workings of XMPP, much less in how a client constructs stanzas for a server or how it reads/accepts them, but I have learned a lot about it from reading posts here from you and wroot so thanks a lot for being good people and helping all of us out on here. I was able to get my packet captures scrubbed and transferred off my enclosed network. If your willing to help me dive into this issue I can PM you the screenshots of Spark failing and Pidgin succeeding, but if you have more important things to do other than help me with this weird situation I understand as this isn’t a critical issue for me right now. I appreciate you guys going out of your way to help the community!