Openfire not advertising bidi in <stream:features>

Openfire Openfire Dev
1

Hi, I’m making a program that’s trying to connect to an Openfire server using a server to server connection. After negotiating TLS, Openfire sends back the <stream:features> stanza which looks like:

<?xml version="1.0" encoding="UTF-8"?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" 
xmlns="jabber:server" 
xmlns:db="jabber:server:dialback" 
from="fromDomain" to="toDomain" id="a342ddtmsl" 
xml:lang="en-US" version="1.0"><stream:features>
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<mechanism>EXTERNAL</mechanism></mechanisms>
<limits xmlns="urn:xmpp:stream-limits:0"><max-bytes>1048576</max-bytes>
<idle-seconds>1800</idle-seconds></limits></stream:features>

but, according to XEP-0288 should also contain <bidi xmlns='urn:xmpp:features:bidi'/>. If I don’t include the the <bidi> stanza in my <auth> stanza for SASL external authentication like shown in 0288:

<!-- Client -->
<bidi xmlns='urn:xmpp:bidi'/>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>
  Y2FwdWxldC5saXQ=
</auth>

What ends up happening later is when the reverse connection happens (Openfire → my program) this newer connection just kicks off the old one.
If I do include the <bidi> stanza in my <auth> stanza, Openfire reports an unexpected stanza error:

2025.02.24 13:15:59.802 ^[[33mWARN ^[[m [socket_s2s-thread-2]: org.jivesoftware.openfire.net.StanzaHandler - Unexpected packet tag (not message,iq,presence)<bidi xmlns="urn:xmpp:bidi"></bidi>. Closing session: LocalIncomingServerSession{address=emulatetest/6b84a147-847a-4db3-a112-832a5b67a6dc, streamID=5loosu6vmc, status=CONNECTED, isEncrypted=true, isDetached=false, authenticationMethod=null, localDomain=fromDomain, defaultIdentity=toDomain, validatedDomains={}}

Weirdly enough, even with that error, the session will still authenticate and show up in the s2s sessions list. Though, the connection will just time out eventually as the socket is closed.
How am I expected to format the bidirectional communication stanza when negotiating the s2s connection?

2

Sadly, Openfire doesn’t support XEP-0288. A ticket for this has been registered in our issue tracker: OF-2759

3

Thank you, that makes sense. For bidirectional s2s then, how do I prevent the newer connection from kicking off the older one?
I can still send and receive stanzas across the newer socket, but this feels hacky. In the s2s sessions manager, the outgoing session is tallying both the RX and TX packets, and incoming tallies nothing (see image) - whereas with standard Openfire ↔ Openfire s2s, the incoming session would tally RX packets and outgoing would tally TX packets

Screenshot from 2025-02-24 15-34-22
Screenshot from 2025-02-24 15-34-221534×164 21.2 KB

4

Where you write ‘bidirectional’ s2s, you mean ‘non-bidirectional’ (as Bidi is explicitly not supported in Openfire?

I’m not sure what you mean. A bit hand-wavy, Openfire should implement the protocols outlined in RFC 6120 and RFC 6121 - but I’m guessing that you’ve already found those.

I do believe that there’s a quirk in Openfire, where, as part of S2S connection establishment, it uses an initial connection for probing of what ports are available, but uses a new connection for the actual establishment of the session. Is that what you’re running into?

5

Yes, non-bidirectional is what I meant, more precisely just having an incoming and outgoing session to the same domain so both servers can send and receive stanzas.
The issue I’m facing is that after setting up the incoming session, when I establish the outgoing session, the latter replaces the former in the active s2s sessions list.
I interpreted this section of RFC 6120, 4.5 to mean just set up one session after the other, but I must be misunderstanding something.

Two streams over two TCP connections, where each stream is
separately secured. In this approach, one TCP connection is used
for the stream in which stanzas are sent from the initiating
entity to the receiving entity, and the other TCP connection is
used for the stream in which stanzas are sent from the receiving
entity to the initiating entity. This is typical for server-to-
server sessions

The next bulletpoint after that one mentions closing connections if a remote server attempts to negotiate more than one stream, but with standard Openfire to Openfire s2s, it’s able to keep both sessions on at once.

6

I truly don’t understand what you’re doing / trying to do. Is the behavior in Openfire different from any other server implementation?

7

Sorry for the confusion, but I was able to get it to work.
Essentially, I’m working on a 3rd party program that connects with s2s to an Openfire server. It would first initiate the s2s connection from itself to Openfire, replicate the handshakes, and create the “Inbound” connection from Openfire’s perspective. Then, when Openfire did the reverse and made the “Outbound” (from Openfire’s perspective) connection to my program, this outbound connection would replace the inbound connection on the active s2s sessions list, instead of showing up as a “Both” connection type. I then found XEP-0288 and thought that was the missing puzzle piece so to speak, and why I started this thread when that didn’t work either.
Flipping the order and having Openfire create the outbound connection first, then having my program initiate the inbound connection fixed the issue.

8

Good to hear that you got it resolved. I’m still not quite sure if Openfire is misbehaving here, or if this is something in your code. Do you see room for improvement in Openfire?

9

Likely it’s my code misbehaving - in a normal setting where two Openfire servers are federating things work as expected no matter which server initiates the connection.