I am trying to identify if there are any UDP packet drops while receiving messages, because of my application not processing them in time.
So I would like to know packet drops at the application port level.
My application is listening on port 5018 (this is my application port.)
I would also like to mention that I checked the following command.
I checked in the file /proc//net/udp
the last column drops. Would that be the column which will provide dropped packets info at the application port level
other commands like ss, netstat, ip, ethtool they all do not seem to provide info port level. Let me know if there any other commands or procedures for me to know dropped packets dues to application at a port level.
Related
When we say firewall has blocked port 28 doest it mean that a firewall process running on a computer scans every packet it receives and if it finds a packet containing port 28 (since packet contains port information) it will not pass that packet on to particular service listening on port 28
Firewalls examine every packet coming in (and often going out). If the firewall rules dictate that the packet should be blocked, then it is not passed on. What "passed on" means depends on the context. On an end-point machine, the packet is not sent to the application handling the network traffic. On a router or firewall appliance, the packet is not sent on the output link.
The firewall can completely drop the packet, or if it is TCP connection packet it can ACK the packet then send a reset:
Rational for dropping packets:
If you run no internet facing services, dropping packets instead of rejecting them (RST,ACK) allows you to make your machine to appear to be offline to attackers (as long as you block pings etc). If you run services on uncommon (high range) ports, dropping packets on closed ports can make an attacker overlook you as they may not scan the higher ranges. However, if you run services on common ports and most ports drop packets while these ports reject them, you are actually giving information about what services your system runs. So drop on all ports or don't bother. Link
I have an online game server running on a vps with linux centos and it keeps dropping players to 0 from time to time, i have discarded problems with the application itself because it does not crash or anything, the players just get disconnected.
I was monitoring packets on my game server port with tcpdump and i caught when that happened and i noticed that an ip adress sent packets without the numerical port like usual (i belive the ip."number" is the ip.port), but is this IP.number the port?
look at the screenshoot:
http://postimg.org/image/6c4k2sdqp/
Differently of all the other normal connections it doesn't send the numerical port, and suddenly the packet listing on the tcpdump stops and my players get dropped from the server.
I was wondering if it was that wich made the connections get dropped for some reason
What's happening here is that the smart-lm port is found in the system services list:
❯❯❯ grep smart-lm /etc/services
smart-lm 1608/udp # Smart Corp. License Manager
smart-lm 1608/tcp # Smart Corp. License Manager
And so tcpdump is showing that instead of .1608 on the end. It may be a firewall between your network and the remote side (including a firewall or router on the remote side) that's causing the problem.
I have problem to open a listening port from localhost in a heavy loaded production system.
Sometimes some request to my port 44000 failed. During that time , I checked the telnet to the port with no response, I'm wonder to know the underneath operations takes there. Is the application that is listening to the port is failing to response to the request or it is some problem in kernel side or number of open files.
I would be thankful if someone could explain the underneath operation to opening a socket.
Let me clarify more. I have a java process which accept state full connection from 12 different server.requests are statefull SOAP message . this service is running for one year without this problem. Recently we are facing a problem that sometimes connection from source is not possible to my server in port 44000. As I checked During that time telnet to the service is not possible even from local server. But all other ports are responding good. they all are running with same user and number of allowed open files are much more bigger than this all (lsof | wc -l )
As I understood there is a mechanism in application that limits the number of connection from source to 450 concurrent session, And the problem will likely takes when I'm facing with maximum number of connection (but not all the time)
My application vendor doesn't accept that this problem is from his side and points to os / network / hardware configuration. To be honest I restarted the network service and the problem solved immediately for this special port. Any idea please???
Here's a quick overview of the steps needed to set up a server-side TCP socket in Linux:
socket() creates a new socket and allocates system resources to it (*)
bind() associates a socket with an address
listen() causes a bound socket to enter a listening state
accept() accepts a received incoming attempt, and creates a new socket for this connection. (*)
(It's explained quite clearly and in more detail on wikipedia).
(*): These operations allocate an entry in the file descriptor table and will fail if it's full. However, most applications fork and there shouldn't be issues unless the number of concurrent connections you are handling is in the thousands (see, the C10K problem).
If a call fails for this or any other reason, errno will be set to report the error condition (e.g., to EMFILE if the descriptor table is full). Most applications will report the error somewhere.
Back to your application, there are multiple reasons that could explain why it isn't responding. Without providing more information about what kind of service you are trying to set up, we can only guess. Try testing if you can telnet consistently, and see if the server is overburdened.
Cheers!
Your description leaves room for interpretation, but as we talked above, maybe your problem is that your terminated application is trying to re-use the same socket port, but it is still in TIME_WAIT state.
You can set your socket options to reuse the same address (and port) by this way:
int srv_sock;
int i = 1;
srv_sock = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(srv_sock, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i));
Basically, you are telling the OS that the same socket address & port combination can be re-used, without waiting the MSL (Maximum Segment Life) timeout. This timeout can be several minutes.
This does not permit to re-use the socket when it is still in use, it only applies to the TIME_WAIT state. Apparently there is some minor possibility of data coming from previous transactions, though. But, you can (and should anyway) program your application protocol to take care of unintelligible data.
More information for example here: http://www.unixguide.net/network/socketfaq/4.5.shtml
Start TCP server with sudo will solve or, in case, edit firewalls rules (if you are connecting in LAN).
Try to scan ports with nmap (like with TCP Sync Handshake), or similar, to see if the port is opened to any protocol (maybe network security trunkates pings ecc.. to don't show hosts up). If the port isn't responsive, check privileges used by the program, check firewalls rules maybe the port is on but you can't get to it.
Mh I mean.. you are talking about enterprise network so I'm supposing you are on a LAN environment so you are just trying to localhost but you need it to work on LAN.
Anyway if you just need to open localhost port check privileges and routing, try to "tracert" and see what happens and so on...
Oh and check if port is used by a higher privilege service or deamon.
Anyway I see now that this is a 2014 post, np gg nice coding byebye
I know that each port can only be assigned to one app. However, I want to do this:
(1) I want to monitor a port, such as 80. This port is already assigned by another app, such as Apache
(2) I can copy every sockets sent to that port, and redirect those ports to another port
I have searched tcpdump, it can capture packets(with whole content). But I do not how to copy packets and then send them to another port?
Or, maybe there are other tools can capture packet easily?
Can give me some details if I want to implement myself? because I am not good at socket programming.
As you correctly noted, you would not be able to use a socket to get packets from port 80 easily. THis is because if the second socket were to also receive packets for that port, then it would need to reuse the port (SO_REUSEADDR option). If the application is third-party and you cannot set this option to the server socket, then this would not work. You probbaly could try checking out scapy which has an option of sniffing packets and see if it meets our requirement: http://www.secdev.org/projects/scapy/doc/usage.html .
I have 2 linux based systems - a client with 2 interfaces (1 LAN, 1 modem) and a server.
I open 2 UDP sockets, and use setsockopt with SO_BINDTODEVICE to bind each socket to it's interface.
Then I send a message from client to server through each of those sockets.
Both of them reach server. Server socket reads them, and sends a reply to each of them.
Then I try to read server's reply on the client.
BUT, there is only 1 reply.
Also if I run tcpdump, I see that both of the replies are received on their relevant interfaces, on the same port that they left. Yet only one of them reaches socket. The other is lost?
The "lost" packet is not random, it's the "non" default one. If my routing table is empty, the modem one is lost. If I add a route to server ip from modem interface, the lost packet will be the lan one.
Yet, they always reach server, always return back, always seen in tcpdump, but 1 never reaches socket. How can that be?
There is an ipv4 network configuration parameter called rp_filter (reversed path validation filter). Basically, if the reply to a packet wouldn't go out the interface this packet came in, then this is a bogus packet and should be ignored. Which is why while I saw the packet on the tcpdump, it never reached socket. Disabling it did the trick.
sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.eth0.rp_filter=0
sysctl -w net.ipv4.conf.ppp0.rp_filter=0