I have an application that is very simple. It sends out UDP packets to a client somewhere else on the network.
The host computer is 192.168.11.66 (Windows 10), the client device is 192.168.11.65 (proprietary device).
The host pc cannot see the client device, however I know that it is on and listening to traffic. When I send UDP packets from the host, I use Wireshark and I do not see the packets being sent out. Instead I see messages from ARP trying to locate the client. I assume because ARP is unsuccessful, the host cancels the sending of the packets.
If I change the destination address of the packets to a broadcast address, all of the packets get sent and I see everything on Wireshark. I need to be able to specify the IP address of the client and have Windows send the packets regardless of whether or not it thinks the client device is on the network or not. The client device looks for UDP traffic specifically addressed to itself and the client device has no way of making itself visible on the network.
Does anyone know how to work around this?
Thank you #Remy: instead to create your own ARP record manually. – Remy Lebeau
I did not realize that I could create manual entries in the ARP. I need to read more about ARP. Adding a manual entry solved my issue. I found that you could do it using ASP -s, or add neighbor using NETSH .
Thanks!
I have been reading about setting up a ping tunnel to access the internet when you can only send ICMP packets. Ptunnel seems to be a popular program and the instructions to use it can be found here http://www.cs.uit.no/~daniels/PingTunnel/. The instructions to this program say that you must have both a client and proxy computer.
I do not understand the benefit of a ping tunnel if you must have a proxy computer that can send TCP/IP packets. If I had a computer that could do that, I wouldn't need to set up the tunnel in the first place. Can someone please explain this to me, why is a proxy necessary and if it is how is ping tunneling useful then?
NSNolan
Well, let's assume you have a server (PC running linux for example) in your home where it has total internet access and now you are at work/airport/hotel with your laptop where you have no access to tcp without paying.By setting an icmp or dns tunnel you can "encode" your packets to appear as if they were pings/nslookup, those packets destination is always your server. When the server recieves those pings from you, it "decodes" them and totally understand what you are trying to reach (like a website or download a file as an example).
Then your server serves you and get the information you are seeking and "encode" them again into icmp/nslookup like packets. Those packets can reach you without any problem and once they do, your laptop can decode them back into useful information (just like the ones it would recieve with tcp). That encoding & decoding are what the Ptunnel do. Though I'm not professional I think that is the total point.
I can't wrap my head around how packet-sniffers can be used by anyone on the network.
I know very little about how networks work, but let me put it this way: suppose the mailman comes around delivering a package to my doorstep. Why is is that I'm able to rifle though all his other packages and look around? Shouldn't the mailman only hand me packages that are mine?
To quote William Pursell's comment, which he should have made an answer and should have expanded:
The mailman does not deliver the letter your doorstep. Instead, he opens your mail and shouts out: "this letter is for <name>. No-one else should listen" and then proceeds to read the letter out loud. –
In the original Ethernet network, there was a shared cable to which all hosts were attached; if a host wanted to send a message to another host, it would transmit the packet on the shared cable, with an Ethernet header with the destination Ethernet address of the other host. All hosts on the cable could, in theory, see the packet. (This was in an era where security was less of a concern; for cases where security was a concern, the packets were encrypted in a fashion that the other host could fairly easily decrypt but that other hosts would have to decrypt in some other more difficult fashion.)
In addition, a packet can be sent to the "broadcast" Ethernet address (all 1's) or a "multicast" Ethernet address (which several hosts are configured to handle); broadcast packets are intended for all hosts on the Ethernet to see, and multicast packets are intended for all hosts in the address's "multicast group" to see.
Normally, an Ethernet adapter would ignore packets that aren't sent to its Ethernet address, to the broadcast Ethernet address, or to a multicast address for which it's configured to receive packets. Most can, however, be put into "promiscuous" mode, where they pass all packets to the host; that mode is used for packet sniffers.
Most current Ethernets are "switched"; instead of a shared cable, there's an Ethernet switch, and hosts plug into the switch with a cable. Packets sent to a particular host's Ethernet address will only be sent out the switch port for that host (unless somebody's configured the hosts to have a "mirror port" on which all traffic is sent, or unless the switch hasn't yet determined which port is the port for that Ethernet address). Broadcast packets are sent to all ports, and multicast packets may be sent to all ports or, if the switch can determine that, to those ports that have adapters configured for the multicast address in question.
Wi-Fi networks are similar, but they're usually protected with encryption, as it's easier for somebody to bring in a laptop and put it into "monitor mode" to sniff on a given channel than it is for somebody to bring in a laptop, configure a switch to have a mirror port (or use some other mechanism to get access to the traffic), and plug the laptop into the appropriate port on the switch.
Generally speaking, with switches you are correct. However the person who owns the switch can intercept your traffic at will (in your example that would be the mail service). Also, sometimes the switch can be fooled into rerouting traffic (someone accepts the package on your behalf and then goes through it).
Furthermore, certain kinds of packets need to be broadcast. For instance ARP packets (where one computer is asking for the ethernet address of another computer specified by IP) get broadcast to all ethernet addresses and therefore can get sniffed.
Generally speaking man-in-the-middle requires someone in the connection chain to be compromised. For instance, your ISP or the company they buy transit from could create a man in the middle attack. (This is also why security in countries oppressive regimes is so difficult, they control the internet and therefore can sniff/man-in-the-middle attack whatever they please). This can also be done by compromising the DNS server you use to point you to a different site that can grab your data and forward your data (or a modified version thereof) on to the true site.
In the good 'ol days hubs were quite common (or even older, everyone shared a piece of coax). In this case it's more like the package gets dropped on the first door, the occupant looks to see if it's theirs, if not, passes it on, if so, copies what's inside and passes the package along. In other words, packet sniffing is actually quite easy.
Yes or more simple way packet sniffing not is good, while you login on the web page you normal use a secret password for verify this is you.
But in case we has a packet sniffer she/he can also see and read what you password is.
And laiter login in the web page as you.
Or in she/he can also modify you data on the road to do something other.
And in the case of internet, the normal way is more the one computer is use to
send a message from in this case Alice to Alice bank.
And in each of this computer ( right side of image ) is this possible
for the use to edit the message if the use want as in this image.
Eva is use for deliver the message to Alice Bank, but she can
can read the message/order and in some case edit this to get the bank
to think Alice want to transfer money to Eva instead of Bob.
In short for protect us against eva to modify the message we can use
hash-algorithm or cryptographer algorithm.
I am working on a project that involves a usb device, through which we will receive ip packets from a remote pc. We assign the remote pc its IP Address. I have been experimenting with sending raw ip packets via several methods:
1 - raw sockets: ping works fine, problems sending tcp
2 - tun/tap W32: I managed to get this working enough to send pings out and get pings back to the phy ethernet device, but could not read them using ReadFile(...) on the driver guid.
3 - winpcap: ping works, out going tcp shows up on wireshark(so I assume it is leaving the pc), but i never get an ack to my syn. Im also worried that if I did get an ack the windows TCP stack would send a rst.
Our goal is to be a transparent pass through from the client pc to the network.
Client <-wrapped ip packet-> [device] <-wrapped ip packet-> WinPC <- IP -> IpNetwork
Its possible that im going about this wrong, seems like this should be easier.
I realize that windows is prob not the ideal OS for this, however I have no control over the OS.
thanks in advance
Fixed my issue with TCP Syn packets not getting acked, turns out I forgot to include the pseudo-header when calculating the TCP header checksum. Now it looks like the tcp handshake completes, so im calling this problem solved. If anyone feels like recomending a better way to accomplish this, feel free to reply. For now looks like we will use the winpcap method.
Update:
For this to work without windows constantly RST'ing tcp connections, you have to enable internet connection sharing(ICS) on the adapter you are sending packets out of. Other than that this ended up working for us.
I often run into problems where I can't get something to connect to something else. I usually forget to check something obvious. Can you help with:
A tip/technique for diagnosing a connection issue
The name of a tool or application that can help (and the situation in which it's useful)
I know the question is a little non-specific, but hopefully the answers can form a useful starting point for anybody who's stuck trying to get computers/programs talking to each other.
Please can you give one answer per answer so the best ones can be voted up.
Simple checks to run when debugging network problems:
Has each machine got an IP address, Go to command prompt and run ipconfig. Key things to check here are the interfaces and ensuring the appropriate ones have IP addresses.
Check both machines IP addresses are in the same range and subnet if you are running it on an internal or Virtual network.
Try pinging each machine from the other to see if they can communicate with each other. Note that some firewalls will block ping requests.
If Pinging fails then check to see if firewalls are active. If the communication is within a 'safe' internal network then try disabling the firewalls and re-pinging.
If the connections are over a wireless network then check signal strength.
If pinging fails and you are connecting through several networks then try running a tracert to see at which will may show you where on the network the connection is failing.
If you are able to ping but not connect then check firewall settings and network connection settings. Windows 2000+ has the capability of setting port an ip access on a connection properties.
Try drawing a network diagram of the connections to help in visualising the problem.
If you are connecting through routers, firewalls and loadbalancers then check that all devices are not tied to any specific ip addresses and that the IP address redirection (if in place) is correct. Also check any NAT logs to see if connections are being received and properly re-directed.
Wireshark
Latest versions of ProcMon
netstat
Wireshark www.wireshark.org
Wireshark is a network protocol analyzer for Unix and Windows.
Features:
Deep inspection of hundreds of protocols, with more being added all the time
Live capture and offline analysis
Standard three-pane packet browser
Multi-platform: Runs on Windows, Linux, OS X, Solaris, FreeBSD, NetBSD, and many others
Captured network data can be browsed via a GUI, or via the TTY-mode TShark utility
The most powerful display filters in the industry
Rich VoIP analysis
Read/write many different capture file formats: tcpdump (libpcap), Catapult DCT2000, Cisco Secure IDS iplog, Microsoft Network Monitor, Network General Sniffer® (compressed and uncompressed), Sniffer® Pro, and NetXray®, Network Instruments Observer, Novell LANalyzer, RADCOM WAN/LAN Analyzer, Shomiti/Finisar Surveyor, Tektronix K12xx, Visual Networks Visual UpTime, WildPackets EtherPeek/TokenPeek/AiroPeek, and many others
Capture files compressed with gzip can be decompressed on the fly
Live data can be read from Ethernet, IEEE 802.11, PPP/HDLC, ATM, Bluetooth, USB, Token Ring, Frame Relay, FDDI, and others (depending on your platfrom)
Decryption support for many protocols, including IPsec, ISAKMP, Kerberos, SNMPv3, SSL/TLS, WEP, and WPA/WPA2
Coloring rules can be applied to the packet list for quick, intuitive analysis
Output can be exported to XML, PostScript®, CSV, or plain text.
work the OSI model from the bottom up
Physical (Do you have a network adapter/connection)
Link layer (arp, ethernet port blocked by network team (I've seen this where locked down environments see two MAC addresses coming from one workstation port and shut down the port)
Network layer (ipconfig, tracert, ping,)
Do you have a network address (DHCP, fixed)
Are you on a proper subnet/have routing between subnets
Is something in the middle blocking you
firewalls, routing tables
When in doubt, check to see if the windows firewall is messing with your communications. 8 times out of 10, it's at fault.
Using tracert is a good start to see how far along the chain you are getting.
For virtual machines it's usally a good idea to make sure you have the loopback adapter set correctly in the Host os.
Most frequently used tool is the ping. It can be used both to test your connection and the availability of a target
Second tool is the tracert if you want to see where the packets get lost.
For more advanced debugging I use the following tools: nmap, wireshark, etc.
Windows has a netstat utility which is pretty similar to the Unix netstat and can do a number of different things that might help you solve network issues.
Random example:
netstat -r displays routing information
netstat /? for usage information
Since you said you're using 2 virtual machines I would hazard a guess that both machines are setup in a NAT configuration (rather than a unique network device) -- In the NAT configuration, neither machine would (typically) be able to ping the other.
If you're familiar with the command line, you can try the "netstat" command.
You can also try "arp -a" to list all the IP/MAC addresses known to your PC.
The "tracert [ip address]" command will show you how many gateways/routers your packets jump through on their way to their destination. (This is probably not helpful if both machines are on the same network, though.)
And don't forget to check your Windows firewall settings.
Otherwise, if you want to get down and dirty, you can try the packet sniffer known as Wireshark: http://www.wireshark.org/ (aka. Ethereal)
Pull the network cable out
If you can get some communications to a device (eg a ping), but can't get your program to talk to a service on the computer. Then, try pulling the network cable out and see if the ping stops. This will verify you're communicating with the computer you really think you are.
On windows i user PortQueryUI : http://www.microsoft.com/en-us/download/details.aspx?id=24009
DNS activity: Portable DNS Cache and Firewall;
General network activity: Wireshark, Network Monitor;
Windows utilities: ping, netstat, nslookup.
You need to be use the process of elimination, for example if you can ping the ip address but not the hostname then there's DNS issues. If you can ping the system but not connect to a share etc.
DNS out of sync
If you're using a virtual machine and you perform a roll-back on it, then it could become out of sync with the DNS (Domain name server). Try to remove and re-add the machine to the domain, or if you've got access to the DNS machine, then get it to flush its cache.