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.
Related
I'm working on a custom yocto Linux for a Raspberry PI 3 and try to get the WIFI connection working with SSH. However when trying to connect from my PC (Ubuntu 19.10, SSH OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c 28 May 2019) to the PI on which Dropbear v2019.78 runs, the connection attempt times out. But only when I try this via SSH, and via wlan0. Other TCP/IP traffic works, and also using the same participants but with eth0. As this is for a robot, I would prefer to not use a tether though...
To try & debug this, I
enabled a serial console so I can work on the PI
disabled eth0
started a tcpdump on the PI (ip.host == 192.168.0.105)
started a tcpdump on the PC (ip.host == 192.168.0.106)
used a dirt-simple TCP/IP socket example written in Python (taken from https://realpython.com/python-sockets/#echo-server) to verify I can in fact communicate. The transmission is successful. I am aware that the example is lacking (no proper protocol etc), but that's not the point of it. It just works enough. The PI runs the server listening on port 2222.
attempted a SSH connection, it timed out.
I filtered the resulting PCAP down to contain just TCP, as there is other information (e.g. Dropbox discovery) that I don't think matters and might potentially be information leaking. On the host side (enp4s0-tcp-and-pi.pcap) I also filtered with ip.host == 192.168.0.105 to only contain any traffic to the PI.
Another note on my setup here: I use a TP-Link router which LAN ports the PC is connected to, and who provides the 2.4GHz WIFI for the PI. So both are part of the same subnet, and no special routing or anything is configured.
Also I stopped the dropbear daemon and adapted my Python code to use port 22. It works.
I'm only broadly aware of the inner workings of TCP, so I can't really make much sense of the things I see here. Any insights are more than welcome.
https://www.dropbox.com/s/5o4rqr5zdws2wq7/wlan0-tcp-only.pcap?dl=0
https://www.dropbox.com/s/amypjtk1nvja4qb/enp4s0-tcp-and-pi.pcap?dl=0
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.
This is what I am trying to do:
I have a windows computer and a Linux computer (ubuntu 16.10) connected to the same wireless router. The router is not connected to the Internet, as this might raise some security concerns (and we don't want the windows computer to talk to the net).
The windows computer is running a program that is supposed to stream data to an UPD port (say port 1234). Using the Microsoft TCPView utility I can see that the windows machine opens the port. In fact, it should allow connections from any IP address and any port (that's what the *'s mean in TCPView).
View of the TCPView Utility
When I try to find the open port on the windows machine from the Linux computer using nmap this is what happens:
Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-30 16:50 EST
Nmap scan report for 192.168.0.164
Host is up (0.051s latency).
PORT STATE SERVICE
1510/udp open|filtered mvx-lm
MAC Address: 74:DE:2B:D8:26:24 (Liteon Technology)
At the very least, this tells me that the linux machine can see the windows machine (I can also ping it). However, I am not sure about the open|filtered state of the port. According to the Nmap manual:
Nmap places ports in this state when it is unable to determine whether
a port is open or filtered. This occurs for scan types in which open
ports give no response. The lack of response could also mean that a
packet filter dropped the probe or any response it elicited. So Nmap
does not know for sure whether the port is open or being filtered. The
UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.
When I try to connect to the port using Python, an error occurs. This code
import socket
UDP_IP = "192.168.0.164"
UDP_PORT = 1234
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))
results in an error 'connection refused'. A little C++ client program that is supposed to read out the streamed data also fails to connect to the port. I am using Python now to test the accessibility of the port more quickly.
In contrast, connecting to TCP port 8080 works fine. Also, I have been sending data back and forth over TCP through the same router between other machines and using a range of ports.
Other important info:
The same errors occur if I switch off the firewall and virus scanner on the windows machine
I have added UDP port 1234 as an allowed connection in the advanced firewall settings of windows.
So, my questions are:
Does anybody have any suggestions about how to debug/solve this situation?
What's different between UDP and TCP that would cause TCP to work without a hiccup (in my past projects) and causes UDP to give me nightmares?
You are forgetting that UDP is not a connection-based protocol. It is a datagram protocol.
There is no way to distinguish between a server that is receiving UDP packets but not responding to them, from a server which is behind a firewall which drops those packets. This is why nmap is describing a port as open|filtered -- there is no way for it to tell the difference.
Your call to sock.bind is failing because you are trying to bind (that is, to start listening for packets!) to a port on a remote IP. This is impossible in general.
It turns out that my problems were two-fold
1) I did have a bad understanding of the UDP protocol. That's been rectified by the answers in the forum. For anyone interested in how to use UDP and Python to communicate between two computers, see this recipe: http://code.activestate.com/recipes/578802-send-messages-between-computers/
2) The windows program that I was trying to communicate with can not be used to to send data over UDP through wifi. Why? I don't know. I called the developer and that's what he told me.
Current status: the problem is not solved but is diagnosed as a combination of my lack of knowledge and an ideosyncratic windows program (see my original post above)
You are trying to bind to a non-local IP address. Use 0.0.0.0 instead of the target address you're using, and connect() or sendto() the target address.
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
For the sake of simplicity, I will refer you to http://en.wikipedia.org/wiki/Berkeley_sockets and the UDP server and client source code there.
I am trying to send a packet using UDP protocol to a linux VirtualMachine server program. Both my host and VM ping well; all packets sent are received in both directions. However my server program is either not receiving any packets, or it is simply not printing. Either way, it isn't printing the confirmation or contents of any packets I send to it from the host.
I do not have another PC handy, but both programs communicate well enough if I stage them on the same computer and Wireshark reports that the packets are being sent.
Mine is a three part question: first, how can I fix this. Second, why would the host and VM receive each others ping messages, but not pass these on to the open sockets of both ends of my UDP system? Finally, do you have any suggestions about the form or intent of this question?
EDIT: I've tried running my VM with the NAT and bridged adapter network setups. However, I can't conceptualize the relationship between those setups and my problems right now.
With NAT networking, the VM gets a private IP address (usually 192.168.x.y) and the host does NAT translation of outgoing packets, and translates reply packets back to the VM. In this mode, all communication must be initiated by the VM -- outside machines can only send packets to the VM in reply to packets the VM sent to them. On the network, the packets will look like they're coming from/going to the host on some unrelated port.
With bridged networking, the VM gets a device that connects directly to the host's network device. In this mode, the VM appears as a separate machine on the same network LAN as the host, with its own IP address. You need to allocate an IP address for it, the same as the host get allocated an IP address (usually via DHCP).
In either case, to debug what is going on, use tcpdump/wireshark on the host to monitor the host's network device. Send packets from the VM, and you should see them in the trace -- they'll appear to come from the host and a different port in the NAT case, and will appear to come from the VM's IP address (and unchanged ports) in the bridged case.
Once you see that, you should be able to send packets back to the VM, though in the NAT case, they must come FROM the address/port the original packet(s) were sent to.
There are known issues with VirtualBox bridged networking not working properly on wifi devices; in general you can only use bridged networking with wired networks.
Oracles VB manual page clear all the terminology used in settings.
I've had similar problem, where my VB program didn't receive any packets, which I solved by setting "Bridged Networking" and setting up proper source/destination IP address in my program by analyzing WLAN interface with wireshark and using ifconfig (or ipconfig) in terminal.