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!
Related
I am constructing an ip-ip tunnel between remote linux server and the local windows server.
The windows server does not support raw ip-ip tunnel so I develop a simple app which makes usage of wintun.
Said the local windows server is bound to ip_local, the remote linux server is bound to ip_remote, and the tunnel ip is ip_tun.
Currently, the windows server can receive the incoming packet (outer ip_remote->ip_local, inner ip_client->ip_tun) from the remote linux server in the tunnel.
For the outgoing packet (ip_tun->ip_client), if I route the packet to the tun NIC, the packet can be sent out.
However, if I route the packet to the real NIC, the packet is ignored.
Thus there seems a mechanism that blocks the sending of packets when the source ip is not bound to the corresponding NIC.
(In the above case, because ip_tun is not bound to the real NIC, the outgoing packet is ignore.)
Is there any configuration that can disable such mechanism?
Thanks for any help.
Enable ip routing in registry then everything ok.
I'm writing a NDIS filter driver for windows. Now I face a problem.
I'm going to redirect TCP packets to a TCP server on the current PC which the NDIS filter driver installs on. For example, the IP address of the current PC is 192.168.1.1 and there is a TCP server on it which is listening port 8000.
A user enters a URL: http://192.168.1.10/xxxx in the IE browser and my NDIS filter driver can absolutely see the TCP SYN packet. I modify the destination IP address of the packet to 192.168.1.1 and the destination port to 8000, because I'm expecting the packet can be redirected to the local TCP server.
Then I use NdisFIndicateReceiveNetBufferLists() to to inject the NBL into the receiving path instead of sending it to the underlying miniport driver.
However, it seems that the local TCP server can never get the redirected SYN packet. I don't know where the thing is going wrong. Would anyone help me or give me some advice?
Thank you very much!
In general, you can't take an NBL from one path (the transmit path) and just drop it into another path (the receive path). You'd need to clone the NBL and indicate the clone. Also, you'll have to edit the IP and TCP headers to fix the checksums.
But before you go down that route -- be advised that a WFP callout is a more appropriate type of driver for this project. WFP callouts are designed to operate at Layer 3 and Layer 4 of the network stack, while NDIS operates at Layer 2.
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 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 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.