You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe
When our system A establishes a websocket connection with opensips,
opensips fails to verify because the received connection information carries the <Via: 1.1 default.fqdn> header,and the wss handshake fails.
Relevant System Logs
opensips error log is as follows:
==================================================
Nov 15 23:08:00 [58] ERROR:core:parse_via: bad char <1> on state 100
Nov 15 23:08:00 [58] ERROR:core:parse_via: <1.1 default.fqdn
X-Forwarded-For: 10.1.1.1
Front-end-https: on
Nov 15 23:08:00 [58] ERROR:core:parse_via: via parse failed
Nov 15 23:08:00 [58] ERROR:core:get_hdr_field: bad via
Nov 15 23:08:00 [58] INFO:core:parse_headers: bad header field
Nov 15 23:08:00 [58] ERROR:proto_wss:ws_parse_req_handshake: cannot parse headers
Host: xxxx:8443
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36
Expected behavior
Websocket connection can successfully establish a connection even if Via is included in the header like “Via: 1.1 default.fqdn”
Confirming the opensips source code,
it is found that even in the websocket handshake stage,
the header verification is carried out according to the rules of SIP message Via. Is this reasonable?
(trace: ws_parse_req_handshake--> parse_headers -->get_hdr_field /parse_via)
Can the handshake failure in this case be avoided?
OS/environment information
Operating System: centos8
Additional context
Note: The message headers from system A itself does not contain the Via header, it may be that the intermediate component of the network layer carries the Via header
The text was updated successfully, but these errors were encountered:
OpenSIPS version
opensips :2.4
Describe
When our system A establishes a websocket connection with opensips,
opensips fails to verify because the received connection information carries the <Via: 1.1 default.fqdn> header,and the wss handshake fails.
Relevant System Logs
opensips error log is as follows:
==================================================
Nov 15 23:08:00 [58] ERROR:core:parse_via: bad char <1> on state 100
Nov 15 23:08:00 [58] ERROR:core:parse_via: <1.1 default.fqdn
X-Forwarded-For: 10.1.1.1
Front-end-https: on
Nov 15 23:08:00 [58] ERROR:core:parse_via: via parse failed
Nov 15 23:08:00 [58] ERROR:core:get_hdr_field: bad via
Nov 15 23:08:00 [58] INFO:core:parse_headers: bad header field
Nov 15 23:08:00 [58] ERROR:proto_wss:ws_parse_req_handshake: cannot parse headers
Host: xxxx:8443
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36
Upgrade: websocket
Origin: https://xxx/
Sec-WebSocket-Version: 13
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-GB,en;q=0.9
Cookie: _ga=GA1.1.2080369201.1731xxx33; _ga_BC6KRKZDR1=GS1.1.1731681733.1.1.173xxx83215.60.0.0
Sec-WebSocket-Key: XoHK1r7h+nfqssssvQJiAg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Protocol: sip
X-Client-Ip: 10.x.xx
X-Authenticated-User: xxx
X-Authenticated-Groups: NAP_ALL_ALLOWED
Via: 1.1 default.fqdn
X-Forwarded-For: 10.x.x.x
Front-end-https: on
Nov 15 23:08:00 [58] ERROR:proto_wss:wss_read_req: cannot complete WebSocket handshake
==================================================
Expected behavior
Websocket connection can successfully establish a connection even if Via is included in the header like “Via: 1.1 default.fqdn”
Confirming the opensips source code,
it is found that even in the websocket handshake stage,
the header verification is carried out according to the rules of SIP message Via. Is this reasonable?
(trace: ws_parse_req_handshake--> parse_headers -->get_hdr_field /parse_via)
Can the handshake failure in this case be avoided?
OS/environment information
Additional context
Note: The message headers from system A itself does not contain the Via header, it may be that the intermediate component of the network layer carries the Via header
The text was updated successfully, but these errors were encountered: