CODEWITHSUNDEEP
c#socketsubuntuudpfirewall
andreas
andreas

Reputation: 8004

Receiving large UDP packet fails behind Linux firewall using C#

I was successfully using this code on my home computer - please note that I have minified the code in order to only show the important parts

Socket Sock = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);

// Connect to the server
Sock.Connect(Ip, Port);

// Setup buffers
byte[] bufferSend = ...; // some data prepared before
byte[] bufferRec = new byte[8024];

// Send the command
Sock.Send(bufferSend, SocketFlags.None);

// UNTIL HERE EVERYTHING WORKS FINE

// Receive the answer
int ct = 0;
StringBuilder response = new StringBuilder();
while ((ct = Sock.Receive(bufferRec)) > 0)
{
     response.Append(Encoding.Default.GetString(bufferRec, 0, ct));
}

// Print the result
Console.WriteLine("This is the result:\n" + response.ToString());

In another environment (Windows but behind an Ubuntu firewall) I have problems receiving packets with over 1472 bytes: An exception is thrown that the request timed out.

So basically I have two options:

How would I need to adapt my code in order to split packets in working size? I thought adjusting the variable bufferRec = new byte[1024] would suffice, but obviously this does not work. I get an exception then that the received package is greater than the bufferRec. Do I have to change the SocketType?

Unfortunately I do not know a lot about sockets, so your explainations would help a lot!

Upvotes: 1

Views: 533

Answers (1)

JohnKiller
JohnKiller

Reputation: 2008

Your packet is traveling various networks. Each network probably has its own MTU size. This is the maximum size a single packet can be.

If your data exceeds that size, the DF flag is checked (DF stands for Don't Fragment). If that flag is set, the packet is dropped and an ICMP response is generated.

In C# sockets, this option is controlled by the DontFragment property, wich defaults to True, hence your problem.

Note that UDP with fragmentation enabled is to be considered unreilable, since packets will probably get lost on a busy network

Upvotes: 1

Related Questions