In Twisted Python, how do I create a tcp server that listens on dual-stack ipv4 + ipv6? tcp:443 and tcp6:443 only accept ipv4 and ipv6 connections respectively, and they can't both run at the same time.
The problem was that tcp was listening on the ipv4 interface 0.0.0.0. Listen on ::0 to accept both ipv4 and ipv6 connections.
server6 = serverFromString(reactor, r"tcp:interface=\:\:0:port=443")
Note the Python raw string r"" to avoid having to double up the backslashes \\
Related
I have installed the TURN server everything in the server code is working fine. no error in the log file. only a warning stating
0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided
but the TURN server running on the server.
here is what shows when I check lsof -i :3478
turnserve 999 root 15u IPv4 446811411 0t0 TCP domain.com:stun (LISTEN)
turnserve 999 root 23u IPv4 446811417 0t0 TCP domain:stun (LISTEN)
turnserve 999 root 24u IPv4 446810998 0t0 UDP domain.com:stun
turnserve 999 root 25u IPv4 446810999 0t0 UDP domain.com:stun
when I check STUN in Trickle ICE it throws an errors
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN server address is incompatible.
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN allocate request timed out.
what's going wrong in this.
Thank you
I think that 701 error is a more generic connectivity error that Trickle ICE uses to indicate it didn't get a binding response back. Run stunclient your.stun.ip.address with the command line tools at www.stunprotocol.org to see if your STUN service is accessible from the outside world.
STUN technically requires being hosted on a device with two IP addresses and two ports. It's typically a command line parameter to specify which IP addresses the server should listen on. But most server implementations can operate on a host with a single IP address.
The second IP address and port on the server is used for STUN client filtering tests to detect what type of NAT is in effect. The client sends a binding request on the server's primary ip and port, but with a change request attribute to have the server respond from the alternate IP address or port. More often than not, this binding request with a change-request attribute fails since NATs will not forward traffic from the other IP/port.
The filtering test is useful for logging what type of NAT the client is on. So that failed connections can be debugged and that success/failure metrics can be correlated to NAT type.
Since most ICE implementations will exchange all available address candidates (local, mapped, and relay), the filtering test isn't very or useful to connectivity establishment.
I'm surprised Trickle ICE is giving you an error. I didn't think WebRTC ever used the changer-request attribute. I just did a Wireshark trace of a Trickle ICE session to stunserver.stunprotocol.org. I don't see the webrtc client setting the change-request attribute in either of the two binding requests it makes.
More details in RFC 5780 Section 3.2
In macOS, I just do so:
> brew install stuntman
when it done
> stunclient stunserver.stunprotocol.org
Binding test: success
Local address: 198.18.0.1:54898
Mapped address: 210.0.158.130:56750
To specify port, just like this:
> stunclient stunserver.stunprotocol.org 3478
Binding test: success
Local address: 198.18.0.1:63061
Mapped address: 210.0.158.130:37126
Have fun!
I want to set up a turn server (coturn) on our company's servers. And I'm not sure which ports should be allowed by outside access. 8443 is a must, using WebRTC. 3478 is a must for credential use. But there's these gazillions of ports which TURN server uses, do they need to be allowed in firewall?Or which ports should be allowed to use CoTURN without problem?
I think it depends on the transport protocols you want to use and the level of security.
With Coturn coturn(git):
The default port for sending (or listening to) STUN/TURN requests is 3478.
TURN listener port for UDP and TCP listeners (Default: 3478). Note:
actually, TLS & DTLS sessions can connect to the "plain" TCP & UDP
port(s), too - if allowed by configuration. For example, the default
listening port can be set to 80 or 443, to go around some strict NATs.
Remember that ports < 1024 may require superuser privileges to start
the turnserver process.
In my project I used also tls listening port but probably it is not necessary:
The default port for sending (or listening to) STUN/TURN over TLS is 5349.
TURN listener port for TLS and DTLS listeners (Default: 5349). Note: actually, "plain" TCP & UDP sessions can connect to the TLS & DTLS port(s), too - if allowed by configuration. For example, the default tls listening port can be set to 443, to go around some strict NATs. Remember that ports < 1024 may require superuser privileges to start the turnserver process. For secure TCP connections, we currently support SSL version 3 and TLS versions 1.0, 1.1, 1.2. For secure UDP connections, we support DTLS version 1.
Also, for establishing at last p2p connection :
Each client will send the data through UDP to the other endpoint:
if it’s sending to a TURN server (to a relay candidate) it will send to a port between 49152-65535 (if it’s sending directly to the other party it will send to any port in the 0-65535 range)
--min-port Lower bound of the UDP port range for relay endpoints allocation. Default value is 49152, according to RFC 5766.
--max-port Upper bound of the UDP port range for relay endpoints allocation. Default value is 65535, according to RFC 5766.
I try to make webRTC app work under corporate firewall that allows only 80 and 443 tcp port, but webRTC use random port(49152-65535). How can i reach?
The solution is to setup a TURN server which is capable to handle traffic on TCP 80 and 443 or use a client library which solves this problem by default (such as the mizu webphone).
You could give coturn a try, it supports TCP transport by default, and if the NAT is very strict and blocks all ports( even outgoing ones) other than 80 and 443, you can set the listening-port as 80 and tls-listening-port as 443 in the TURN server configuration before starting it.
When I start Tomcat I see the following using netstat (filtered by tomcat PID):
TCP 0.0.0.0:5007 xxxx34793KZ:0 LISTENING
TCP 0.0.0.0:8081 xxxx34793KZ:0 LISTENING
TCP 0.0.0.0:8543 xxxx34793KZ:0 LISTENING
TCP 127.0.0.1:8005 xxxx34793KZ:0 LISTENING
TCP 127.0.0.1:29821 xxxx34793KZ:29822 ESTABLISHED
TCP 127.0.0.1:29822 xxxx34793KZ:29821 ESTABLISHED
TCP 127.0.0.1:29823 xxxx34793KZ:29824 ESTABLISHED
TCP 127.0.0.1:29824 xxxx34793KZ:29823 ESTABLISHED
TCP 127.0.0.1:29830 xxxx34793KZ:29831 ESTABLISHED
TCP 127.0.0.1:29831 xxxx34793KZ:29830 ESTABLISHED
TCP 127.0.0.1:29832 xxxx34793KZ:29833 ESTABLISHED
TCP 127.0.0.1:29833 xxxx34793KZ:29832 ESTABLISHED
TCP 127.0.0.1:29834 xxxx34793KZ:29835 ESTABLISHED
TCP 127.0.0.1:29835 xxxx34793KZ:29834 ESTABLISHED
TCP 127.0.0.1:29836 xxxx34793KZ:29837 ESTABLISHED
TCP 127.0.0.1:29837 xxxx34793KZ:29836 ESTABLISHED
TCP [::]:8081 xxxx34793KZ:0 LISTENING
TCP [::]:8543 xxxx34793KZ:0 LISTENING
Ports 29821-29824 and 29830-29837 are what I'm wondering about.
I have searched the web, tomcat documentation, tomcat source code and any mailing list I can think of (including Stackoverflow) and can find nothing on the purpose of these TCP ports. They come in pairs which implies to me that they are possibly configured to loopback. I'm stumped as to why Tomcat needs these.
Our application that runs on Tomcat gets installed into environments where IT Security is quite robust, so they want to know the reason for every port in use.
Any ideas?
The Apache webserver uses port 80 to listen for incoming requests and replies over port 80. Firefox uses port 80 to send requests to webservers and then listens on port 80 for the response from the webserver. I have run Apache and Firefox simultaneously before and am just wondering how two different programs can share the same port.
Each side of a TCP network connection is defined by a touple of (ipaddress, port #). When a packet leaves your system all it knows is that it needs to find ip address 192.168.1.1 and go the whoever has a socket bound to port 80.
A server socket is going to be defined by the address on which Apache is listening and port 80. The client socket open by Firefox will have the same ip address but a different randomly assign port number which you normally do not see.
You can see it using netstat or tcpview (Windows)
For example when I run netstat right now I see:
tcp4 0 0 x.x.x.x.62993 stackoverflow.co.https ESTABLISHED
where x.x.x.x is my laptops ip address and 62993 is the random port number assigned to my web browser.
Firefox isn't listening to port 80. It's making a request to a server port and handling the response.