I've got a strange problem. I have a client sending packets to my server, but my servers UDP socket never receives them. Same thing happens the other way around, if I send and he tries to receive.
Check this image, captured from wireshark:
http://img263.imageshack.us/img263/2636/bokus.png
I hav bound my UDP socket to EndPoint 192.168.2.3, which is the internal IP of the server, and port 9998.
The client sends data to my IP, which should then be forwarded to the local server machine..
As you can see wireshark clearly detects incomming packets for 192.168.2.3 with destination port 9998 but nothing gets delivered!
(...why does it say distinct32 btw in destination port?)
Something else to watch for is make sure any firewall you might running has a rule setup to allow communications on your port 9998.
If I had to guess (would need to see your recieving C# code to know), It looks like you might be trying to receive UDP packets but using TCP protocol on the client side. (Or i might just be misunderstanding some of the text of your screenshot.)
Theres no need to 'listen' for a connection when using UDP. UDP packets don't have a connect/disconnect protocol. Nor do they guarantee that packets are received in the same order they're sent.
try using something along these lines in your C# client and see if you get data.
var udpClient = new System.Net.Sockets.UdpClient(9998);
Byte[] receiveBytes = udpClient.Receive(ref RemoteIpEndPoint);
Related
I'm using UdpClient to send a message and listen for a response, like this:
Client = gcnew UdpClient();
HostEndPoint = gcnew IPEndPoint(192.168.0.20, 52381);
Client->Connect(HostEndPoint);
Client->Send(Message, Message->Length);
Bytes = Client->Receive(HostEndPoint);
I have two similar devices but they respond differently. In the first case, the destination responds on the same port as I send to. So, for example, sending with a random source port of 49542, this happens:
Request: 192.168.1.10:49542 > 192.168.1.20:52381
Response: 192.168.1.20:52381 > 192.168.1.10:49542
And with the above code I get the response as expected.
The other similar device however responds with a random port (which changes whenever it is powercycled), like this:
Request: 192.168.1.10:49542 > 192.168.1.20:52381
Response: 192.168.1.20:46468 > 192.168.1.10:49542
And in this case, I do not receive the response, Receive() will timeout. I believe I understand why there's nothing received. There's suggestion in .net docs that once you use a IPEndPoint with UdpClient() or Connect(), any other responses are filtered out. So, I'm not even sure why Receive has an IPEndPoint parameter.
I have monitored the communication with WireShark and I can see the messages in both directions. So I know the device is responding I just can't figure out how to receive it in my code.
The best solution I think is to be able to receive any response that arrives to my source random port (49542 above), additionally to specify the destination IP as well, but that may not be needed. Alternatively, to listen for any response from the destination IP, on any port, since I don't see how to know what port the device is responding with.
As best as I can figure out you have to indicate a port # for Receive(IPEndPoint), which usually is the destination port of the message you sent to in the first place - as it is in my code sample (which works with the first device). The random port chosen by Connect can't be listened to, that's the receiving port, but I think Receive listens for the sending port from the device. which is unknown.
I tend to think that the fact that I can't find any information about how this can be done suggests that it can't be done because devices aren't supposed to respond from a random port. But, I've discussed this issue with the manufacturer and they insist it's correct behavior.
Also note, I've tried to create a second UdpClient to listen for the response from the destination IP, but it also requires a port be defined, and there's no way I can tell to know what port to listen for. I have tried UdpClient()->Client->RemoteEndPoint, but I'm pretty sure, this is the endpoint I'm starting with which has the known port, not the random port.
This is the first time I've encountered this and it seems weird to me. The devices are from a major manufacturer though, that surely knows what they're doing.
I believe I have solved this. The trick is to not use Connect, but instead to pass HostEndPoint in the Send command. This approach works with both devices.
Client = gcnew UdpClient();
HostEndPoint = gcnew IPEndPoint(192.168.0.20, 52381);
// Client->Connect(HostEndPoint);
Client->Send(Message, Message->Length, HostEndPoint);
Bytes = Client->Receieve(HostEndPoint);
Although it's working, I'm not completely sure what messages it will allow thru. It might allow any port from the specified IP, or it might allow any response from the specified IP that is directed to the initial random source port. I'm not sure.
Also, I initially thought I might have to set HostEndPoint->Port = 0 between Send and Receive. That works, but it isn't necessary.
I am trying to create tcp connection.
I am sending tcp SYN and getting SYN-ACK.
Afterwards, I am sending ACK message.
However, before my last ACK is sending I am getting RST reset packet. I can see that using wireshark sniffer.
I am writing my code in C# , an using pcap .NET library, over Win7.
How can I fix the problem and what makes it happen?
Your problem is, that your OS receives a SYN/ACK that it cannot associate on a source port and thus the OS TCP/IP stack sends a RST.
What do you exactly want to do? You could suppress the RST with a local firewall.
I want to check the connection to a remote machine using UDPClient. Heard that it will return an icmp packet if failure occurs. How we can catch it?
How it is possible to check for a remote machine?
UdpClient receivingUdpClient = new UdpClient();
receivingUdpClient.Connect(IPAddress.Parse("10.2.2.13"), 80);
Byte[] sendBytes = Encoding.ASCII.GetBytes("0");
Var b=receivingUdpClient.Send(sendBytes, sendBytes.Length);
With UDP, there is no definite way of knowing whether the packet reached its destination or not (compare with TCP, which sends ack packets to let the sender know its packet was received).
It is true that in some cases, ICMP packets are sent, but what if the packet was filtered out (or simply dropped) somewhere along the routing path? As far as I have seen, most home routers are pre-configured to drop all ICMP on external ports, for example.
Instead of relying on ICMP packets, you could investigate if the protocol you are using has a PING packet (or some equivalent no-op packet, or if you created the protocol -- add it!) and use that with a timeout/retry logic to verify if the service is available.
I've a plugin which always listening to the port 6002, and i have an ASP.net application which sending messages to the same port and receiving the reply from the plugin on the same port,
Sending is working fine, and the plugin sends a reply on the same port but i don't know how to catch this reply, when i try to listen to the same port using Tcplistener the start method throws this exception : Only one usage of each socket address (protocol/network address/port) is normally permitted,
is there any way to catch the received message
Thanks
It sounds like you are wrongly assuming that the Socket which you get from TcpListener.AcceptSocket can only be used in one direction.
Sockets can actually be bidirectional. You can use Send to send something, and Receive to listen for get the replies. Open one socket, and then use it for both sending and receiving.
In short, no.
Once a port is opened an exception will be thrown if further attempts are made to utilise that same port from a different source - as you are experiencing right now. There isn't a way to get around this.
I've solved this problem using this way ,, I know it's old method but it's working !! :
'/*Variables Initialization*/
dim objSocket, strServicePort, strIpAddr, strResult, strMsgTo, strMsgResponse
strServicePort = "6002"
strIpAddr = "127.0.0.1"
'/* Create a TCP/IP socket. */
objSocket = Server.CreateObject("Intrafoundation.TCPClient.3")
objSocket.ClearLog()
'/* Establish socket connection. */
objSocket.Open (strIpAddr,strServicePort)
objSocket.Timeout=60.0
strMsgTo ="---- Message here ----"
'/* Send request message to plugin */
objSocket.SendRN(strMsgTo)
'/* receive XML Request Message from plugin */
strMsgResponse = objSocket.Recv()
strMsgResponse = Replace(strMsgResponse, vbLf, "")
objSocket.Close()
If you want to inspect traffic you can use winpcap.
edit: I don't think you are asking the right question. In this case the plugin is the server (listening on port 6002) and your ASP.net app is the client listening on some arbitrary port. You only need to bind to a different port in your ASP.net app if it also needs to run as a server with the plugin acting s the client. In this case you should pick a different port even though there are, in fact, ways to make it work when they are both bound to the same port.
In your case though you should just read back responses from the connection you established from the client.
I'm writing a simple proxy (more a packet logger) for an online game in C#. All the packets get received by the proxy but some aren't sent to the client (not sure about the server).
For example:
Client->Server: Login Packet - My proxy receives the packet, displays it and sends it to the server.
Server->Client: Connected! Packet - My proxy again receives the packet, it also displays it and sends it to the client.
Server->Client: Chat channels packet - My proxy again receives the packet, it also displays it but the client doesn't receive it. There is no exception.
My code: http://lesderid.pastebin.com/Km7vT2jF
(This is the same project as here: Why can't I send to the listening socket anymore?)
This is just from a brief reading of the code:
Do not bind to 127.0.0.1. Bind to IPAddress.Any instead.
OnDataReceivedFromServer needs to call EndReceive.
I don't recommend mixing synchronous (Send) and asynchronous (BeginReceive) operations on the same socket.