I'm not seeing any websocket traffic for our app

[Andy]

I also tested using the built in browser launcher from Fiddler Everywhere to https://libwebsockets.org/testserver/

and I'm not seeing any Websocket tabs anywhere or any of the ws traffic. There's a lot of HTTP.

Additionally, in our application the http(s) connections use the Upgrade mechanism to upgrade to a ws(s) connection but the listening port on our service is not being used in whatever the fiddler proxy thing is doing. I just see attempts to go to port 80. Is this something we configure in Fiddler Everywhere?

[Andy]

I just closed and re-launched the browser from the button in Fiddler Everywhere and I see these. Is this the extent of what we will see for websocket traffic? Is it because it's using https so the messages are encrypted?

[Andy]

Here's an example of the issue I'm seeing with our application.

The client will attempt to upgrade an HTTP to use websocket to say, http://127.0.0.1:10000/v1/rpc which will end up as ws://127.0.0.1:10000/v1/rpc

However, I see this in Fiddler Everywhere,

[Nick Iliev]

Hello Andy,

 

To access the WebSocket-specific UI, simply double-click on a WS session. This will open up the WebSocket inspectors, allowing you to examine the WS handshake, the list of streamed WS messages, and individual messages (by selecting them and launching the Message inspector). Here's an example:

I hope the above addresses your issue, but please do let us know if you need further information or have additional questions.

Regards,
Nick Iliev
Progress Telerik

[Andy]

I believe the Fiddler proxy is not establishing the websocket upgrade to the requested port. I don't see the plug icon for our application. I see the circle with the slash.

[Nick Iliev]

To determine the cause of the 502 status and abandoned connection when the proxy is in the middle, it is recommended to compare the raw HTTP Requests & Responses with those generated by Fiddler Everywhere.

If you prefer, you can submit the raw and Fiddler sessions via a private ticket on the Telerik support center. Please refrain from sharing them in this public thread to avoid exposing sensitive data.

[Andy]

Sounds good. I created a support ticket.

I turned on LogWebSockets=VeryVerbose in our DefaultGame.ini for our client and can see it attempts to create two websockets to the server but fails:

VeryVerbose  LogWebSockets             FLwsWebSocket[1]: Constructed url=ws://localhost:11000/v1/rpc protocols=pragma
Verbose      LogWebSockets             FLwsWebSocket[1]::Connect: setting State=StartConnecting url=ws://localhost:11000/v1/rpc bWantsMessageEvents=1 bWantsRawMessageEvents=1
VeryVerbose  LogWebSockets             FLwsWebSocket[2]: Constructed url=ws://localhost:10000/v1/rpc protocols=pragma
Verbose      LogWebSockets             FLwsWebSocket[2]::Connect: setting State=StartConnecting url=ws://localhost:10000/v1/rpc bWantsMessageEvents=1 bWantsRawMessageEvents=1
Verbose      LogWebSockets             FLwsWebSocket[1]::ConnectInternal: setting State=Connecting PreviousState=StartConnecting
Verbose      LogWebSockets             FLwsWebSocket[1]::ConnectInternal: lws_client_connect_via_info succeeded
Verbose      LogWebSockets             FLwsWebSocket[2]::ConnectInternal: setting State=Connecting PreviousState=StartConnecting
Verbose      LogWebSockets             FLwsWebSocket[2]::ConnectInternal: lws_client_connect_via_info succeeded
Warning      LogWebSockets             Lws(Warning): lws_client_handshake: got bad HTTP response '502'
Verbose      LogWebSockets             FLwsWebSocket[1]::LwsCallback: Received LWS_CALLBACK_CLIENT_CONNECTION_ERROR, setting State=Error CloseReason=HS: ws upgrade response not 101 PreviousState=Connecting
Verbose      LogWebSockets             FLwsWebSocket[1]::LwsCallback: Received LWS_CALLBACK_WSI_DESTROY, State=Error
Warning      LogWebSockets             Lws(Warning): lws_client_handshake: got bad HTTP response '502'
Verbose      LogWebSockets             FLwsWebSocket[2]::LwsCallback: Received LWS_CALLBACK_CLIENT_CONNECTION_ERROR, setting State=Error CloseReason=HS: ws upgrade response not 101 PreviousState=Connecting
Verbose      LogWebSockets             FLwsWebSocket[2]::LwsCallback: Received LWS_CALLBACK_WSI_DESTROY, State=Error
Verbose      LogWebSockets             FLwsWebSocket[1]::GameThreadFinalize: setting State=None PreviousState=Error
Error        LogPragma                 FPragmaWebSocket::HandleWebSocketConnectionError (ws://localhost:11000/v1/rpc): HS: ws upgrade response not 101
Display      LogPragma                 UPragmaBackoff::Continue -- Attempting [Reconnect] in [1.000000] seconds.
Verbose      LogWebSockets             FLwsWebSocket[2]::GameThreadFinalize: setting State=None PreviousState=Error
Error        LogPragma                 FPragmaWebSocket::HandleWebSocketConnectionError (ws://localhost:10000/v1/rpc): HS: ws upgrade response not 101

The Raw tab of the Request Inspector shows,

GET http://localhost/v1/rpc HTTP/1.1
Pragma: no-cache
Cache-Control: no-cache
Host: localhost
Origin: http://localhost
Upgrade: websocket
Connection: Upgrade
<snip>

for both with the message that the connection was refused (because it's trying to connect to 127.0.0.1:80,

HTTP/1.1 502 Fiddler - Connection Failed
Date: Wed, 09 Aug 2023 21:34:40 GMT
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, must-revalidate
Timestamp: 14:34:40.803
Connection: close

[Fiddler] The connection to 'localhost' failed. <br />Error: ConnectionRefused (0x274d). <br />System.Net.Internals.SocketExceptionFactory+ExtendedSocketException No connection could be made because the target machine actively refused it. 127.0.0.1:80

[Nick Iliev]

We have just post some suggestion in our private thread, but for visibility, I will also repost some of the information here.

By design Fiddler Everywhere will not change the client's request port - the only scenario that might happen if a rule explicitly does that.

In addition, we have included sample server and client WS applications (available as ws-test.zip) that run on port 10000. These can serve as a reference for testing similar scenarios and identifying any potential problems.

 

[Andy]

I replied in your tracker but just for visibility I thought I would update here as well. Thanks for the sample client and server. With these I see websocket traffic in the Fiddler Inspector so this got me digging.

I changed up our client and server to use my PC local IP address (just to rule out any 127.0.0.1/localhost weirdness) and installed Wireshark.

Looking at the Opening Handshake [1] I don't see the port in the Host field as described by the HTTP RFC [2] (see attached).

I have a feeling there's something awry with the libwebsockets.org sources that Unreal Engine 4.26.2 uses and this websocket Upgrade (or perhaps our client isn't setting this port correctly for how they are using it). This will be my next area of investigation.

Anyway, sorry I pointed fingers towards Fiddler and thanks again for your help!

[1] https://datatracker.ietf.org/doc/html/rfc6455#section-1.3
[2] https://datatracker.ietf.org/doc/html/rfc2616#section-14.23

[宇辉]

i got the same problem, i can not see anything about the websocket in the inspector panel when i using fiddler to debug the app in my android device, 

as shown above; in my local terminal that shows the websocket has been established successfully, but i can not see anything about it in fiddler, so i do not know if my config does have something wrong or i did not use rightly in some aspect

[Nick Iliev]

Hey 宇辉,

Is the traffic from your remote Android device and its application going through Fiddler Everywhere, and is the applicaiton using a security configuration that trusts the Fiddler CA?

Additionally, do you see the initial CONNECT tunnel request to the API endpoint (refer to the screenshot)? If not that would indicate that your WS request is not going through the FIddler proxy at all, and you probably need to configure your WS client to respect the proxy settings

[宇辉]

Thanks a lot,  i have checked my CA that it has been installed correctly in my android device.  And i can not see the endpoint in the screenshot you put above which in my fiddler,  Perhaps it has something wrong in my WS client proxy settings, i would search some other solutions, thanks