Customized websocket code

Issue #158 new
Former user created an issue

Appreciate your previous help/guidance to enable me to customize the websocket code (0.8.1) to be able to connect to my smarthome websocket server not following official websocket protocol.

As you might recall, I had to customize the code (XmppWebsocketDecoder) to be able to handle the "weird" opening stream from the server:

<stream:stream>

which I managed: Only had to make an "if" sentence to recognise and modify the <stream:stream> opening stream, and the subsequent handshake worked fine for connection/login.

Now, after an upgrade for the smarthome server, I am not able to establish connection. Although, based on debugging, the opening stream still seems to be handled ok, and the handshake seems to stop as part of the "feature" stream sent by the server (which passes outside my "if" sentence, and is handled by the regular "unmarshaller" code intended for websocket protocol). The feature stream from the server is recognized as:

<features xmlns="http://etherx.jabber.org/streams"><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>SCRAM-SHA-256</mechanism><mechanism>SCRAM-SHA-1</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms></features>

The "feature" stream sent by the server is after some time followed by:

<close xmlns="urn:ietf:params:xml:ns:xmpp-framing"/>

Any idea what would cause this issue?

Comments (3)

  1. Stian Kjoglym

    Well, after updating XmppSessionConfiguration arrayList to include SHA-256, the handshake completes.

    However, as the handshake is completed (bind is succeeded), the websocket server disconnects, and the stream starts all over (ending in a connected/disconnected loop). Do not get any details for the disconnect, so have no clue what is wrong.

  2. Stian Kjoglym

    Not sure if the library/issues are followed up, but choose to give it just another try:

    So, for my java (OpenHAB) and Smarthome server setup using rocks.xmpp, I manage to get a successful websocket handshake followed by succesful stream negotiation up to the ‘Presence’ part, meaning the following sequence is ok:

    • Opening client stream / server open stream
    • Feature mechanisms from server / auth from client
    • Challenge from server / response from client
    • Success from server
    • Client re-opening stream / server re-opening stream
    • Feature bind / roster etc

    However, the presence stanzas make the connection in an online/offline loop (after the last iq stanza with roster type:result and subscription:both from server):

    [Out] <presence xmlns="jabber:client"><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://xmpp.rocks" ver="UGzTWn6pZLkpLX40G69I2X5o4Lc="></c><c xmlns="urn:xmpp:caps"><hash xmlns="urn:xmpp:hashes:2" algo="sha-256">2kCKFS1BrMhAjDtdvz4JH9rbHtehoPubppQ4HtNrLm0=</hash></c></presence>
    [In] <presence from="mrha@busch-jaeger.de/rpc"><c hash="sha-1" node="http://xmpp.rocks" ver="dOmtXIyaqfcEcu52BgM7enFuDnw=" xmlns="http://jabber.org/protocol/caps"/></presence>
    [Out] <presence xmlns="jabber:client" from="installer@busch-jaeger.de" to="mrha@busch-jaeger.de/rpc" type="subscribe"></presence>
    [Out] <close xmlns="urn:ietf:params:xml:ns:xmpp-framing"></close>
    [Out] <presence xmlns="jabber:client"><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://xmpp.rocks" ver="UGzTWn6pZLkpLX40G69I2X5o4Lc="></c><c xmlns="urn:xmpp:caps"><hash xmlns="urn:xmpp:hashes:2" algo="sha-256">2kCKFS1BrMhAjDtdvz4JH9rbHtehoPubppQ4HtNrLm0=</hash></c></presence>
    ***DISCONNECT**
    

    Following from the code above, there is a javax.websocket.DecodeException

    unexpected element (uri:"", local:"presence"). Expected elements are <{urn:xmpp:sm:3}a>,<{urn:ietf:params:xml:ns:xmpp-sasl}abort>….

    Further guidance would be highly appreciated!

  3. Christian Schudt repo owner

    Hi, sorry for the late response.

    The issue is, that your server sends a presence stanza without a namespace (xmlns):

    <presence from="mrha@busch-jaeger.de/rpc">

    Since in WebSockets there is no stream, but single frames, there is no <stream> header, which defines the jabber:client namespace as default.

    See also https://tools.ietf.org/html/rfc7395#section-3.3.3

  4. Log in to comment