I downloaded the stun client from http://www.stunprotocol.org/ and trying to figure out the NAT type by command stunclient --mode full stun.stunprotocol.org --verbosity 9 and I got the below response.
config.fBehaviorTest = true
config.fFilteringTest = true
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 52.86.10.164:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 52.86.10.164:3478
Got response (68 bytes) from 52.86.10.164:3478 on inter
Other address is 52.201.75.212:3479
Sending message to 52.201.75.212:3478
Got response (68 bytes) from 52.201.75.212:3478 on inte
Sending message to 52.201.75.212:3479
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.201.75.212:3479
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Binding test: success
Local address: 10.64.60.58:58841
Mapped address: 125.19.34.60:24604
Behavior test: fail
Filtering test: success
Nat filtering: Address and Port Dependent Filtering
I am working in a corporate and therefore for security reasons, NAT type "Address and Port Dependent Filtering" seems viable.
But as a general phenomenon, it seems to me that for peer to peer connections , most of the the time, NAT Type will be "Address and Port Dependent Filtering" and therefore turn server is required for any media communication.
However, searching on google for webrtc, it shows that 90% of peer to peer communication establishes through stun server itself( by hole punching etc). This means NAT type in that case is fully supported for establishing the connection.
Do experts have any opinions about the NAT type analytics to consider for peer to peer communication?
The stunclient program could use a bit more logging to indicate what it's doing. Since I know a little about the code, here's how I interpret it.
Stunclient does two different sets of tests. The first are the "mapping behavior" tests, which is the most important for understand how your NAT/Firewall will impact P2P connectivity. The other set are the "filtering tests" that are an indicator of how "open" your NAT is with regards to receiving traffic from other IP/port combinations.
Your behavior test "failed". What this likely means, based on your log output is this:
Test 1: Pick a random port, 58841, in this case. From this local port, do a basic binding test to stun.stunprotocol.org:3478. This is where the client receives a response where the server indicates the mapped address (125.19.34.60:24604) and that the stun alternate IP for subsequent behavior and filtering tests is at 52.201.75.212.
Test 2: Same local port, 58851. Send a binding request to the alternate IP and primary port (52.201.75.212:3478). In your case, it appears that the response that came back was likely a different ip or port. And in thist case "test 3" was required.
Test 3: Same local port, 58851. Send a binding request to the alternate ip and alternate port (52.201.75.212:3479) so it can distinguish between between "address dependent" vs "address and port dependent mappings". And this is the interesting part - you never got a response. Despite being able to communicate with both IP addresses on port 3478. This is why the test came back as failed.
Could be one of two things:
a) Your NAT/Firewall actually is open for port 3478, but not 3479. Do this from the command line to detect
stunclient 52.201.75.212 3479
And if that succeeds in getting a mapped address, then immediately do this:
stunclient 52.86.10.164 3478
Try other combinations of those two ip address and ports. The resulting behavior could mean the following
b) Your NAT/Firewall declines to port map when both the remove ip and port have changed. That means your network environment is even more restrictive that an "Address and Port dependent mapping" NAT. More commonly known as a symmetric NAT.
As for the filtering tests, just ignore this result. The filtering tests try to detect if you can send to one ip:port, but receive from a different ip or port. 99% of the time NATs disallow this. So the result almost always results in "Address and Port Dependent Filtering". The filtering test result is not very indicative of how your NAT will succeed in P2P connectivity.
And just because your enterprise network is very restrictive, it doesn't mean it's impossible for you to communicate with a peer on another network. If he has a more well behaved NAT with Endpoint Independent Mapping, then there's still a chance P2P connectivity will succeed.
I haven't kept up with NAT trends in recent yearas, but 80-90% of connections succeeding with STUN alone sounds right. The rest will need a relay solution such as TURN.
I imagine, you want to communicate between p2p in all possible scenarios (including symmetry NAT).
My suggestion: Try using webRTC and use stun and turn servers in ice server list. this will give you range of ICE candidates and webRTC will take care of connecting to best possible candidates.
this should save you from your NAT type concerns.
Related
I am trying to create a SAP RFC connection to a new system.
AFAIK the firewall (in this case to port 3321) is open.
I get this message at the client:
RFC_COMMUNICATION_FAILURE (rc=1): key=RFC_COMMUNICATION_FAILURE, message=
LOCATION SAP-Gateway on host ax-swb-q06.prod.lokal / sapgw21
ERROR timeout during allocate
TIME Thu Jul 26 16:45:48 2018
RELEASE 753
COMPONENT SAP-Gateway
VERSION 2
RC 242
MODULE /bas/753_REL/src/krn/si/gw/gwr3cpic.c
LINE 2210
DETAIL no connect of TP sapdp21 from host 10.190.10.32 after 20 sec
COUNTER 3
[MSG: class=, type=, number=, v1-4:=;;;]
And this message on the SAP server
Any clue what needs to be done, to get RFC working?
With this little info no one can know what the issue is here.
But it is something related to your network and SAP system configuration.
I guess your firewall does some network address translation (NAT) and the new IP behind the firewall does not match anymore with the known one. SAP is doing some own IP / host name security checks.
If not already done, check with opening the ports 3221, 3321 and 4821 in the firewall. Also check the SAP gateway configuration which IP addresses and host names are configured to be valid ones for it (look at what is traced in the beginning of the gateway trace file dev_rd at ABAP side).
Also consider if maybe the usage of a SAProuter would be the better option for your needs.
it works in my case if ashost is the host name, and not an IP address!
Do not ask me why, but this fails:
Connection(user='x', passwd='...', ashost='10.190.10.32', sysnr='21', client='494')
But this works:
Connection(user='x', passwd='...', ashost='ax-swb-q06.prod.lokal', sysnr='21', client='494')
This is strange, since DNS resolution happens before TCP communication.
It seems that the ashost value gets used inside the connection. Strange. For most normal protocols (http, ftp, pop3, ...) this does not matter. Or you get at least a better error message.
I am testing on G-wan server performance and it's very amazing!!! Here is the output from report.c
Requests
All: 5,725 (6.06% of Cache misses)
HTTP: 66 (1.15% of all requests)
Errors: 70 (1.22% of all requests)
CSP: 5,650 (98.69% of all requests) Exceptions: 1
Connections
Accepted: 4,717 (1.21 requests per connection)
Closed: 4,372
Timeouts: 682 (14.46%) Accept:682 Read:0 Slow:0 Build:0 Send:0 Close:0
Busy: 345 (Waiting: 334 Reading: 9 Replying: 2 Sending: 0 Pushing: 0 Relaying: 0 Closing: 0)
I found that the Errors rate seem to be quite high, and there an exceptions occur on CSP too, could anyone tell me what did "Errors" mean and how to avoid it? Thanks!
the "Errors" rate seem to be quite high
That's HTTP errors (wrong requests coming from a client, not found resources, etc. - look at the error.log file for a trace).
The only way to avoid HTTP errors is to prevent clients from connecting to the server.
If you can't live with this "high rate of HTTP errors" of 1.22% of all requests then use a G-WAN connection handler (with the HTTP_ERROR notification) to make G-WAN ignore HTTP errors and close the connection without sending an HTTP error message (just return 0; in the handler) - but that's probably not what most users want.
there an exceptions occur on CSP too
An exception means a 'graceful crash report' was issued for a servlet bug. As you have only 1 crash on 5,650 dynamic requests, that was probably during the servlet development. Look at your error.log and trace files to check what happened.
Note that the "cache misses" statistics are for static contents only (1.15% of all your HTTP requests).
Apparently, not all your clients are responding in the timely fashion: you have timeouts and pending requests.
How do I implement something similar to the HTTP Basic authentication, in a TCP server written for Node.JS ? The code for a basic TCP server is the following:
// Load the net module to create a tcp server.
var net = require('net');
// Setup a tcp server
var server = net.createServer(function (socket) {
// Every time someone connects, tell them hello and then close the connection.
socket.addListener("connect", function () {
console.log("Connection from " + socket.remoteAddress);
socket.end("Hello World\n");
});
});
// Fire up the server bound to port 7000 on localhost
server.listen(7000, "localhost");
// Put a friendly message on the terminal
console.log("TCP server listening on port 7000 at localhost.");
While there are several ways to provide authentication over a TCP connection, all require some form of "protocol" being an agreed-upon communications grammar/syntax.
For example, in the Simple Mail Transport Protocol, the following conversation occurs (where S: and C: designate lines provided by the SMTP server and email client, respectively):
S: 220 server.example.com
C: HELO client.example.com
S: 250 server.example.com
C: MAIL FROM:<sender#example.com>
S: 250 2.1.0 sender#example.com... Sender ok
C: RCPT TO:<recipient#example.com>
S: 250 recipient <recipient#example.com> OK
C: DATA
S: 354 enter mail, end with line containing only "."
C: full email message appears here, where any line
C: containing a single period is sent as two periods
C: to differentiate it from the "end of message" marker
C: .
S: 250 message sent
C: QUIT
S: 221 goodbye
In replies from the server, the initial numeric value indicates the success or failure of the requested operation, or that the reply contains an informational message. Using a three digit numeric value allows for efficient parsing as all replies beginning with 2xx indicate success, 3xx are informational, 4xx indicate protocol errors, and 5xx are reserved for server errors. See IETF RFC 5321 - https://www.rfc-editor.org/rfc/rfc5321 for the full protocol.
So in your specific case, you might consider something as simple as:
[connect to TCP server]
S: ? # indicates the server is ready for authorization
C: username password # send authentication credentials
The server would then reply with:
S: ! # indicates successful authentication and
# that server is ready for more commands
Or
S: ? # indicates authentication failure
If too many failed attempts to authenticate are seen, the server might sever the connection to reduce the potential for abuse, such as DDOS attacks.
Once authenticated, the client could send:
C: > # begin streaming
Or any other command you which to support.
Response with info? is very quick:
i: info? http://cdimage.ubuntu.com/daily/current/natty-alternate-i386.iso
i/size
With http head request it takes maybe 10 times more time why ?
port: open tcp://cdimage.ubuntu.com:80
insert port "HEAD /daily/current/natty-alternate-i386.iso HTTP/1.1 ^/"
insert port "Host: cdimage.ubuntu.com ^/^/"
out: copy ""
while [data: copy port][append out data]
block: parse out rejoin [": " newline]
select block "Content-Length"
the port modes are responsible in this case. you where using buffered I/O with the wait mode (which is on by default).
in http, the client is responsible closing of the port when you've read all the server bytes.
since you are basically using tcp directly, using insert port, you are responsible for also detecting the end of the request and closing the port when sufficient bytes have arrived. this can only be done in /lines or /no-wait when doing low-level tcp fun.
Something that read and info? do for you.
while [data: copy port][append out data]
doesn't terminate until a timeout occurs (which is 30 seconds by default in REBOL).
also, your request seems to be in error...
try this:
port: open/lines tcp://cdimage.ubuntu.com:80
insert port {HEAD /daily/current/natty-alternate-i386.iso HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 2.7.7.3.1
Host: cdimage.ubuntu.com
}
out: form copy port
block: parse out none ;rejoin [": ^/"]
probe select block "Content-Length:"
here it seems that adding /lines will prevent the wait. its probably related to how the http scheme handles the line mode on open.
look around for REBOL port modes within the documentation and on the net its well explained all over the place.
if you had used trace/net on, you'd realized that all the packets where received and that the interpreter was just still waiting. btw your code actually returned an error 400 in my tests.
Is there any way to set keepalive for induvidual socket descriptor in vxworks? I read in some documents that "SOL_TCP" option in setsockopt function will do such favors in linux. Is such facility available in VxWorks too? If so please provide related details regarding the same, like what are the include file we need to include and how to use such option etc.
From the VxWorks "Library Reference" manual (can be download):
OPTIONS FOR STREAM SOCKETS
The following sections discuss the socket options available for stream (TCP) sockets.
SO_KEEPALIVE -- Detecting a Dead Connection
Specify the SO_KEEPALIVE option to make the transport protocol (TCP) initiate a timer to detect a dead connection:
setsockopt (sock, SOL_SOCKET, SO_KEEPALIVE, &optval, sizeof (optval));
This prevents an application from hanging on an invalid connection. The value at optval for this option is an integer (type int), either 1 (on) or 0 (off).
The integrity of a connection is verified by transmitting zero-length TCP segments triggered by a timer, to force a response from a peer node. If the peer does not respond after repeated transmissions of the KEEPALIVE segments, the connection is dropped, all protocol data structures are reclaimed, and processes sleeping on the connection are awakened with an ETIMEDOUT error.
The ETIMEDOUT timeout can happen in two ways. If the connection is not yet established, the KEEPALIVE timer expires after idling for TCPTV_KEEP_INIT. If the connection is established, the KEEPALIVE timer starts up when there is no traffic for TCPTV_KEEP_IDLE. If no response is received from the peer after sending the KEEPALIVE segment TCPTV_KEEPCNT times with interval TCPTV_KEEPINTVL, TCP assumes that the connection is invalid. The parameters TCPTV_KEEP_INIT, TCPTV_KEEP_IDLE, TCPTV_KEEPCNT, and TCPTV_KEEPINTVL are defined in the file target/h/net/tcp_timer.h.
IP_TCP_KEEPINTVL and also TCP_KEEPIDLE, TCP_KEEPCNT options supported by setsockopt after vxworks 6.8 version. In former releases of vxworks you can change these values globally and all the sockets created effected.
Below question is an answer for how will it be done.
How to set TCP keep alive interval for a specific socket fd (Not system wide) in VxWorks?