I am trying to send a UDP packet to a device that is behind a NAT. Using a 3rd party program it is possible to send packets to this device no problem, and the packets show up in wireshark fine.
Using my own UDP client to send a packet to the device doesn't work... but if the device sends ME a packet, in the onReceive() method, sending directly back to the device in this method DOES work...but interestingly if I take the EndPoint and connect to this using a new UDP client, then it doesn't work again.
It seems like only when the device connects to me can I send messages downstream (like reverse connecting in TCP) and even taking the EndPoint as a reference to the 'connection' is not enough.
Can anyone think of reasons why I can't send directly to the device, even though I know it is possible to do so because the 3rd party software can do it?
Sending directly to other IP's such as my local computer works fine too, it is just this device that I cannot contact. My local computer is on an address like 192.168.10.2 and the device is on an address like 12.0.1.5 (when connected it creates its own LAN)
Many thanks
Related
My issue is is that my UDP client is reporting that it is connected when I have nothing on the network. I'm trying to connect to a PLC module with IP 10.10.10.10 at port 7775 from a computer port of 7777. The Connect() function from the client is working, even though there is no Ethernet or wireless connection turned on.
The core of my problem revolves around my connection code I believe
Public Sub Connect()
Try
If (plcType = 0) Then
udpClient = New UdpClient(7777)
udpClient.Client.Connect(IPAddress, port)
SendCommand("ME")
End If
Catch
MsgBox("Could not connect to the controller, please check IP address." & vbCrLf & Err.Description)
'Connect()
End Try
End Sub
If I insert a break point after the Connect() command I get extremely strange behavior. After the break point is hit if I look into udpClient.Client's properties it says it is connected, but if I leave those properties and then look at it again it will suddenly change and say it is not connected and the program will correctly read that it is not connected after that point.
This issue only appeared After I connected a second computer and attempted to run the same program on it to the same device. Neither computer can correctly talk to the device anymore, that I can understand, but I can't understand why one of my computers believes that it is talking to the device when it clearly isn't.
Thank you for any help.
Update: Any connection available will trigger this condition, only if all networks are disable or disconnected will it behave as expected. However, it is still reporting as connected when there is no device on the network of that IP.
So #CodeCaster is right saying that "UDP has no notion of being connected". UDP is a connectionless fire-and-forget protocol. When you send a datagram, you have no guarantee it will reach its destination.
Different "connect" operations that are available across a multitude of languages merely mean "ok, we'll use this socket for talking to this specific address and port". This knowledge does not translate to packets being sent over the network. It is a local thing that allows you to use send function instead of sendto.
If you want to know if there's a device on your network listening to a specific IP and UDP port, then you're going to need your own synchronizing mechanism. The protocol does not support that out of the box. So examples are:
Heartbeat. Let your remote peer send a special multicast message every 5 seconds. If you haven't received a heartbeat message in 15 seconds, assume the remote peer is down. Adjust numbers at your own discretion.
Ping-pong, or echo request - echo response. Periodically send a special datagram to the remote peer and expect a response.
Handshakes, acknowledges, retries... The more robust channel you need, the more it is going to remind TCP. This is a kind of a sign to switch protocols!
I'm using Game Maker: Studio and already got the UDP broadcasting to work, but only for people using the internet in the same router. But, I want to broadcast via Hamachi too, so there's no need to enter the IP manually.
This is the function I can use: http://docs.yoyogames.com/source/dadiospice/002_reference/networking/network_send_udp.html
And this one I use for local broadcast: http://docs.yoyogames.com/source/dadiospice/002_reference/networking/network_send_broadcast.html
Your gamemaker UDP packets are as good as any other. So if you can send ping requests to an IP, you should be able to send it any UDP packet you want.
When you ping an address through hamachi, you are actually sending UDP packets to it. So if you want to know if UDP communication will work through hamachi, try to ping someone with the console (type "ping [his IP]"). If it works, then any UDP packet with he correct address should travel correctly, including the ones emitted by your gamemaker app.
Be aware, though, that you may have to cope with a greater packet loss ratio than on your local network. Contrarily to TCP, UDP packets may sometimes not reach their destination.
I am trying to send UDP Packets to a public server from a client in symmetric nat. i am able to send packets to the server However i want the server to send packets to the client under symmetric cone nat. How do i solve this? Please help me.
Make the server send packets to the client's external IP+Port which the server detects on the arrival of first packet from client.
Basically, the router allows any outgoing UDP traffic from the devices connected to it and blocks all incoming UDP traffic. But it maintains a table of source and destination IP+port whenever a UDP packet is sent out. It allows replies from devices external to the router, provided the router must have an entry of external device IP+port.
So, you just need to use this mapping in the table now.
Just make your server detect the client's external IP+port from the packet it receives from the client and then let the server send back packets to the client on that external IP+port.
This will punch a hole in the router's firewall i.e., the router firewall will now allow the incoming UDP packets as it already contains an entry in it's table. This process is called HOLE PUNCHING.
You can understand all this NAT traversal process in the various RFC's published.
What I want is, basically, to create a connection between two different computers on same local network. But i want to do this by computers' local IP's. (like 192.168.2.23 etc)
This must be a totally local connection. no TURN or STUN Servers. I am not sure if this is possible. Because there are not much documentation/example/information about WebRTC.
So, how can I create a connection from my computer to another one just passing its local IP as parameter?
Update: To be more clear; imagine there is an html page contains some code that activates my camera and audio services. and another -almost same- page is open in other computer. Waiting a connection request... And there is a textbox in my page to type an IP belongs to other computer on my local network. type 192.168.2.xx and bingo! i have connection between me and other computer.
I want this process as IP based, because there may be more than 2 devices on the network. And all of them are possible devices to create connection. So i need to reach them by their IP's.
Any example code or explanation would be great! even if it tells that this is not possible.
Thanks
Peer discovery is a vital part in any WebRTC application. It's an expensive term for saying: "Hi, I'm computer 4 and I want to talk to you!".
See it as calling a friend over the phone. You need to dial his number first.
This part is not defined in the WebRTC standards. You need to implement this logic in your application. Once you know who you want to call, you need a way of exchanging vital information. This is called signaling, like flo850 put in his answer.
Signaling is needed before any peer-to-peer connection can be set up.
To come up with an idea for your use case of 7 devices in a LAN.
If you have these devices connected to for example a WebSockets server and are in the same channel.
The WebSockets server can be written to route messages to specific receivers.
Devices connected to the channel often are identified with some kind of ID, imagine you use the device's IP.
When you want to talk to computer 4 with IP 192.168.0.4 you send the exchange messages (signaling) on the channel to the receiver with ID, the IP of the device you want to connect with.
How to send the signaling (offer, answer) is described here with example code.
Hope this helps
Users usually sit behind NATs; that's why ICE concept implemented in WebRTC.
If both users are sitting behind same NAT; you can skip ICE servers by passing "NULL" parameter value over "RTCPeerConnection" constructor:
var peer = new [webkit|moz]RTCPeerConnection ( null );
Now, browser will use "host" candidates, also known as "local" candidates.
you still need a signaling server. During the ICE candidate search, your clients will exchange their local ip through this signaling server
I'm sniffing between two devices which communicate in a duplex fashion via udp. I'm using wireshark to sniff. The config file for the first device (a piece of hardware under test) states that the client port is 54718 and the server is 54717. In the config file for the second device (a simulator written years ago), only one port is specified. That of 54718.
The two devices communicate without any problems.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
In wireshark I can see that the first device is sending to the second device such that the source port is 54717 and the destination is 54718. I can also see that the second device is sending to the first device such that the source port is 54718 and the destination is 54717.
The first device sends first and the protocol is described as that of UDP in Wireshark. The simulator replies, also via UDP. Subsequent exchanges are described as being STUN ChannelData TURN Messages. I've no knowledge of this protocol but maybe it explains why I don't see 54717 in the simulators config file.
Thanks for your help,
Barry
First, in UDP communication, there is no "connect" action. UDP is not connection-oriented.
Second, the second device will get the peer address and port from recvfrom() api call.
In all probability, the first device's use of the terminology "client port" and "server port" do not refer to two different ports within the client device. Instead, the "client port" refers to the port to be used as the point of origin within the first device, and the "server port" refers to the remote destination port on the far device, to which the first device's outgoing traffic will be sent.
The second device, on the other hand, is probably fundamentally a "listening" device. It only knows the UDP port it needs to listen on, and waits for any queries destined to that port to arrive from anywhere.
So, I will refer to the "first device" as the client, and the "second device" as the server.
Each datagram sent from the client to the server contains two sets of address information:
1) The destination IP address and port, and
2) The return IP address and port.
The server can use recvfrom() to extract the complete return address (including port number) from each incoming request.
This way, we really only need one port number to be predfined and agreed upon by both the server and the client ahead of time: The server's port number.
The client could conceivably choose to use any random port number as its origin port (but by convention it would likely choose to avoid any of the well-known reserved ports to avoid potential interoperability problems), and the server could dynamically read the return address information from each incoming request and send its responses to the correct destination dynamically.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
UDP is connectionless, and your program likely gets the 54717 as a default fallback value if nothing else is specified (e.g. in a config file).