jabberd14 HOWTO: getting information about s2s connections
Starting with version 1.6.0 the dialback component is able to let administrators browse the list of current incoming and outgoing connections using service discovery. (For an example see the image here.)
To get access to this list, your JID has to have either global access rights, or at least access rights to the 's2s' feature. (Please check the end of jabber.xml.dist to have an example on giving access rights to JIDs.) Users with JIDs, that have either the global or the s2s access right, will be able to browse the connections, when they direct their Jabber browser to the address of the dialback component. (The address of the dialback component is configured using the id attribute of the service element starting the dialback component. If you have not changed this address, it will be just "s2s.localhost" as in the default configuration file. - Please note that in the screenshots, the address of the dialback component is not the default one!)
Connecting incoming connections
This group contains the connections, that have been initiated by
the peer connecting to the local server. While there are in this
group they are not authenticated. This might be caused by two reasons:
Either because the connection is only be used to validate dialback
requests (authentication is not needed for validating dialback keys),
or because the connection has just been established and authentication
has not yet finished. As soon as the connection is authenticated, it
moves to the group established incoming connections
.
For connections in this group, the connections will be listed by their stream id. This might seem to be uncomfortable, as the domain for the peer might be more handy, but we do not know the other side's domain for every connection - we might not even know the local domain the peer is connecting to, if the connection has just been established and no XML has been exchanged yet. Therefore the stream id is the only unique information available for all connections.
The stream id basically is a random number identifying the connection. The most important role of a stream id is, that it is used for calculating dialback keys. So it takes part in the non-SASL s2s authentication process.
Addresses
This node tells the local and remote domain names. The local domain name is taken from the to attribute of the incoming XML stream root element. It should be available for every connection, where a stream root has been received. The peers domain is only available, if the peer set the from attribute on its stream root element. This attribute is not required by RFC 3920, so it might not be present.
IP/port
This node tells the local and remote IP address and TCP port number of the connection. (If you get "::;0" or "0.0.0.0;0" as the local address, this is because I have not updated the mio part of the server yet to provide this information.) Additionally it is shown here if the connection is protected by TLS.
XMPP version
If the incoming stream root has not yet been received, the
XMPP version the peer supports is not yet known. Else it depends
on the version attribute being present on the incoming stream.
0.9
is the pre-RFC version of the protocol. Version 1.0 is XMPP as
it is defined by RFC 3920.
Connecting outgoing connections
This group contains connections, that have been initiated by the local server, but that are not authorized by the peer to actually send stanzas. There might be two reasons for this situation: Either we are currently authenticating this stream, but authentication has not finished yet, or that we used this connection only to verify an incoming connection using the dialback protocol.
Connections in this group are listed as local domain/remote
domain
.
Connection results
The dialback component will try to connect to all IP addresses of the peer, that are listed in the peer's DNS entry. In connection results, you can see for each tried connection, why it failed (or just "Connected" if the connection succeded). You might see IPv4 as well as IPv6 addresses here. Either with and without an explicit port number.
Connection start
When the dialback component started to establish a connection to the peer. This is represented in Universal Coordinated Time (UTC).
Connection state
This state tells the dialback component what it is currently expecting to happen on this connection. The following states do exist:
- created, not yet started to connect
- The connection data has been created, but the dialback component has not actually started the connection attempt yet.
- we started to connect, no connection yet
- The dialback component started to establish a TCP connection, but this connection is not open yet.
- connected to the other host
- The TCP connection to the peer has been established. (We should have sent our stream root then.)
- we got peer's stream root
- We got the peer's stream root start tag.
- we are waiting for stream features
- If the incoming connection is an XMPP/1.0 connection, we do not got to the previous state, but instead to this state - indicating that we will not sent anything yet, but that we are first waiting for the peer to send its stream features.
- we got the stream features
- The stream features of the peer have been received on the incoming
connection. This state is about the same for XMPP 1.0 connections
as
we got peer's stream root
is for pre-XMPP 1.0 connections. We are able to send dialback requests if the peer supports them, but probably if is is supported by the peer we will establish a TLS layer now, or authenticate using SASL EXTERNAL. - we sent out a dialback request
- A dialback request has been sent to the peer, we are waiting for a reply to it from the other side. The other side now has to connect back to us to verify the dialback key, that we sent to them.
- we had success with our dialback request
- The peer sent a positive reply to our dialback request, i.e. we are now allowed to send messages from the domain, that has been verified by the dialback request.
- dialback failed
- The peer sent a negative reply to our dialback request, i.e. the peer denied us to send messages using the domain we wanted to use.
- we started to authenticate using sasl
- We have sent out a SASL request for authentication using the EXTERNAL mechanism.
- there was a SASL authentication failure
- Peer rejected our SASL authetentication request. Authentication did not succeed.
- successfully authenticated using SASL
- We have authenticated ourselves using SASL. We are now authorized to send stanzas from the domain we authorized as.
Dialback
Shows is the dialback protocol is supported by the peer. If dialback is not supported, we have to hope that the peer supports certificate based SASL EXTERNAL and accepts our certificate as being signed by a trusted certification authority.
Dialback state
With this state, the dialback component monitors if there are dialback requests to be sent, and if these requests can already be sent.
- no dialback request, just sending verifies
- The dialback component does not want to send dialback requests, and the connection would not yet be ready to send such requests.
- we could send dialback requests, if we want to
- The dialback component does not want to send dialback requests, but the connection would be ready to send dialback requests to the peer.
- we want to send dialback requests, but cannot do that yet
- The dialback component wants to send dialback requests, but still has to wait for the stream to be ready to send out a dialback request.
- we have sent a dialback request
- The dialback component wanted to send a dialback request, and the connection is ready to send them. Therefore the requests have been sent to the peer.
Pending verifies
Number of dialback verification requests, that are waiting to be sent on this stream. A dialback verification request is sent by the destination server to the authoritive server of a domain to verify, that a connecting server is authorized to send messages using the domain it wants to use.
Dropped because of settings
The connection to the peer has been dropped as the connection did not meet the configured minimum security requirements or other settings. (E.g. the peer only supports dialback, and we require SASL authentication for this peer.)
IP/port
This node tells the local and remote IP address and TCP port number of the connection. (If you get "::;0" or "0.0.0.0;0" as the local address, this is because I have not updated the mio part of the server yet to provide this information.) Additionally it is shown here if the connection is protected by TLS.
Pending IPs
The dialback component is able to try connecting to different IP addresses or port numbers of a peer. This shows which IP addresses and optionally port numbers are left to try if the current connection fails.
Pending stanzas
How many stanzas are waiting to be sent to the peer. This does not count the packets, that have to be sent for dialback or the stream features. Only the real message, presence and iq stanzas are counted.
Stream ID
The stream id, that has been assigned to this connection by the peer. Stream IDs are used in the dialback protocol.
XMPP version
If the stream root of the peer has not yet been received, the
XMPP version the peer supports is not yet known. Else it depends
on the version attribute being present on the incoming stream.
0.9
is the pre-RFC version of the protocol.
Version 1.0 is XMPP as it is defined by RFC 3920.
Established incoming connections
This group contains the connection initiated by a peer, that have been authenticated and authorized. The peer is allowed to send stanzas on this connection as long as the domain of the sending addresses match the authorized domain.
The connections are listed as <streamid>@<destination domain>/<authorized domain>.
IP/port
This node tells the local and remote IP address and TCP port number of the connection. (If you get "::;0" or "0.0.0.0;0" as the local address, this is because I have not updated the mio part of the server yet to provide this information.) Additionally it is shown here if the connection is protected by TLS.
Last used
When the dialback component has received the last stanza on this connection. This is used to check for idle connections.
Stanza count
How many stanzas have been received on this connection.
Established outgoing connections
This group contains the connection initiated by the local dialback component, that have been authenticated and authorized by the peer. We are allowed to send stanzas to this connection as long as the domain in the source addresses match the domain we are authorized to use.
The connections are listed as <destination domain>/<authorized domain>.
IP/port
This node tells the local and remote IP address and TCP port number of the connection. (If you get "::;0" or "0.0.0.0;0" as the local address, this is because I have not updated the mio part of the server yet to provide this information.) Additionally it is shown here if the connection is protected by TLS.
Last used
When the dialback component has sent the last stanza on this connection. This is used to check for idle connections.
Stanza count
How many stanzas have been sent on this connection.