By default, as stated in the documentation of syslog-ng, the default Transport Protocol used by syslog-ng is TCP.,
If I don't configure the Transport Protocol, but instead I configure PORT 514 which is the default UDP port, what will happen? Will the communications go over TCP or UDP?
The syslog() and network() drivers of syslog-ng use TCP by default. Setting the port() option to 514 without specifying transport() means 514/tcp.
Related
I'm trying to set up some port forwarding to enable a device which lies inside my private home network. It requires a number of ports to be forwarded and a number of guides I have read regarding setting this up says to set port x TCP to forward, port y UDP to forward, and occasionally uses the phrase "Internet Protocol Port" z. What is Internet Protocol ports vs UDP/TCP? Does that mean both UDP and TCP? I've never seen something that forwards IP ports; only TCP/UDP.
I am familiar with TCP and UDP, just not the term "Internet Protocol Port". Where would I port forward an IP port in DD-WRT if not using TCP/UDP?
I see now that I mixed up the terms in my head after reading through the guides. It was Internet Protocol "ID", not "port". That term refers to a pool of protocols of which UDP and TCP are examples. When that guide says to enable Internet Protocol ID it is asking to enable Authentication Header which I gathered is a protocol in itself at the level of UDP or TCP.
Source: http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
Is it possible to send/receive udp over port 8080? Everything I see says 8080 is strictly a TCP port. I don't quite get why that would be?
Port 8080 is used by TCP or UDP. There is no restriction of Kernel for opening ports 8080 UDP. What happens is that there is a convention to use port 8080 as TCP, like squid proxy, but nothing prevents you from using UDP in it.
Can I disable the ACK mechanism for TCP connections. In my country the DPI is activated for VoIP which blocks the remote end IP. (weather used with openvpn or IPsec or etc). However they are not monitoring TCP. the VoIP operates at TCP but the quality is very bad due to ACK function. I did try some DELACK but did not paid me off much. Could it be possible that I can disable the ACK in TCP protocol using some patch or some thing so I can operate VoIP with it. My servers are Linux CentOS based.
No.
TCP without ACK isn't TCP.
If you were to hack the TCP stack somehow and prevent ACKs being sent then all kinds of things would stop working. You would need to adjust your version of TCP to the point where it simply wasn't TCP anymore. You would then need it running at both ends of the connection.
Does SIP v2.0 permit to have the protocol running over non-standard ports
(not 5060)? I've checked through the specification, but wasn't able to find
an answer. It looks like a port can be negotiated and determined during a
registration phase, but I could not confirm this with RFC.
Yes, port 5060/5061 are just the default ports if no other port is given. RFC3261 also only gives listening to port 5060/5061 as a recommendation;
It is also RECOMMENDED that a server
listen for requests on the default SIP ports (5060 for TCP and UDP,
5061 for TLS over TCP) on all public interfaces.
For example, if you use DNS lookup according to RFC3263, the port is looked up at the same time as the address;
That lookup would return:
;; Priority Weight Port Target
IN SRV 0 1 5060 server1.example.com
IN SRV 0 2 5060 server2.example.com
Well Yes you can use the other ports for sending Sip packets... Port Forwarding is a Hint...
If i established openvpn connection through udp(proto udp), can i use tcp in it(tcp convert to udp somehow), or only udp?
In short: Yes, you can send TCP through an VPN-Tunnel which is transported via UDP.
In fact you can tunnel any protocol support by OpenVPN no matter what transport you choose.
You can use any protocol you like, even raw IP. OpenVPN simulates a fully-fledged network device (to some extend – whether it's based on the Ethernet or the IP layer depends on configuration) which behaves like any other network adapter. So you can of course use TCP and UDP in it.
The packages sent via the OpenVPN devices are encrypted and passed through the UDP “connection” used by OpenVPN to the remote side, where they're decrypted and passed on to routing to forward them to their final destination (which might be the remote itself).