tcpdump usually comes as standard on Linux distros. It will log all packets visible at the server note that
you probably want to set it running with a filter for your client IP to cut down on the noise
I think this includes packets not accepted by iptables on the local machine - but you might want to test this
e.g.
/usr/sbin/tcpdump -i eth0 -c 3000000 -np host client.example.com >tcp.log
Then just run nmap from your client.
I understand that your host, 192.168.2.7 is sending multicast packet to group 239.255.250.250 on port 9131
NOTE: I assume however that servers are listening on port 9131. you didn't provide any info on this.
From ifconfig output, I can see that MULTICAST is enabled and the tcpdump confirm this.
First make sure that the host running the servers (the one receiving the multicast packet) have joined the multicast group.
On each server host type :
netstat -gn
If you see your multicast address, it has joined the group.
If not, then either something is wrong with your server program or possibly kernel settings.
If the server has joined the group but you don't see any packet incoming from client, then check on your router that you have enabled igmp ( your router must be igmp capable)
For example,on cisco router
enable
conf t
ip multicast-routing
For each interface involved.
int <NIC>
ip pim sparse-dense-mode
If igmp is enabled on router, look for debug features to track the packets.
On server side, start a packet capture :
tcpdump -i <NIC> host 239.255.250.250
If you don't see any packet coming in, then the multicast packet are not forwarded (assuming that
Then on client send a multicast packet (use the script in link below to troubleshoot)
NOTE: the UDP packet seems malformed so not sure if servers will be able to read it. You can use the script in link below to confirm whether or not the message in tcpdump are displaying as malformed or not ( they are not in my case)
Example of python code using multicast :
https://stackoverflow.com/questions/603852/multicast-in-python
NOTE: I used this script on a debian raspi ( not raspbian and server received packets through router - as setup above - fine)
Linux guide : http://stlinux.com/howto/network/short-guide
Cisco : http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_52_se/configuration/guide/3750scg/swmcast.html#wp1024278
Best Answer
That is one of the issues that might apply to UDP scanning. To be honest I have not bothered much with it. I think you can bump up the timing when you are on your nice fast local wired network. The
-T5option seems to work OK when I am scanning the same computer I runnmapon :-). In this case, it completed a full UDP scan in less than 3 minutes.Another hint: press enter while nmap is running. It will show a progress indicator.
Another way to speed it up is to not scan all 65535 ports :-). If you only want to double-check that your firewall protects the ports you think it does, you can just pass a list of listening ports that you saw in
netstat -l/ss -l. I do not tend to have many weird network services that are listening on physical interfaces but that I need to firewall, so I can just type them in manually :-P.A second issue is that UDP scans may also show programs which are not listening, only making requests, e.g. a program which sent a DNS request and is waiting for a reply. So some judgement is required. This is easiest when using
netstat -l -p/ss -l -pso they show the program name, and then you can start guessing how they are using UDP :-).The paranoia value of a real scan from a different computer, is that it would help people start noticing things like the Intel ME stupidity.