I’m using Golang to try to send packets through UDP to an IP address and port provided by STUN. The goal is to communicate between two devices without having to open a port in the firewall, as both devices are located in a different network.
The program runs on both devices in the following manner:
Device 1 waits for device 2 to send the IP address and port found by STUN. This goes through an open port in the firewall of device 1. (Only for device 1 an open port is possible)
The problem is that device 2 does not receive any packets through the port found by STUN.
I think the problem consists of the router not knowing the connection to device 2. Device 2 is connected with the router, but the router doesn’t know what to do with the packets.
Do you have any idea how to solve this problem?
Thanks!
Related
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!
My firm produces some devices with a network interface. The devices are sent with a IP address = 0.0.0.0. The customers plugs the device on the private net in the field and, by using a tiny app written with VB6, discover it and set the correct IP address.
This working by using UDP messages: the app broadcast a "Who's there?" UDP message, read back the answer(s) containing the MAC address of the device(s), and the the user send another UDP message containing the new IP address for target MAC.
Now, for some unknown reasons, one of these device get its IP address set to 127.0.0.2. The problem is that now the VB app can't find (via UDP) the device anymore, making it impossible to change the IP address to a valid one.
Further analisys revealed than if the app is running on Windows XP it sees the device, but if the app is running on Windows 7 the UDP message does'nt arrive to to the "socket" (while Wireshark can see the answer from the device).
Now, there a solution to allow Win7 to let "pass" an UDP message sent from a 127.0.0.2 external address? If yes, we could avoid to ship around the world a replacement device with a correct IP address and all the trouble of phisically mounting it in the field.
Here's a Wireshark capture of the "question" and the "answer" not "detected" by the VB app:
cap.pcapng
Now, for some unknown reasons, one of these device get its IP address set to 127.0.0.2.
You need to fix that.
The 127/8 block is reserved for the "loopback" address (ie. localhost). No packets sent to 127.0.0.2 will leave your systems NIC. Unless there are bugs in the drives (or hardware): this could be the case with WinXP.
Is it possible that set a proxy for windows (7) and all packets go Through the proxy server ? I mean all packets even ARP packets !
Sure it is take a look at arp spoofing/poisoning basically arp protocol works by machine saying this is my IP address and the router takes note and forwards any packets with this IP to that machine (Mac Address). SO basically you have to send out the arp messages at a faster rate tricking the router that messages should be bound to your machine and not the actual mac address that IP should belong to.
just to note (arp is a LAN protocol) so if your proxy is not within the the subnet as the machine your presumably attacking their is no way you can get these packets
Is there a way to find out the IP address of a device that is directly connected to a specific ethernet interface? I.e. given one host, one wired ethernet connection and one second host connected to this wired connection, which layer or protocol below IP could be used to find this out.
I would also be comfortable with a Windows-only solution using some Windows-API function or callback.
(I know that the real way to do this would probably via DHCP, but this is about discovering a legacy device.)
Mmh ... there are many ways.
I answer another network discovery question, and I write a little getting started.
Some tcpip stacks reply to icmp broadcasts.
So you can try a PING to your network broadcast address.
For example, you have ip 192.168.1.1 and subnet 255.255.255.0
ping 192.168.1.255
stop the ping after 5 seconds
watch the devices replies : arp -a
Note : on step 3. you get the lists of the MAC-to-IP cached entries, so there are also the hosts in your subnet you exchange data to in the last minutes, even if they don't reply to icmp_get.
Note (2) : now I am on linux. I am not sure, but it can be windows doesn't reply to icm_get via broadcast.
Is it the only one device attached to your pc ?
Is it a router or another simple pc ?
To use DHCP, you'd have to run a DHCP server on the primary and a client on the secondary; the primary could then query the server to find out what address it handed out. Probably overkill.
I can't help you with Windows directly. On Unix, the "arp" command will tell you what IP addresses are known to be attached to the local ethernet segment. Windows will have this same information (since it's a core part of the IP/Ethernet interface) but I don't know how you get at it.
Of course, the networking stack will only know about the other host if it has previously seen traffic from it. You may have to first send a broadcast packet on the interface to elicit some sort of response and thus populate the local ARP table.
Windows 7 has the arp command within it.
arp -a should show you the static and dynamic type interfaces connected to your system.
Your Best Approach is to install Wireshark, reboot the device wait for the TCP/UDP stream , broadcasts will announce the IP address for both Ethernet ports
This is especially useful when the device connected does not have DHCP Client enabled, then you can go from there.
You can also get information from directly connected networking devices, such as network switches with LDWin, a portable and free Windows program published on github:
http://www.sysadmit.com/2016/11/windows-como-saber-la-ip-del-switch-al-que-estoy-conectado.html
LDWin supports the following methods of link discovery: CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol).
You can obtain the model, management IP, VLAN identifier, Port identifier, firmware version, etc.
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.