Has anyone ever looked into forming and sending test UDP packets from Bash? I need to test some UDP ports in addition to TCP ports in a piece of code. TCP is easy since its connection oriented. UDP on the other hand is a little more challenging. I would assume the packet would have to be built and sent out, then bash would have to wait for a reply, or timeout to determine if the port is open on the other end. Other utilities can be used, however I'd like to try to avoid it since it was so easy to do straight with Bash for TCP. Any thought on how to do this? The goal is a port check tool to monitor servers. Yes there are other tools out there like NMAP, but I don't need a complex port scanner.
* UPDATE *
Took Barmar's suggestion and tried using netcat, but I cant get it to work with UDP. The terminal just gets stuck whenever I try UDP:
netcat -uvz 8.8.8.8 53
This doesnt work either and this is a straight example from Google
nc -vnzu server.ip.address.here 1-65535 > udp-scan-results.txt
* UPDATE *
For those who say "you can't do that with netcat", can you explain why all these people say you can? Whats the deal netcat...
http://www.radarearth.com/content/using-netcat-udp-port-troubleshooting
https://gist.github.com/benhosmer/2429640
http://www.thegeekstuff.com/2012/04/nc-command-examples/
* UPDATE *
Here is yet another:
http://mikeberggren.com/post/16433061724/netcat
* UPDATE *
And here is some other evidence that contradicts everything above... sigh
Very bottom of page, under "Caveats"
http://linux.die.net/man/1/nc
* SOLUTION *
This ultimately helped me understand my own logic. Hopefully it will help others out there too.
http://serverfault.com/questions/416205/testing-udp-port-connectivity
There are different tools that allow for sending UDP packets, e.g. hping and nmap.
hping host.example.com --udp -V -p 53
nmap -sU -p 53 host.example.com
However, unlike TCP UDP does not establish a connection, i.e. you're don't automatically get a response.
Related
I'm attempting to write a script to connect to a DLNA audio renderer.
There are a few articles on the web giving information on how to do this using UDP and curl, however in my particular scenario I'm having some difficulties.
The first step is to send a UDP multicast announcement over the network to discover DLNA devices on the network.
The message sent to discover devices is:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MX: 5
Man: "ssdp:discover"
ST: urn:schemas-upnp-org:device:MediaRenderer:1
All lines in this message sent over UDP should have crlf line endings and the last line should have an extra crlf according to this article
That all seems fine. And if the message above is in a file devicediscovery.txt supposedly it's possible to use netcat to send out this message:
cat devicediscovery.txt | nc -u -4 239.255.255.250 1900
239.255.255.250:1900 is the multicast address and port over which DLNA devices communicate.
This all seems fine too, however, as is pointed out in the linked article netcat ignores the response from the dlna media renderer because there is a mismatch in IP addresses the message is sent out over the dlna multicast address, though the response comes from the router. The article suggests using tcpdump to capture the response, however I'm on Windows and using Bash on Windows WSL so tcpdump is not available and such a technique would possibly be complicated when developing a script to automate the dlna connection.
Would it be possible to use two seperate instances of netcat? One instance sending the message over the dlna multicast address and the other listening for the response from the router?
I have tried to get this working, however I'm unsure which port netcat should be listening on to hear the incomming response. Is there a standard port that netcat should listen on?
I've tried commands such as: nc -luv 192.168.0.1, however I get an error Servname not supported for ai_socktype. I've tried to remedy this by playing around with /etc/services but had no luck.
What command can I use and how must I configure the system to listen for the response from the search for dlna devices? I'd like to parse the response in a script so that the dlna connection can be automated.
Although you mention issues with DLNA it looks that you are really asking for how to best troubleshoot this.
Network cards don't allow access to incoming traffic unless set in promiscuous mode. Netcat won't be able to do what you need because of this. But, you can use Wireshark to read the traffic on the interface. TCPdump and Wireshark have close ties and almost interchangeable.
https://www.wireshark.org/
I would recommend to use it to troubleshoot further. Ppost the capture (not just a picture) and show where it failed.
I want to have a generic shell script which will check network connectivity between two hosts.
I wrote shell script with host and nslookup command to get the more details of target host, with these command I can't determine if current host can talk to target host.
Also I can't use(restricted) ping command , I was wondering if can use some other command to check network connectivity betweenn two hosts
Please suggest
Given a target host to determine if source host can communicate to target host
This is too vague to be useful. To solve this problem, you need to nail down what you mean by "communicate." A host may be able to send ICMP but not TCP. It may be able to send TCP but not ICMP. It may be able to send TCP to port 80, but not to 22. It may be able to send HTTP to port 80, but not SSH to port 80. Packets you send may return an error, or they may be silently dropped. The endpoint may receive your packets, but not process them. It may process them but not respond to you. There are many levels of "communicate."
So the best thing to test with is the thing you actually want to do. So if you want to communicate with HTTP over port 80, the best test is to do that. In fact, the best test is to just do the thing you wanted to do and not check beforehand. You're going to have to deal with errors no matter way. Just because you checked beforehand doesn't mean your actual attempt will be successful.
But sometimes you do just want to check "connectivity" (for some value of "connectivity") for monitoring purposes. In that case, again, do the thing you want. The easiest shell tool for checking HTTP connectivity is to fetch something with curl. If you need some other port, then a very nice generic solution is netcat (often called nc). I like:
nc -G 1 <host> <port> </dev/null
A return code of 0 means it connected; 1 means it failed.
For more esoteric issues, you can use nmap or even hping to craft about anything you want.
But most of the time, you shouldn't check at all. And if you do check, check with the thing you really want to do.
I'm trying to use Pcap.Net to open a tcp connection.
I'm sending following package:
The server is responding with:
After this, Windows on its own sends the reset packet:
Why is this happening, and how do I block this behavior?
I'm doing this on Windows 7
As Mr Harris says, you can use WinDivert to do what you want. E.g. to just do the TCP handshake, you can write something like the following:
// TCP handshake using WinDivert:
HANDLE handle = DivertOpen("inbound && tcp.SrcPort == 80 && tcp.Syn && tcp.Ack", 0, 0, 0);
DivertSend(handle, synPacket, sizeof(synPacket), dstAddr, NULL);
...
DivertRecv(handle, synAckPacket, sizeof(synAckPacket), &srcAddr, &length);
...
DivertSend(handle, ackPacket, sizeof(ackPacket), dstAddr, NULL);
...
The DivertRecv() function redirects the server response into user space before it is handled by the Windows TCP/IP stack. So no pesky TCP RST will be generated. DivertSend() injects packets.
This is the main differences between WinDivert and WinPCAP. The latter is merely a packet sniffer, whereas the former can intercept/filter/block traffic.
WinDivert is written in C so you'd need to write your own .NET wrapper.
(usual disclosure: WinDivert is my project).
Essentially, the problem is that scapy runs in user space, and the windows kernel will receive the SYN-ACK first. Your windows kernel will send a TCP RST because it won't have a socket open on the port number in question, before you have a chance to do anything with scapy.
The typical solution (in linux) is to firewall your kernel from receiving an RST packet on that TCP port (12456) while you are running the script... the problem is that I don't think Windows firewall allows you to be this granular (i.e. looking at TCP flags) for packet drops.
Perhaps the easiest solution is to do this under a linux VM and use iptables to implement the RST drops.
Either by using Boring Old Winsock to make a TCP connection to the server, rather than constructing your own TCP-over-IP-over-Ethernet packets and sending them to a server, or by somehow convincing the Windows Internet protocol stack to ignore the SYN+ACK (and all subsequent packets) you get from the server, so that it doesn't see the SYN+ACK from the server, notice that no process has tried to set up a TCP connection from 192.168.1.3:12456 to 192.168.1.1:80 using the standard in-kernel networking stack (i.e., nobody's tried to set it up using Boring Old Winsock), and send back an RST to tell the server that there's nobody listening at port 12456 on the machine.
You might be able to do the latter using WinDivert. It does not itself appear to have a .NET wrapper, so you might have to look for one if you're going to use .NET rather than Boring Old Unmanaged C or Boring Old Unmanaged C++.
I am looking for UDP debugger tool, for the following requirement
1) netstat -s, shows udpInOverflows=23000 and this counter is increasing continuously.
how can I check udp packets which are thrown because of no buffer space.
2) what are the possible reason for this problem to occur and how to solve it.
3) is there any way to check incoming UDP packet which are received by kernel after all verification like udp socket is open for that port and no check sum error, snoop will not work because it capture direct from network interface.
Regards
Nitin
If you are willing to spend a little time with kernel source you should be able to use dtrace to get at the information you want. For example "dtrace -n 'fbt::udp_input:entry{stack();}' will show you how packets are getting into udp_input (not all that interesting). You should also check the mib::: probes and fbt:ip:ip_drop*:. This is all dependent on the version of Solaris you are using of course.
I'm trying to see the results of an incoming ping on a target windows machine. This is needed to verify that the ping, which is running in a background thread, is being sent from the originator.
I have tried netstat to no avail. Are there any other approaches I could try?
Thanks.
Ping is an ICMP packet and doesn't create a TCP connection (hence you won't see it in netstat). On Linux, I'd add a rule to the firewall.
The most simple solution for your case might be to open a connection and close it. That will add it to the output of netstat with WAIT_CLOSE.
As Aaron Digulla already noted, ping is ICMP. This also means the originator even less trustable then with TCP; there's no SYN/ACK handshake. You just get an IP packet on your host, and you have to trust the header fields. Anyone can spoof those header fields, with almost no restrictions (It might be a bit challenging to get an IP claiming to come from 127.0.0.1 past a router)
Therefore, ICMP is not suitabel for verification tasks. You need a challenge/response protocol. TCP works reasoanbly well as long as you can trust the network but not necessarily all hosts on it (a reasonable assumption for the Internet. Not strong enough for financial transactions, which is why they use SSL)