Wallbox not connecting via OCPP 1.6 JSON after update to 3.4.9

[jgantenberg]

SteVe Version : 3.4.9
Operating system : Ubuntu 20.4
JDK : Zulu11.54+25-CA
Database : MariaDB 10

Expected Behavior

after update steve to latest 3.4.9 my wallbox (Entratek Power Dot Pro) does not connect to steve anymore.
After switch back to former version 3.4.8 the connection is initiated immediately.
Nothing else changed.
Is it a known problem?

[goekay]

hey @jgantenberg can you please post the logs with 3.4.9 where the connection cannot happen?

[jgantenberg]

Unfortunately there is really nothing in the log. The last message says webapp has started and nothing more.
In the logs of 3.4.8 immediately after the started message came up the next is the connection of the wallbox. I took Main.properties und log configuration equal for both versions.

[goekay]

The last message says webapp has started and nothing more.

is this the message from the terminal? if you are running steve with prod profile, the actual logs will be in a log file. there should some indication about the reason why a connection could not happen.

i locally could not reproduce an issue with 3.4.8 and 3.4.9. after starting steve, i execute the following on a terminal to mimic a charging station (and open a websocket connection):

curl \
    --http1.1 \
    --include \
    --no-buffer \
    --header "Connection: Upgrade" \
    --header "Upgrade: websocket" \
    --header "Host: localhost:8080" \
    --header "Origin: http://localhost:8080/steve/websocket/CentralSystemService/issue802" \
    --header "Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==" \
    --header "Sec-WebSocket-Version: 13" \
    --header "Sec-WebSocket-Protocol: ocpp1.6" \
    http://localhost:8080/steve/websocket/CentralSystemService/issue802

issue802 is a chargeBoxId that i inserted into db beforehand. there are no errors. the connection is opened.

[mhei]

I have also a problem which can be tracked down to the 3.4.9 update. I made a tcpdump trace to sniff into the HTTP communication and see the following:

GET /websocket/CentralSystemService/CCC300 HTTP/1.1
Connection: Upgrade
Host: ocpp.....org
Sec-WebSocket-Key: VrGoIcdGE3LpyGcng3xaPQ==
Sec-WebSocket-Protocol: ocpp1.6
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: WebSocket++/0.8.2

HTTP/1.1 400 Bad Request
Date: Thu, 14 Apr 2022 09:48:03 GMT
Server: Apache/2.4.53
Content-Type: text/html;charset=iso-8859-1
Content-Length: 70
Connection: close

<h1>Bad Message 400</h1><pre>reason: Ambiguous URI empty segment</pre>

My setup is non-standard in such, that I've an Apache webserver before the SteVe installation which acts as a forward-proxy. However, this setup is running fine when downgrading to 3.4.8. So something is different with the new version.

[goekay]

interesting.

<h1>Bad Message 400</h1><pre>reason: Ambiguous URI empty segment</pre>

this signals that the request is not even reaching the OcppWebSocketHandshakeHandler of steve. this is coming from jetty (the web server library we use).

this might be caused by the migration from jetty 9.x to 10.y in the new version coming from this PR. i think jetty got stricter in some areas in this version. we had another issue about the new strictness: #749

i will look into this.

[jgantenberg]

After my return to my desk I made some tcpdumps and found out that it was a simple configuration problem in my wallbox. When configuring the websocket URI I added a slash (/) at the end leading to following URI: ws:<host>:<port>/steve/websocket/CentralSystemService//(chargeBoxId) with double slash before chargebox Id. In tcpdump I saw the same bad request 400 with ambigous URI as reason. After deleting the slash at the end the wallbox connected immdiately.
The hint for the more pickier jetty ws was the right guess.
Thanks for paying attention.

[mhei]

Just for the record: the double slash thing was a great hint: I double-checked my Apache config and found out that my ProxyPassMatch rule created the internal URL as ws://localhost:8080//websocket/... Now that I fixed this, it works. Thanks all!