Tag Info

Hot answers tagged

52

Looking at the RFC for TCP: RFC 793 - Transmission Control Protocol, the answer would seem to be no because of the fact that a TCP header is limited to 16-bits for the source/destination port field.      Does IPv6 improve things? No. Even though IPv6 will give us a much larger IP address space, 32-bit vs. 128-bits, it makes no attempt ...


36

You probably want to use the ServerAlive settings for this. They do not require any configuration on the server, and can be set on the command line if you wish. ssh -o ServerAliveInterval=5 -o ServerAliveCountMax=1 $HOST This will send a ssh keepalive message every 5 seconds, and if it comes time to send another keepalive, but a response to the last one ...


28

netstat -lnp will list the pid and process name next to each listening port. This will work under Linux, but not all others (like AIX.) Add -t if you want TCP only. # netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:24800 ...


27

Nmap is a great port scanner, but sometimes you want something more authoritative. You can ask the kernel what processes have which ports open by using the netstat utility: me@myhost:~$ sudo netstat -tlnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 ...


25

The idea behind this is to ensure you don't receive packets targeted for the previous program listening on that port. This TIME_WAIT state is defined in RFC793 as two times the maximum segment lifetime. I don't know about other Operating Systems but I assume that all of these have some kind of similar behavior. A workaround for this problem is to set ...


25

Apart from not getting detailed information about your test setup the main problem seems to be, that you use a message size of 64 byte. This is far away from the usual MTU of 1500 bytes and makes UDP highly inefficient: while TCP merges multiple sends into a single packet on the wire (except if TCP_NODELAY is set) to make efficient use of the link, each UDP ...


23

Suppose you're exchanging data with a computer on a port <1024, and you know that computer is running some variant of unix. Then you know that the service running on that port is approved by the system administrator: it's running as root, or at least had to be started as root. On the wide, wild world of the Internet, this doesn't matter. Most servers are ...


23

Just to make sure we're on the same page (your question is ambiguous this way), asking to bind TCP on port 0 indicates a request to dynamically generate an unused port number. In other words, the port number you're actually listening on after that request is not zero. There's a comment about this in [linux kernel source]/net/ipv4/inet_connection_sock.c on ...


18

What do the three rules do? Those 3 rules seem pretty self-explanatory: Reject incoming UDP packets with an ICMP message "port unreachable" Reject incoming TCP packets with "tcp reset" Reject incoming packets (of any other protocol) with ICMP message "protocol unreachable" If you're looking for more detail (about UDP/TCP packets, ICMP), you need to ...


16

UNIX domain sockets should offer better performance than TCP sockets over loopback interface (less copying of data, fewer context switches). Beware though that sockets are only reachable from programs that are running on the same server (there's no network support, obviously) and that the programs need to have the necessary permissions to access the socket ...


15

setcap 'cap_net_bind_service=+ep' /path/to/program this will work for specific processes. But to allow a particular user to bind to ports below 1024 you will have to add him to sudoers. Have a look at this discussion for more.


14

You can define a new 'tunnel' in your Subversion configuration (~/.subversion/config). Find the section [tunnels] there and define something like: [tunnels] foo = ssh -p 20000 Afterwards you can contact your repository via the URL svn+foo://server.com/home/svn/proj1 proj1.


13

In /etc/ssh/sshd for Computer B set: AllowTcpForwarding yes TCPKeepAlive yes From Computer A: $ ssh -R 2222:localhost:22 ip.of.computer.b From Computer B: $ ssh localhost -p 2222 Note that 2222 is an arbitrary high-port number I picked. That port on Computer B will then be tunneled back through the SSH connection initialized on Computer A to port ...


13

There was a time when IANA only assigned ports up to 1023. See RFC1700. At one time this was a standard. Most of the time I have no trouble finding when things change in the stream of RFC's but for the question of changing ports from 1024 to 49152 from registered to assigned I came up short. In terms of Linux history, there was a question raised about the ...


12

I too have wondered this and was motivated by your question! I've collected how close I could come to each of the queues you listed with some information related to each. I welcome comments/feedback, any improvement to monitoring makes things easier to manage! net.core.somaxconn net.ipv4.tcp_max_syn_backlog net.core.netdev_max_backlog $ ...


12

t_open() and its associated /dev/tcp and such are part of the TLI/XTI interface, which lost the battle for TCP/IP APIs to BSD sockets. On Linux, there is a /dev/tcp of sorts. It isn't a real file or kernel device. It's something specially provided by Bash, and it exists only for redirections. This means that even if one were to create an in-kernel /dev/tcp ...


12

The quick way The quickest way to transfer files over a LAN is likely not rsync, unless there are few changes. rsync spends a fair bit of time doing checksums, calculating differences, etc. If you know that you're going to be transferring most of the data anyway, just do something like this: user@dest:/target$ nc -q 1 -l -p 1234 | tar xv ...


12

First check on the config file which port is configured: $ sudo grep Port /etc/ssh/sshd_config Port 22 Then either restart ssh to make sure it loads the config you just saw or find out on which port ssh is running: $ sudo netstat -tpln | egrep '(Proto|ssh)' Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ...


12

However, are there any other clever tools/methods to see if process listening on TCP port receives a message? You can use strace with -e trace=network. This is what it prints on accepting a TCP connection, receiving an HTTP request, sending an HTTP response and closing the connection: $ strace -v -f -e trace=network -p `cat logs/my_server.pid` Process ...


11

It's for convenience, but it's also a lower-than-user-level diagnostic. You can isolate the problem you're having with a service that way, for example: Joe has a database server and client. They are not communicating. Is the problem on the network? The server? The client? Joe goes to the client machine and opens a shell. He uses telnet, just as you ...


11

A Linux system has a so called loopback interface, which is for internal communication. Its hostname is localhost and its IP address is 127.0.0.1. When you run nmap on localhost, you actually run the portscan on the virtual loopback interface. 192.168.1.1 is the IP address of your physical (most likely eth0) interface. So you've run nmap on two different ...


10

(Some of these methods have been mentioned in other answers; I'm giving several possible choices in rough order of preference.) You can redirect the low port to a high port and listen on the high port. iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 1080 You can start your server as root and drop privileges after it's started ...


10

You can put a -n option to lsof and then it remove the DNS resolution, which can accelerate the display


8

Using ssh is the easiest solution. ssh -g -L 8001:localhost:8000 -f -N user@remote-server.com This forwards the local port 8001 on your workstation to the localhost address on remote-server.com port 8000. -g means allow other clients on my network to connect to port 8001 on my workstation. Otherwise only local clients on your workstation can connect ...


8

No, there is no timeout for CLOSE_WAIT. I think that's what the off means in your output. To get out of CLOSE_WAIT, the application has to close the socket explicitly (or exit). See How to break CLOSE_WAIT. If netstat is showing - in the process column: are you running with the appropriate privileges and capabilities (e.g. as root)? they could be ...


8

Yes. By putting network interfaces into promiscuous mode, tcpdump is able to see exactly what is going out (and in) the network interface. tcpdump operates at layer2 +. it can be used to look at Ethernet, FDDI, PPP & SLIP, Token Ring, and any other protocol supported by libpcap, which does all of tcpdump's heavy lifting. Have a look at the ...


8

You can use netstat -anp | grep 57010 on server C. But this will only work if there isn't any firewall in between which is mapping port 57010 to a different one.


8

One way is to say lsof -i:57010 -sTCP:ESTABLISHED. This walks the kernel's open file handle table looking for processes with an established TCP connection using that port. (Network sockets are file handles on *ix type systems.) You'd use -sTCP:LISTEN on the server side to filter out only the listener socket instead. Because of the way lsof works, it can ...


8

This is does not matter whether you create tcp connection as a root or regular user. Socket creation is a kernel business and TCP connections is a Transport Level of OSI model But software you use (Application level) can contain software vulnerabilities and hacker can exploit them. So the basic recommendation is not to execute application as with a root ...


8

If you just want to get the number and don't need any details you can read the data from /proc/net/sockstat{,6}. Please keep in mind that you have to combine both values to get the absolute count of connections. If you want to get the information from the kernel itself you can use NETLINK_INET_DIAG to get the information from the kernel without having to ...



Only top voted, non community-wiki answers of a minimum length are eligible