Develop Reference

What's wrong with sending "chr(6)" over a socket?

I'm trying to send ASCII character 6 (acknowledge) over a socket. The socket is connected and sends and receives other information without problem.
The way that I send the acknowledgement is as follows:
_socket.Send(data, data.Length, 0);
In there, data is of the type byte[], the value of [0] equals 6 (as it should).
According to socket workbench (a tool, proposed by the customer), nothing is being sent.
According to Wireshard, something is being sent but immediately there's a response, saying that something is wrong:
Wireshark screenshot of the acknowledgement I send:
Wireshark screenshot of the response I receive:
The IP address, ending with 236, is my local PC.
The IP address, ending with 160, is the host where I send the acknowledgement.
According to the colours, used by Wireshard, I suppose something's terribly wrong, but I don't have enough network background knowledge to solve this issue.
Does anybody know what I should do in order to send the acknowledgement successfully?
By the way, this is not a question for Superuser (about usage of an existing computer program), this is about how to develop a program: the Wireshark screenshots are purely explanatory.
Thanks in advance

How do I specify Server Ip address in my Client program?

I'm currently working with TCP/IP Sockets, My client console program has to connect with server which is my PC, If the destination in the client program is specified as a local host it works fine, what I need to get done with is to connecting the client with my server through internet, what I did is looked up for my IP address on http://www.whatismyip.com/ and tried but it didn't work as I think it's a Network Interface IP address, then I altered destination IP address in client program specifically to the address of my computer which I want it to be a server, but that didn't work also. Here's my code.
Ip = (IPAddress.Parse("192.168.1.4"));
MyClient.Connect(Ip,6000);
GetStream = MyClient.GetStream();
Console.WriteLine("CONNECTED TO SERVER");
Read = new BinaryReader(GetStream);
Write = new BinaryWriter(GetStream);

There 2 things (at least) that you should be aware of:
1. To access your computer from Internet (from the public address, the one you get with whatismyip.com) you need to open the port (6000) at the router, and tell the router to what IP it should forward the incoming connection. You could specified specifics ports or put a DMZ host where all the incoming connections will be routed to that host/PC. Read your router manual to see how that is done.
2. You cannot access your public IP from the inner side of the router (intranet), if you want to connect to your public IP you need to be in another network.
If you have a dynamic IP (is the default) every time the router is powered off and on then, most probably, that IP would change, you need to investigate thru whatismyip.com in order to know what IP has been assigned. You could connect to dyndns.org and ask for a host name myhost.mydomain.com (.es, .fr, etc), and in the router tell the DDNS (Dynamic DNS) to update that host every time the IP changes. In your client program you then connect to MyClient.Connect("myhost.mydomain.com", 6000);
Hope I explain myself well enough, anyway, if you have any question let me know.

Receiving UDP Broadcast message in C#

I know this question has been asked many times. I've read ALL the answers and tried EVRY piece of code I could find. After a few days I'm so desperate that I have to ask you for help.
I have a device and a PC in my home network. The device sends UDP broadcast messages. On my PC I can see those messages in wireshark:
Source Destination Length
192.168.1.102 0.0.0.0 UDP 60 Source port: 9050 Destination port: 0
That means the packets are arriving on my PC. My next step was to create a C# application that receives those packets. As mentioned above I tried every possible solution, but it just won't receive anything.
So I guess there must be something very basic I'm doing wrong.
Can anyone help me out? Thanks!

Just experienced the same issue, and wanted to share what fixed it for me.
Briefly: it seems that Windows Firewall was somehow the cause of this weird behavior, and just disabling the service does not help. You have to explicitly allow incoming UDP packets for specific program (executable) in Windows Firewall inbound rules list.
For full case description, read on.
My network setup is: IP of my (receiving) machine was 192.168.1.2, IP of sending machine was 192.168.1.50, and subnet mask on both machines was 255.255.255.0.
My machine is running Windows 7 x64.
This is the code (roughly) that I used:
Socket sock = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
IPEndPoint iep = new IPEndPoint(IPAddress.Any, 0);
sock.Bind(iep);
sock.EnableBroadcast = true;
EndPoint ep = (EndPoint)iep;
byte[] buffer = new byte[1000];
sock.ReceiveFrom(buffer, ref ep);
Initially this did not work unless I sent a broadcast packet from that socket before I call ReceiveFrom on it. I.e. adding this line before ReceiveFrom call:
sock.SendTo(someData, new IPEndPoint(IPAddress.Broadcast, somePort))
When I didn't send the broadcast packet first from receiving socket, incoming broadcast packets were not received by it, even though they appeared in Wireshark (destination of packets was 255.255.255.255).
I thought that it looks like firewall is messing with incoming packets (unless some kind of UDP hole is opened first by outgoing packet - even though I haven't heard before that UDP hole punching applies to broadcast packets somehow), so I went to services and disabled Windows firewall service altogether. This changed nothing.
However, after trying everything else, I re-enabled the firewall service, and tried to run the program again. This time, firewall prompt appeared asking me whether I want to allow MyProgram.vshost.exe process (I was debugging in Visual Studio) through firewall, I accepted it, and voila - everything worked! Incoming packets were being received now!

You are OK, they have something wired in the code which causes the problem. (I haven't read the article, just copy pasted)
It always works from the local machine, but from a remote machine it will fail for some reason.
To fix this:
In the Broadcst.cs they broadcast twice. once for the localhost and then for the target IP adress (iep2). simply remove the
sock.SendTo(data, iep1);
and it should work.
No idea why.

Send UDP packet, not using ARP, known IP and MAC

I am trying to send UDP over a network to a microcontroller. The microcontroller has had almost all of the IP stack stripped out to keep it lean, so cannot engage in ARP.
The microcontroller is outputting broadcast packets, which I can receive so I know its IP address and MAC address.
I can send broadcast UDP packets to it, which it receives fine, but when I try to send packets using its IP address, I can see ARP messages in wireshark, "Who has 192.168.1.205? Tell 192.168.1.18", 205 being the micro, 18 is my PC. The micro does not respond with its MAC address, so I cant send the packet, but I know the MAC address from the packets the micro is sending out anyway.
So my question is can I specify the IP and MAC address using the UdpClient so it does not need to use ARP.. is there anything else I'm not considering?
The broadcast method that works looks like this:
myUdpClient.EnableBroadcast = true;
myUdpClient.Connect(IPAddress.Broadcast, port);
myUdpClient.Send(dataBytes, dataBytes.Length);
The fixed IP method that doesnt currently work looks like this
IPEndPoint ep = new IPEndPoint("192.168.1.205", port);
myUdpClient.Send(dataBytes, dataBytes.Length, ep);
I have looked at using things like
myUdpClient.Client.SendTo(dataBytes, SocketFlags.DontRoute, ep);
but this doesnt work, and is still not making use of the microcontrollers MAC address.. which my application knows and needs to use (I think). I was also hoping some ARP table on the network would have known where the MAC address was seeing as packets with this info are being sent from it..
As a note, I want to keep broadcast to a minimum to reduce the load on other microcontrollers on the network.
Thanks in advance,
Gareth

As far as I can see, you have two options, I'm sure someone else has more;
Set a static ARP entry in the OS before launching your application. arp -s <ip> <mac> or similar will set it on most OS's and bypass ARP for further requests to the IP.
Use Jpcap to bypass the IP stack entirely, building and sending your own raw packets.

UDP and port randomisation

I'm currently programming a UDP application which allows clients to login. After that, their endpoint gets stored in a list.
private void socket_Callback(IAsyncResult result_)
{
EndPoint remote = new IPEndPoint(IPAddress.Any, 0);
socket.EndReceiveFrom(result_, ref remote);
if (!listOfEndPoints.Contains(remote))
{
// registration process
// add it to list
listOfEndPoints.Add(remote)
}
else
{
// process packet
}
}
However, sometimes a client's NAT will assign every packet a different external end point. If the registration packet's source end point is 12.34.56.78:1000, that end point gets added to the list. If the same client then however sends another packet, the NAT will assign it a different port, so its source end point will be 12.34.56.78:1001.
This results in the server assuming the client is not registered and try to process the packet as a registration one. Needless to say this won't work.
A way of fixing this would be to send an ID (which could however be faked easily, if it's not super-cryptic) to the client. However, the client would have to add it to each packet it sends to the server.
So it wouldn't be very effective to do it like that.
Is there any other way of telling that the packet has come from the same client as the registration packet?

You should definitely not use the source IP address and port of a UDP packet to associate it with a logical connection. You should include the ID of the connection in each packet and update the IP and port you respond to if you receive a new IP and port for the same logical connection. If connection hi-jacking is an issue, you may need to implement some form of security, such as a secure checksum in the datagram.
TCP handles associating packets with connections for you. With UDP, you must associate datagrams with logical sessions yourself. I don't know why you think it "wouldn't be very effective to do it like that".
One of the tradeoffs of UDP is that if you need anything TCP provides, you have to code it yourself.
By the way, I've never seen ports shift in this way. Are you sure the client code isn't broken, perhaps opening a new socket for each datagram it sends.