Lighttpd

I'm not an expert on this matter, but "host" => "/var/tmp/remote_debug.sock" seems odd. Something like "host" => "127.0.0.1" would sound better to me.

Thank you Avij for quick reply.

I am upgrading from mod_websocket to mod_wstunnel. With mod_websocket, had host configured as "/var/tmp/remote_debug.sock" and it worked. So tried to have same config.

Changed it to "127.0.0.1" and still same error :
2018-03-21 03:03:32: (server.c.1435) server started (lighttpd/1.4.48)
2018-03-21 03:03:32: (gw_backend.c.1348) either host/port or socket have to be set in: wstunnel.server = ( /remote_debug => ( 0 ( ...
2018-03-21 03:03:32: (server.c.1443) Configuration of plugins failed. Going down.

Continuing with the guesses: A host definition is likely to need a port definition for its companion. You don't have a port specified in that part of the config. But as you do have the socket defined, you might not need the host/port defined at all. Try getting rid of the "host" => "something" entirely. Whether that will actually work is an entirely different question, but it might clear the error message.

The mod_websocket to which you are referring was never part of lighttpd.

The error messages says "either host/port or socket have to be set". Please read the " or " more carefully.

They syntax requirement is the same as for other modules such as mod_fastcgi and mod_proxy, which you already have in your config.
Docs_ModWStunnel
Docs_ModProxy

Please note that if you use large websocket frames, there is a bug fix for #2858 that is part of lighttpd 1.4.49.

Thank you gstrauss and avij.

After modifying config file with socket parameter, lighttpd comes up fine.

While testing actual websocket functionality, websocket client is getting 404 response.

At websocket server, with debugs enabled for lighttpd, do not see any mod_wstunnel related debug logs (debug logs attached).

How to confirm if websocket request is redirected to mod_wstunnel from mod_proxy ?

2018-03-21 16:57:41: (response.c.649) -- handling subrequest
2018-03-21 16:57:41: (response.c.650) Path : /web/htdocs/captive_portal_debug.tfcgi
2018-03-21 16:57:41: (gw_backend.c.2417) handling it in mod_gw
2018-03-21 16:57:41: (response.c.122) Response-Header: \nHTTP/1.1 500 Internal Server Error\r\nContent-Type: text/html\r\nAccess-Control-Allow-Origin: *\r\nAccess-Control-Allow-Headers: X_SESSION_ID\r\nX-Frame-Options: SAMEORIGIN\r\nCache-Control: no-cache\r\nContent-Length: 369\r\nDate: Wed, 21 Mar 2018 23:57:41 GMT\r\nServer: lighttpd/1.4.48\r\n\r\n

Could you please help me confirm If mod_proxy redirects websocket request to mod_wstunnel.

Regards,
Murugesh.

Modified wstunnel.debug to 4, could not find logs related to mod_wstunnel handling request :

2018-03-21 17:13:24: (gw_backend.c.1000) proc: tcp:127.0.0.1:6080 0 0 0 0
2018-03-21 17:13:24: (gw_backend.c.1000) proc: unix:/var/tmp/captive_portal_debug.sock 0 0 0 0
2018-03-21 17:13:25: (gw_backend.c.1000) proc: tcp:127.0.0.1:6080 0 0 0 0
2018-03-21 17:13:25: (gw_backend.c.1000) proc: unix:/var/tmp/captive_portal_debug.sock 0 0 0 0
2018-03-21 17:13:26: (gw_backend.c.1000) proc: tcp:127.0.0.1:6080 0 0 0 0
2018-03-21 17:13:26: (gw_backend.c.1000) proc: unix:/var/tmp/captive_portal_debug.sock 0 0 0 0
2018-03-21 17:13:27: (gw_backend.c.1000) proc: tcp:127.0.0.1:6080 0 0 0 0
2018-03-21 17:13:27: (gw_backend.c.1000) proc: unix:/var/tmp/captive_portal_debug.sock 0 0 0 0
2018-03-21 17:13:28: (request.c.445) fd: 12 request-len: 143 \nPOST /captive_portal_debug.tfcgi HTTP/1.1\r\nContent-Type: application/json\r\nContent-Length: 115\r\nHost: 192.168.3.246\r\nConnection: keep-alive\r\n\r\n

Attached updated lighttpd debug log file.

Would like to confirm If mod_proxy and mod_wstunnel configurations are fine for websocket redirection from mod_proxy to mod_wstunnel to websocket server.

Regards,
Murugesh.

How to confirm if websocket request is redirected to mod_wstunnel from mod_proxy ?

...

Could you please help me confirm If mod_proxy redirects websocket request to mod_wstunnel.

Where did you read that in the documentation? (Hint: it doesn't say anything like that. Please read the documentation more carefully.)

lighttpd does not work that way. There can be only one handler for a request. In your case, you can use mod_proxy OR mod_wstunnel, but not both.

Thank you gstrauss.

For my websocket redirection functionality would like to use mod_wstunnel, removed websockify reference from mod_proxy server.

websocket.conf has :

$HTTP["url"] =~ "^/websockify" {
wstunnel.server = (
"captive_portal_debug" => ((
"socket" => "/var/tmp/captive_portal_debug.sock"
))
)
wstunnel.ping-interval = 10
wstunnel.debug =4
}

appears to be request not reaching mod_wstunnel from gw_backend (from logs):

2018-03-27 13:32:37: (response.c.458) -- logical -> physical                                                                                                                                                       
2018-03-27 13:32:37: (response.c.459) Doc-Root     : /web/htdocs                                                                                                                                                   
2018-03-27 13:32:37: (response.c.460) Basedir      : /web/htdocs                                                                                                                                                   
2018-03-27 13:32:37: (response.c.461) Rel-Path     : /captive_portal_debug.tfcgi                                                                                                                                   
2018-03-27 13:32:37: (response.c.462) Path         : /web/htdocs/captive_portal_debug.tfcgi                                                                                                                        
2018-03-27 13:32:37: (response.c.479) -- handling physical path                                                                                                                                                    
2018-03-27 13:32:37: (response.c.480) Path         : /web/htdocs/captive_portal_debug.tfcgi
2018-03-27 13:32:37: (response.c.487) -- file found                                                                                                                                                                
2018-03-27 13:32:37: (response.c.488) Path         : /web/htdocs/captive_portal_debug.tfcgi                                                                                                                        
2018-03-27 13:32:37: (response.c.649) -- handling subrequest                                                                                                                                                       
2018-03-27 13:32:37: (response.c.650) Path         : /web/htdocs/captive_portal_debug.tfcgi                                                                                                                        
2018-03-27 13:32:37: (gw_backend.c.2417) handling it in mod_gw                             
2018-03-27 13:32:37: (response.c.122) Response-Header: \nHTTP/1.1 500 Internal Server Error\r\nContent-Type: text/html\r\nAccess-Control-Allow-Origin: *\r\nAccess-Control-Allow-Headers: X_SESSION_ID\r\nX-Frame-O
2018-03-27 13:32:37: (request.c.445) fd: 13 request-len: 285 \nGET /captive_portal_debug HTTP/1.1\r\nSec-WebSocket-Version: 13\r\nSec-WebSocket-Key: XSxEaMRQ3w21OoJAZY4QRg==\r\nConnection: Upgrade\r\nUpgrade: we
2018-03-27 13:32:37: (response.c.243) -- splitting Request-URI             

Regards,
Murugesh.

Could you please help me, why request does not reach mod_wstunnel.

Probably because you haven't read the documentation carefully. Maybe try again, perhaps with a little more effort? The answer is pretty simple, and it's a mistake in your config.

Thank you gstrauss for reply.

Is my websocket.conf missing any server host options listed at : https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ConfigurationOptions#gw_backend-gateway-server-host-options

(or)

config file has required wstunnel server options with incorrect values ?

Going through : https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModWStunnel
And comparing my websocket.conf with Docs_ModWStunnel documentation, still it does not strike me what is missing.

Attached main lighttpd.conf that includes websocket.conf

Regards,
Murugesh.

Start with a trivial lighttpd configuration, make one small change at a time, and test it. Then repeat with another small change.

From your post above, it sounds like you've read less than half a page of documentation (which contains a working example), and have tried nothing.

Thank you gstrauss.

Issue with HTTP[url] regex pattern matching. Updated websocket.conf :

$HTTP["url"] =~ "^/captive_portal_debug" {
wstunnel.server = (
"/captive_portal_debug" => ((
"socket" => "/var/tmp/captive_portal_debug.sock",
))
)
wstunnel.debug = 4
wstunnel.ping-interval = 10
}

Could see mod_wstunnel logs now.

From server logs could see, handshake response reaching websocket client, but client reports error :
"Server sent no subprotocol even though requested".

Websocket server logs :

2018-03-28 15:05:31: (request.c.445) fd: 13 request-len: 143 \nPOST /captive_portal_debug.tfcgi HTTP/1.1\r\nContent-Type: application/json\r\nContent-Length: 115\r\nHost: 192.168.3.245\r\nConnection: keep-alive\r\n\r\n
2018-03-28 15:05:31: (response.c.243) -- splitting Request-URI
2018-03-28 15:05:31: (response.c.244) Request-URI : /captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.245) URI-scheme : https
2018-03-28 15:05:31: (response.c.246) URI-authority : 192.168.3.245
2018-03-28 15:05:31: (response.c.247) URI-path (raw) : /captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.248) URI-path (clean): /captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.249) URI-query :
2018-03-28 15:05:31: (response.c.383) -- before doc_root
2018-03-28 15:05:31: (response.c.384) Doc-Root : /web/htdocs
2018-03-28 15:05:31: (response.c.385) Rel-Path : /captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.386) Path :
2018-03-28 15:05:31: (response.c.438) -- after doc_root
2018-03-28 15:05:31: (response.c.439) Doc-Root : /web/htdocs
2018-03-28 15:05:31: (response.c.440) Rel-Path : /captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.441) Path : /web/htdocs/captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.458) -- logical > physical
2018-03-28 15:05:31: (response.c.459) Doc-Root : /web/htdocs
2018-03-28 15:05:31: (response.c.460) Basedir : /web/htdocs
2018-03-28 15:05:31: (response.c.461) Rel-Path : /captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.462) Path : /web/htdocs/captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.479) - handling physical path
2018-03-28 15:05:31: (response.c.480) Path : /web/htdocs/captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.487) -- file found
2018-03-28 15:05:31: (response.c.488) Path : /web/htdocs/captive_portal_debug.tfcgi
2018-03-28 15:05:31: (response.c.649) -- handling subrequest
2018-03-28 15:05:31: (response.c.650) Path : /web/htdocs/captive_portal_debug.tfcgi
2018-03-28 15:05:31: (gw_backend.c.2417) handling it in mod_gw
2018-03-28 15:05:31: (response.c.122) Response-Header: \nHTTP/1.1 500 Internal Server Error\r\nContent-Type: text/html\r\nAccess-Control-Allow-Origin: *\r\nAccess-Control-Allow-Headers: X_SESSION_ID\r\nX-Frame-Options: SAMEORIGIN\r\nCache-Control: no-cache\r\nContent-Length: 369\r\nDate: Wed, 28 Mar 2018 22:05:31 GMT\r\nServer: lighttpd/1.4.48\r\n\r\n
2018-03-28 15:05:31: (request.c.445) fd: 14 request-len: 285 \nGET /captive_portal_debug HTTP/1.1\r\nSec-WebSocket-Version: 13\r\nSec-WebSocket-Key: ugk2FGEvacnbqAA0ZedEHA==\r\nConnection: Upgrade\r\nUpgrade: websocket\r\nSec-WebSocket-Extensions: permessage-deflate; client_max_window_bits\r\nSec-WebSocket-Protocol: base64\r\nOrigin: *\r\nHost: 192.168.3.245\r\n\r\n
2018-03-28 15:05:31: (response.c.243) -- splitting Request-URI
2018-03-28 15:05:31: (response.c.244) Request-URI : /captive_portal_debug
2018-03-28 15:05:31: (response.c.245) URI-scheme : https
2018-03-28 15:05:31: (response.c.246) URI-authority : 192.168.3.245
2018-03-28 15:05:31: (response.c.247) URI-path (raw) : /captive_portal_debug
2018-03-28 15:05:31: (response.c.248) URI-path (clean): /captive_portal_debug
2018-03-28 15:05:31: (response.c.249) URI-query :
2018-03-28 15:05:31: (gw_backend.c.933) gw - found a host 0
2018-03-28 15:05:31: (gw_backend.c.2417) handling it in mod_gw
2018-03-28 15:05:31: (mod_wstunnel.c.431) allowed origins not specified
2018-03-28 15:05:31: (mod_wstunnel.c.518) WebSocket Version = 13
2018-03-28 15:05:31: (mod_wstunnel.c.552) will recv text data from backend
2018-03-28 15:05:31: (response.c.383) -- before doc_root
2018-03-28 15:05:31: (response.c.384) Doc-Root : /web/htdocs
2018-03-28 15:05:31: (response.c.385) Rel-Path : /captive_portal_debug
2018-03-28 15:05:31: (response.c.386) Path :
2018-03-28 15:05:31: (response.c.438) -- after doc_root
2018-03-28 15:05:31: (response.c.439) Doc-Root : /web/htdocs
2018-03-28 15:05:31: (response.c.440) Rel-Path : /captive_portal_debug
2018-03-28 15:05:31: (response.c.441) Path : /web/htdocs/captive_portal_debug
2018-03-28 15:05:31: (response.c.458) -- logical -> physical
2018-03-28 15:05:31: (response.c.459) Doc-Root : /web/htdocs
2018-03-28 15:05:31: (response.c.460) Basedir : /web/htdocs
2018-03-28 15:05:31: (response.c.461) Rel-Path : /captive_portal_debug
2018-03-28 15:05:31: (response.c.462) Path : /web/htdocs/captive_portal_debug
2018-03-28 15:05:31: (gw_backend.c.990) connect succeeded: 15
2018-03-28 15:05:31: (gw_backend.c.234) got proc: pid: 0 socket: unix:/var/tmp/captive_portal_debug.sock load: 1
2018-03-28 15:05:31: (mod_wstunnel.c.857) send handshake response
2018-03-28 15:05:31: (response.c.122) Response-Header: \nHTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\nSec-WebSocket-Accept: LBRTITFyRHncBSKQo/yHI9Al/4g=\r\nAccess-Control-Allow-Origin: *\r\nAccess-Control-Allow-Headers: X_SESSION_ID\r\nX-Frame-Options: SAMEORIGIN\r\nCache-Control: no-cache\r\nConnection: upgrade\r\nDate: Wed, 28 Mar 2018 22:05:31 GMT\r\nServer: lighttpd/1.4.48\r\n\r\n
2018-03-28 15:05:31: (gw_backend.c.308) released proc: pid: 0 socket: unix:/var/tmp/captive_portal_debug.sock load: 0
2018-03-28 15:05:31: (gw_backend.c.1000) proc: unix:/var/tmp/captive_portal_debug.sock 0 0 0 0
2018-03-28 15:05:32: (gw_backend.c.1000) proc: unix:/var/tmp/captive_portal_debug.sock 0 0 0 0

Websocket Client logs:
Error: server sent no subprotocol even though requested at ClientRequest._req.on (/usr/lib/node_modules/ws/lib/WebSocket.js:696:26) at emitThree (events.js:135:13) at ClientRequest.emit (events.js:216:7) at TLSSocket.socketOnData (_http_client.js:486:11) at emitOne (events.js:115:13) at TLSSocket.emit (events.js:210:7) at addChunk (_stream_readable.js:266:12) at readableAddChunk (_stream_readable.js:253:11) at TLSSocket.Readable.push (_stream_readable.js:211:10) at TLSWrap.onread (net.js:585:20)

This remote_debug functionality was working fine with previous lighttpd 1.4.29 and external mod_websocket.

Now lighttpd upgraded to 1.4.48 and mod_wstunnel being used, no change done on websocket client.

Could you please help me understand what is causing this error "server sent no subprotocol even though requested" ?
How to get more information in server about this error, although server logs shows send handshake response.

Websocket client needs modification ?

Regards,
Murugesh.

Request has : Sec-WebSocket-Protocol: base64

2018-03-28 15:05:31: (request.c.445) fd: 14 request-len: 285 \nGET /captive_portal_debug HTTP/1.1\r\nSec-WebSocket-Version: 13\r\nSec-WebSocket-Key: ugk2FGEvacnbqAA0ZedEHA==\r\nConnection: Upgrade\r\nUpgrade: websocket\r\nSec-WebSocket-Extensions: permessage-deflate; client_max_window_bits\r\nSec-WebSocket-Protocol: base64\r\nOrigin: *\r\nHost: 192.168.3.245\r\n\r\n

Added "subproto" => "base64" in wstunnel.server config :

$HTTP["url"] =~ "^/captive_portal_debug" {
wstunnel.server = (
"/captive_portal_debug" => ((
"socket" => "/var/tmp/captive_portal_debug.sock",
"subproto" => "base64"
))
)
wstunnel.debug = 4
wstunnel.ping-interval = 10
}

Still websocket client reports :
Error: server sent no subprotocol even though requested

Please share your thoughts on what is missing.

Regards,
Murugesh.

Please share your thoughts on what is missing.

Can you read? Read the documentation. Does the documentation say that "subproto" => "base64" is valid? (Hint: no)

From server logs could see, handshake response reaching websocket client, but client reports error :
"Server sent no subprotocol even though requested".

Yep. That's an error message which is well-specified. The server sent no subprotocol. It also indicates that your websocket client is either wrong or intolerant, depending on how you read RFC 6455. Then again, you have already shown above that you do not comprehend what you read very well.

The lighttpd mod_wstunnel code contains this comment:

 *     setenv.set-response-header = ( "Sec-WebSocket-Protocol" => "..." )
 *     if header is required

server.modules += ("mod_setenv")
setenv.set-response-header = ( "Sec-WebSocket-Protocol" => "base64" )

Thank you gstrauss.

Regards,
Murugesh.