Install ngrep
apt-get install ngrep
and start to watch the UDP/10000 traffic
ngrep -q 'is accessable' udp port 10000
Install netcat
apt-get install netcat
and send a message to the server through UDP/10000
echo 'yes, it is accessable' | nc -u your.server.com 10000
If you can see the sent message on the server side, this means that there is no UDP/10000 connectivity problem between this client and the server.
Also I have tested this way: This is on a Mac…
Open a Chrome window with 3 tabs, all of which are connected to the same room.
Open a local terminal window and run:
(you will see lots of traffic on 10000 with 3 Chrome tabs running)
sudo tcpdump -ni en0 port 10000
Open another terminal window,
Run the following to block 10000 udp traffic.
echo "block drop quick on en0 proto udp from any to any port = 10000" | sudo pfctl -ef -
Run the following to enable 10000 udp traffic
echo "block drop quick on en0 proto udp from any to any port = 10000" | sudo pfctl -d
If you have three tabs open with 10000 udp open you will see a lot of activity. When you block 10000 you will see activity slow down, the video in the Chrome tabs will stop and the Chrome tabs will eventually reload. If the tabs reload with 3 good video signals you know failover to 443 worked.
I found this to be a nice visual way to test.
Audio/video does not work if two clients are on different networks
Using this to monitor traffic:
sudo tcpdump -ni ens160 udp port 10000 -vv -X
port 10000 is accessible if I use netcat to connect to it
echo 'yes, it is accessible' | nc -u your.server.com 10000
on the server:
tcpdump: listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes
08:05:16.163828 IP (tos 0x0, ttl 52, id 19934, offset 0, flags [DF], proto UDP (17), length 50)
59.95.99.46.56015 > 103.133.214.224.10000: [udp sum ok] UDP, length 22
0x0000: 4500 0032 4dde 4000 3411 1bea 3b5f 632e E..2M.@.4...;_c.
0x0010: 6785 d6e0 dacf 2710 001e 1240 7965 732c g.....'....@yes,
0x0020: 2069 7420 6973 2061 6363 6573 7361 626c .it.is.accessabl
0x0030: 650a
but I cannot see any traffic on my jitsi server - port 10000 using the same tcpdump command, when I create a jitsi meeting and connect to it from my laptop+chrome+broadband, and a second client - android jitsi app running on a cellular phone/4G.
What could be the problem?
when you connect 2 clients by default jvb is not used as per default configuration (p2p : enabled in config.js) so port 10000 connectivity does no difference at all.
I see … hmmm.
So - is my understanding correct?
If one client is on a different mobile network and one is on a home network behind a router,
a. port 10000 on the jitsi server does not come into the picture.
b. STUN/TURN is not required - and even if it does come into the picture, it is not connected with port 10000 UDP
as I said by default jvb is not used for 2 clients so they will not connect to port 10000 of the video bridge hence your point a is correct.
as of your point b I don’t use p2p so I can’t comment reliably, from what I hear Stun is necessary for it to work.
a. P2P works differently. As gpatel-fr mentioned, by default JVB is not used in a P2P scenario - both peers negotiate a random port to cimmunicate over.
b. Because 1 of the clients is behind a router, there is no way for the mobile client to determine the home user’s public IP address without STUN (assuming the router is a NAT device). You don’t necessarily have to set up you own STUN server, there are several free ones available, like the google STUN servers. The Jitsi quick install also provides a STUN implementation.
Hi…Just attempted port 80 just as 443 (TCP) and we as a whole realize it IS working, so why there isn’t anything for these port in the container underneath - from your perspective (in your ss).
Do I have to catch traffic from another Ip address… as in my public IP seems to be: 1.2.3.4 and both me and my worker is associated with this equivalent issue (by means of various interface at pfsenses) so would i be able to do bundle catch from this PC or would it be a good idea for me to utilize another PC whose public ip is: 5.6.7.8?
to test you can use this script in the terminal
for i in (seq 1 20); do sleep 3; nc -z -v -u your.domain.com 10000; done
Also, at /etc/jitsi/videobridge/sip-communicator.properties
use …_PUBLIC_ADDRESS, first then _LOCAL_ADDRESS
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<ur.public.ip>
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<ur.private.ip>
as per my experience…
How do I test this on Windows?
I have no Windows experience but I can suggest you another option. I prepared an echo service which will send the needed text to your port.
run ngrep on Jitsi server
run the following command on the second console on Jitsi
curl "http://checkmyport.emrah.com?proto=udp&port=10000&text=is%20accessable"
curl is not already installed, install it firstapt-get install curl
A new method to check UDP/10000 connectivity
Unlike the first method, this new method does not require any client-side action.
on the server
curl and ngrep packagesapt-get install ngrep curl
UDP/10000 in our case)ngrep -q 'accessible' udp port 10000
curl "http://checkmyport.emrah.com?proto=udp&port=10000&text=it-is-accessible"
The third method
Unlike the first method, this method does not require any server-side action.
Edit:
It seems that this method is not very accurate. The results vary depending on the hosting/cloud providers
On a Linux client
ncat
apt-get install ncat
nc -z -v -u YOUR-HOST-ADDRESS 10000
>>> Connection to YOUR-HOST-ADDRESS 10000 port [udp/*] succeeded!
If you you see the succeeded message, this means that the port is open to the public.
testing this on my server on a random (blocked by default) port gives a successful result and a line in my ufw.log file.
nc -z -v -u emrah.com 54321
Connection to emrah.com 54321 port [udp/*] succeeded!
I only get succeeded message if there is really an UDP server on the server side. Which package provides the nc command in your system?
I’m trying nc from ncat, IIRC netcat-openbsd or netcat-traditional behave differently
well, AFAIK the message you posted (succeeded!) is the one from netcat-openbsd (netcat-traditional answers ‘Open’)
with ncat package on Ubuntu 20.04 (the one from nmap) I get:
nc -z -v -u emrah.com 54321
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connected to 207.154.243.197:54321.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.02 seconds.
sudo update-alternatives --config nc
There are 3 choices for the alternative nc (providing /bin/nc).
Selection Path Priority Status
------------------------------------------------------------
0 /bin/nc.openbsd 50 auto mode
1 /bin/nc.openbsd 50 manual mode
2 /bin/nc.traditional 10 manual mode
* 3 /usr/bin/ncat 40 manual modeAfter some tests, I think that the results depend on the hosting providers.
For example on Digital Ocean it’s succeded if there is an UDP service but on AWS it’s always succeded.
On a Ovh server and a Ionos server, same result as AWS.
My server (emrah.com) is on Digital Ocean and the results are completly different for you and me although we use the same tools too 