Clash Royale CLAN TAG#URR8PPP

UFW not allowing Kurento Media Server 6.7 to get connected through ws_uri

I had very strange experiences while configuring UFW for kurento-media-server(version 6.7.0) in Ubuntu 16.04 for a local network. My node app and KMS are both installed on the same server, running on different ports. With UFW disabled, the app works fine, and the node app is working quite well with KMS. Now, I activate ufw and configure it to

the app won't connect to KMS. It seems that the WebSocket handshake is stuck in some kind of buffer.

As soon as this is configured, the KMS won't connect to the app. Moreover, as far as I know, ufw doesn't interfere in localhost connections. But the connection to ws://localhost:8888/kurento just gets stuck in loopback.

ws://localhost:8888/kurento

/etc/kurento/kurento.conf.json


"mediaServer" :
"resources":
// //Resources usage limit for raising an exception when an
// object creation is attempted
// "exceptionLimit": "0.8",
// // Resources usage limit for restarting the server when no
// objects are alive
// "killLimit": "0.7",
// Garbage collector period in seconds
"garbageCollectorPeriod": 240
,
"net" :
"websocket":
"port": 8888,
//"secure":
// "port": 8433,
// "certificate": "defaultCertificate.pem",
// "password": ""
//,
//"registrar":
// "address": "ws://localhost:9090",
// "localAddress": "localhost"
//,
"path": "kurento",
"threads": 10






ws_uri

undefined

After every failed connection, either with Node App (basically node package kurento-client) or Simple WebSocket Client, I can't simply disable UFW and get all things done. I have to reboot the system, disable the firewall(ufw) and start kurento-media-server-6.0. Even sudo service kurento-media-server-6.0 restart doesn't help.

sudo service kurento-media-server-6.0 restart

tcpdump -vv -i lo port 8888 and '(tcp-syn|tcp-ack)!=0'

tcpdump -vv -i lo port 8888 and '(tcp-syn|tcp-ack)!=0'

tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size
262144 bytes
13:04:30.904489 IP (tos 0x0, ttl 64, id 51739, offset 0, flags [DF],
proto TCP (6), length 316)
localhost.48866 > localhost.8888: Flags [P.], cksum 0xff30 (incorrect
-> 0xf928), seq 1016466694:1016466958, ack 1363142683, win 3637,
options [nop,nop,TS val 2501898228 ecr 2501846491], length 264
13:04:30.904729 IP (tos 0x0, ttl 64, id 51740, offset 0, flags [DF],
proto TCP (6), length 298)
localhost.48866 > localhost.8888: Flags [P.], cksum 0xff1e (incorrect
-> 0xc0e7), seq 264:510, ack 1, win 3637, options [nop,nop,TS val
2501898228 ecr 2501846491], length 246
13:04:30.906243 IP (tos 0x0, ttl 64, id 43249, offset 0, flags [DF],
proto TCP (6), length 52)
localhost.8888 > localhost.48866: Flags [.], cksum 0xfe28 (incorrect -
> 0x009f), seq 1, ack 510, win 1891, options [nop,nop,TS val
2501898228 ecr 2501898228], length 0
13:04:30.906293 IP (tos 0x0, ttl 64, id 43250, offset 0, flags [DF],
proto TCP (6), length 155)
localhost.8888 > localhost.48866: Flags [P.], cksum 0xfe8f (incorrect
-> 0xd653), seq 1:104, ack 510, win 1891, options [nop,nop,TS val
2501898230 ecr 2501898228], length 103


tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size
262144 bytes
13:13:14.951036 IP (tos 0x0, ttl 64, id 22976, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.53530 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0x270b), seq 3285074519, win 43690, options [mss 65495,sackOK,TS val
2502422275 ecr 0,nop,wscale 7], length 0
13:13:22.531679 IP (tos 0x0, ttl 64, id 28371, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0x1a57), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502429855 ecr 0,nop,wscale 7], length 0
13:13:23.559036 IP (tos 0x0, ttl 64, id 28372, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0x1654), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502430882 ecr 0,nop,wscale 7], length 0
13:13:25.575055 IP (tos 0x0, ttl 64, id 28373, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0x0e74), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502432898 ecr 0,nop,wscale 7], length 0
13:13:29.799248 IP (tos 0x0, ttl 64, id 28374, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0xfdf2), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502437123 ecr 0,nop,wscale 7], length 0
13:13:37.990986 IP (tos 0x0, ttl 64, id 28375, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0xddf3), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502445314 ecr 0,nop,wscale 7], length 0


1 Answer
1

Finally, I resolved this issue myself. After very rigorous searching on the internet, I found the similar problem in Websocketpp where issue #623 highlighted the cause.

The actual problem was due to varying interpretation of listen backlog parameter by different kernels. Ubuntu 16.04 interpreted the value 0 to reject all the connections, rather using its default backlog queue.Later, I found out that kurento-media-server is using the same service (Websocktepp) for handling the websocket connections. The issue is already resolved in commit 0bb33e4 but it is still unmerged on master branch(version 0.70) of Websocktetpp and the issue is resolved in develop branch(version 0.80-dev) of Websocketpp. Since, kurento-media-server is still using the stable version of master, there was no direct solution to it.

0

0bb33e4

master

develop

master

The very first idea was to clone the kms repo, fix the issue and rebuild the service. But the tests failed.

Finally, changing the backlog length using the following solved my issue.

$ echo "net.ipv4.tcp_max_syn_backlog=1024" >> /etc/sysctl.conf
$ sysctl -p


I think this overrides the value set by websocketpp (version 0.70).

P.S.: I enabled tcp_syn_cookies permanently so as to resist syn flooding.

tcp_syn_cookies

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.