I have a Realtek Gigabit ethernet adapter connected to my PC's PCI port and my OS is Windows 7 x64. I have a device in my LAN which brodcasts data via UDP every 100 ms (source port: 0, dest. port: 5100) and I can see all incoming data via Wireshark. The problem is I can't receive data via the application I developed and total received bytes is always zero in Windows:
I can't even receive data via NetCat. What's the problem? How it is possible that Wireshark is able to receive UDP packets although Windows says total number of received bytes is zero? I can't ping or respond to ping from other computers that are present in my LAN.
var socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
string ip = "192.168.0.1";
int port = 5100;
socket.Bind(new IPEndPoint(IPAddress.Parse(ip), port));
var buffer = new byte[1024];
int numBytesReceived = socket.Receive(buffer);
Related
I am using a Packet Capturing and Analysis Tool named as Cisco Joy for generating network flows.
Here is the link: https://github.com/cisco/joy
So Joy is a Packet capturing and analysis tool which uses a configuration file to capture Packets on a network interface and return json files as output in a directory.
I have configured Cisco Joy with AF_Packet to generate the network flows.
So I have been trying to process the network packets using tcpreplay on a virtual network interface at a speed of 3 GBPS but Joy is not receiving the packets at the same speed.
Actual: 450889 packets (397930525 bytes) sent in 1.06 seconds
Rated: 374307598.1 Bps, 2994.46 Mbps, 424122.22 pps
Flows: 12701 flows, 11947.01 fps, 450298 flow packets, 591 non-flow
Statistics for network device: vth0
Successful packets: 450889
Failed packets: 0
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
Packets Received from Cisco Joy: 260850
So Here tcpreplay sent over 400k packets but Cisco Joy received only around 260k.
I have changed the buffer size of the length in which the packets have been captured but still I didn't find any resolution from that so anyone have any clue about this?
What I have discovered is that there are a number of ports on my Windows 10 box which (1) are not in use by any process and (2) I cannot listen on.
I discovered this problem trying to run a node server which used port 3000. I found a number of questions on this topic. This one is typical: Node.js Port 3000 already in use but it actually isn't?
All the respondents of this question and similar questions all suggest using "netstat -ano" to find the process which is using the port and killing it.
What I have found is that there are large number of ports blocked which are not tied to processes. This is not related to AV or firewall. I turned off the firewall and I have only Windows Defender AV.
I wrote a program to listen on the ports between 3000 and 5000 inclusive on 127.0.0.1.
int port = 3000;
while(port <= 5001)
{
try
{
ListenOnPort(port);
++port;
}
catch (Exception ex)
{
Console.WriteLine($"Listen on {port} failed: {ex.Message}");
++port;
}
}
Where ListenOnPort is...
private static void ListenOnPort(int v)
{
var uri = new UriBuilder("http", "127.0.0.1", v);
HttpListener listener = new HttpListener();
listener.Prefixes.Add(uri.Uri.ToString());
Console.WriteLine($"Listening on {v}");
listener.TimeoutManager.IdleConnection = new TimeSpan(0, 0, 1);
listener.Start();
var task = listener.GetContextAsync();
if(task.Wait(new TimeSpan(0,0,1)))
{
HttpListenerResponse response = task.Result.Response;
// Construct a response.
string responseString = "<HTML><BODY> Hello world!</BODY></HTML>";
byte[] buffer = System.Text.Encoding.UTF8.GetBytes(responseString);
// Get a response stream and write the response to it.
response.ContentLength64 = buffer.Length;
System.IO.Stream output = response.OutputStream;
output.Write(buffer, 0, buffer.Length);
// You must close the output stream.
output.Close();
}
listener.Stop();
}
The program produced output similar to this...
Listening on 3000
Listen on 3000 failed: The process cannot access the file because it is being used by another process
Listening on 3001
Listen on 3001 failed: The process cannot access the file because it is being used by another process
Listening on 3002
Listen on 3002 failed: The process cannot access the file because it is being used by another process
Listening on 3003
Listen on 3003 failed: The process cannot access the file because it is being used by another process
Listening on 3004
Listen on 3004 failed: The process cannot access the file because it is being used by another process
Listening on 3005
Listen on 3005 failed: The process cannot access the file because it is being used by another process
Listening on 3006
Listening on 3007
Listening on 3008
Listening on 3009
Listening on 3010
What I discovered is that between the ranges of 3000 and 5000, there are 624 ports which are blocked. Meanwhile "netstat -ano" shows that there are exactly 5 ports in use in that range. So what is blocking the 619 other ports?
Right...
While looking for something else I found the answer (at least the source of the problem). The reason I cannot connect to these ports is because they are all part of excluded port ranges on windows. To see the excluded ports use...
$ netsh int ipv4 show excludedportrange tcp
And there, magically, is a list of all the ports I cannot connect to. These excluded port ranges apparently originate from HyperV and Docker, both of which I have installed. There is apparently a way to get the ports back...not easy since it involves uninstalling Docker and HyperV, then reserving the port ranges for yourself and then reinstalling HyperV and Docker. Not worth it. Now that I simply know how to find the ports I cannot use, I will simply not use them!
Set the Windows "Dynamic Port Range" in a non conflicting place
We managed to contain this problem for the case where you can not change your port numbers (like a non configurable application).
When you issue the command:
netsh int ip show excludedportrange protocol=tcp
You get an output with a list of port ranges reserved:
Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
33474 33573
50000 50059 *
58159 58258
58259 58358
58359 58458
58459 58558
58559 58658
58659 58758
58759 58858
* - Administered port exclusions.
The most likely reason for this is Windows Hyper-V (Microsoft's hardware virtualization product) that reserves random port ranges (usually blocks of 100 ports).
This becomes a pain, because if you are developing an application or larger solution that uses multiple ports, some times you get a conflict and some times not after rebooting your system.
To find the "Dynamic Port Range" you can issue the command:
netsh int ipv4 show dynamicport tcp
The answer:
Protocol tcp Dynamic Port Range
---------------------------------
Start Port : 1024
Number of Ports : 64511
You can instruct Windows to modify this range out of the conflicting area. Let's say your development is under and up to port 60000, you can issue the following command to restrict the dynamic port range out of it (you must have administrator privilegs):
netsh int ipv4 set dynamic tcp start=60001 num=5534
To make Hyper-V (and Windows in general) use this new dynamic range you have to reboot your system.
Now if we request the excluded port range:
netsh int ip show excludedportrange protocol=tcp
The response has changed:
Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
50000 50059 *
63904 64003
64004 64103
64105 64204
64205 64304
64305 64404
64405 64504
64505 64604
64605 64704
* - Administered port exclusions.
Only the "Administered port exclusions" remains below port 60001
I need to find out what is the average size of request in gRPC when Im sending a string to server and receiving a string from server?
I read somewhere it should be around 20 Bytes but what I see in Network Monitor app is that the request is above 500 Bytes. So is it the smallest possible size of a gRPC message size or what?
For a single rpc, gRPC needs to do a few things:
Establish HTTP/2
(Optional) Establish TLS
Exchange headers for the RPCs (size depends on schema)
Exchange actual RPC messages (size depends on schema)
Close connection
gRPC is meant to be used for many RPCs on a single connection so the smallest possible rpc message is really the bytes used for 4.
[Edit]
I checked and the minimum data exchanged for an rpc is over 500 bytes, in terms of raw IP packets.
I used the gRPC helloworld.proto, changed to send an int32.
Inspecting packets in Wireshark showed the following IP packet totals:
1286 bytes to establish connection, exchange headers and do the first rpc
564 bytes for each subsequent rpc
176 bytes for client Shutdown
Of those 546 "minimum" bytes:
67% was TCP/IP overhead (acknowledgements, packet headers)
10% was "trailer" data sent after the rpc
I am currently trying to get Advertisement Packets from Bluetooth LE in Windows 10.
I am developing an Universal Windows Application, thus I am using JavaScript with the following code:
// Create and initialize a new watcher instance.
var watcher = new Windows.Devices.Bluetooth.Advertisement.BluetoothLEAdvertisementWatcher();
watcher.signalStrengthFilter.inRangeThresholdInDBm = -126;
watcher.signalStrengthFilter.outOfRangeThresholdInDBm = -126;
watcher.signalStrengthFilter.outOfRangeTimeout = 60000;
watcher.signalStrengthFilter.samplingInterval = 0;
watcher.scanningMode = 1;
watcher.addEventListener("received", onAdvertisementReceived, false);
These are my settings to get the most BLE ADV Packets.
In my scenario I have a BLE transponder sending an ADV packet every second, which I can verify on a linux-machine with WireShark.
Strangely I don't get all of these ADV packets with the Windows application.
I will get like 15-20 packets and then there is a 30-60s pause before getting other packets.
All devices (windows-machine, linux-machine and ble-transponder) are within a 1m radius. So I think I should get the same packets on the windows-machine like on the linux-machine, but I don't. Why is that? Are my settings wrong or is there a better way of getting ADV packets?
Thank you in advance.
See my answer at BLE Scan Interval Windows 10.
Basically, Windows instructs the BLE controller to scan for 18.125 ms and then to sleep for 100 ms. That's why you don't get all packets.
I would like to use five TCP and five UDP streams (sending and receiving) in parallel on a single host, where the UDP traffic consists of video, and the TCP traffic is arbitrary. How do I use both transport layers in parallel on the same node?
In INET 3.0.0 there is an example nclients in examples\inet directory. It could be a good start point to prepare your model.
As long as the TCP and UDP traffic is independent, you can easily install several UDP and TCP applications at the same time in the same host. Something like this:
**.cli[*].numTcpApps = 2
**.cli[*].tcpApp[0].typename = "TelnetApp"
**.cli[*].tcpApp[1].typename = "TCPBasicClientApp"
**.cli[*].numUdpApps = 2
**.cli[*].udpApp[0].typename = "UDPVideoStreamSvr"
**.cli[*].udpApp[1].typename = "UDPVideoStreamSvr"
// ... further cofiguration of the applications