Bug #3010

wstunnel forward respond tcp fragment body wrong

Added by michael2008 3 months ago. Updated 3 months ago.

Target version:


Hi lighty labs team,
I use lighty version 1.4.55 for H5 wss -> lighttpd -> wstunnel tcp -> tcp server

server.modules += ( "mod_wstunnel" )
$HTTP["url"] =~ "^/wss" {
wstunnel.server = ( "" => ( ( "host" => "", "port" => "9090" ) ) )
wstunnel.frame-type = "binary" = 300 = 0 = 0
setenv.set-response-header = ( "Sec-WebSocket-Protocol" => "wss_proto" )

If tcp server respond data with tcp fragment , 1.4K + 1K.
My Chrome H5 app got two respond data from wss connection (two packet without tcp fragment flag).


Updated by gstrauss 3 months ago

  • Status changed from New to Need Feedback

If you think this is a bug in lighttpd mod_wstunnel, please provide more specific data showing whether or not lighttpd is sending proper websocket frames

The kernel TCP stack sends TCP packets and handles TCP fragment, or not. lighttpd does not meddle at that layer.
Your problem is probably not in lighttpd and is more likely in your TCP stack, firewall settings, intermediary network, etc.


Updated by gstrauss 3 months ago

  • Status changed from Need Feedback to Invalid
  • Target version deleted (1.4.x)

mod_wstunnel handles the websocket protocol to and from the client.
mod_wstunnel sends to the backend the data payload unpacked from websocket frames (sent from client).
mod_wstunnel packs the data payload received from the backend into websocket frames and sends websocket frames to the client.

You misunderstand the websocket protocol layer if you think that lighttpd mod_wstunnel will pass TCP fragment flags from your backend. TCP is below the layer of websocket frames.


Updated by stbuehler 3 months ago

One might argue that tunneling TCP could use one large websocket frame (in many fragments). But the RFC 6455 also states in 5.4 Fragmentation:

Unless specified otherwise by an extension, frames have no semantic
meaning. An intermediary might coalesce and/or split frames, if no
extensions were negotiated by the client and the server or if some
extensions were negotiated, but the intermediary understood all the
extensions negotiated and knows how to coalesce and/or split frames
in the presence of these extensions. One implication of this is that
in absence of extensions, senders and receivers must not depend on
the presence of specific frame boundaries.

So you need to be able to handle multiple frames for one TCP session (mod_wstunnel actually never sends fragments right now: src/mod_wstunnel.c:1093 - the FIN bit is always set).

Also available in: Atom