I have confused about UDP port reservation by using C++ function.
I'm new for network programming.
I have been tring to reserve UDP ports for my own experiment.
My target is to reserve around 500 ports for my application.
I followed this guidance here.
It is Microsoft document for blocking UDP port (from Dodcument said).
It is CreatePersistentUdpPortReservation function on C++.
As for my understanding, CreatePersistentUdpPortReservation function contacts with SIO_ACQUIRE_PORT_RESERVATION function to negotially reserve a port at runtime.
Hence, If I call CreatePersistentUdpPortReservation
function to reserve approx. 5000 ports. For example, 60000-64999 (5000) ports. Then, any services will be theoretically not able to use one of them. They will be only use other avaialable ports (For example, 56000).
To check the result of the port reservation is completed, I captured DNS traffic in the machine, which I did the port reservation function, by Wireshark. I found that one port of 60000-64999 is applied for some service in the local machine from the capture result.
So, that means CreatePersistentUdpPortReservation does not work? or I did a wrong?
I tried to find a reason to explain this problem. I re-checked many times about the function calling. It always returned 0 errorcode that means the function is worked completely. But why one of range UDP ports that I reserved is still used for other service after I did the ports reservation. Because this function did not reserve UDP port at first or the reservation time is expired ?
I am not sure about reservation time for reserving one UDP port for this function.
Also, anyone has any new idea on how to check the status of the UDP port for testing this function?
Not only Wireshark, I tried network scanner to scan the reserved UDP ports, after calling the ports reservation function. The result said the reserved port is the open state.
Related
I am using OMNET++ INET for Ad hoc networks. I would like to send the UDP packet to multiple end nodes so that they all receive the same packet and not that the end node is chosen randomly. How should I set the destAddress in file omnetpp.ini?
Send it to 255.255.255.255 which is the IP broadcast address. Or you can send to the local broadcast address which looks something like 10.0.0.255 (if you have an 8 bit subnet). The lower layers will know how to deal with these addresses and do the appropriate broadcast on the local network.
If you want to send to specific nodes (not to all nodes) then you should either use multicast addresses (but that's pretty complicated to set up), or you indeed need to modify the UDPBasicApp and change the behavior that it can send out also packets to multiple addresses. i.e. instead of the random selecion from the host list, you could implement a loop sending out to all addresses. Or you could keep the random selection behavior and use a different syntax to denote nodes that should be treated as a single group for sending. For example "host1,host2,host3 host4,host5" would mean: choose randomly from either host1,host2,host3 or host4,host5 and then send out the UDP packet to all hosts in the comma separated group.
One last tip: If you don't insist to use UDP, PingApp does support sending out pings to multiple hosts in the target address. It can in fact ping all host interfaces in the simulation with the * notation.
Not sure if this works for you, but I used the UdpBasicBurst node application and set the destAddresses field to 'Broadcast'.
Even after using UdpBasicBurst node application and setting the destAddresses field to 'Broadcast' I am not getting it.Could anyone have any another suggestions please
I have server code on one box that needs to listen in on status coming from another box with about 10 chips with linux embedded in them. The 10 chips have their own ip addresses and each will send basically health status to the server which could (possibly) do something with it.
I would like the server just to passively listen and not have to send a response. So, this looks like a job for zmq's pub/sub. Where, each of the 10 chips have their own publication and the server would subscribe to each.
However, the server would need to know the well known address that each chip bound their publication to. But, in the field, these chips can be swapped or replace with a different ip address.
Instead, it's safer to have the chips know the server code's ip adddress.
What I would like a pub/sub where the receiver is the well known address. Or, a request/response pattern where the clients (the chips) send a messages to the server (the requests), but neither the server nor the chips need to send/receive a response.
Now, currently, there are two servers on the separate box. So, if possible I'd like a solution for one server and multiple servers.
Is this possible in zmq? And what pattern would that be?
thanks.
Yes, you can do this exactly the way you'd expect to do so. Just bind on your subscriber, then connect to that subscriber with your publishers. ZMQ doesn't designate which end should be the "server", or more reliable end, and which should be the "client", or more transient end, specifically for this reason, and this is an excellent reason to switch up the normal paradigm.
Edit to address the new clarification--
It should work fine with multiple servers. In general it would work like the following (the order of operations in this case is just to ensure no messages get lost, which is possible if the PUB socket starts sending messages before the SUB is ready):
Spin up server 1. Create SUB socket and bind on address:port.
Spin up server 2. Create SUB socket and bind on address:port.
Spin up a chip. That chip will create a PUB socket and connect on [server 1] address:port and connect on [server 2] address:port.
Repeat step (3) for the other nine chips.
Dual .SUB model
Oh yes, each .PUB-lishing entity may have numerous .SUB-s listening,
so having two <serverNode>-s meets the .PUB/.SUB-primitive Formal Communication Pattern ( one speaks - many listen )
As given above, each of your <serverNode> binds
.bind( aFixServer{A|B}_ipAddress_portNumber )
so as allow each .PUB-lishing <chipNode> to
.connect( anAprioriKnownServer{A|B}_bindingNode_ipAddress_portNumber )
And both <serverNode{A|B}> than .SUB-s to receive any messages from them.
Multi-Server model
As seen above, the {A|B} grammar is freely extensible to {A|B|C|D|...} so the principal messaging model will stand for any reasonable multi-server extension
Q.E.D.
I'm writing a packet filter in netfilter. Is there a way I can get the source and destination port of a ICMP packet?
I have extracted icmp_hdr from the sk_buff structure. But I don't see any property from source and destination address?
Port numbers are the way the TRANSPORT layer recognizes which packet belongs to what process at the end systems.
They're used to let the process-to-process delivery work; but ICMP, from a functional point of view, is not a transport layer protocol.
ICMP is a messaging protocol at the Network layer(on top of the IP; but not really in the transport layer), it's got a lot of responsibilities but none of them has anything to do with process-to-process delivery, so having a port number there wouldn't make any sense.
Take an example, when you ping(ping uses ICMP echo messages) an IP address, which port are you really pinging?
The answer is: no port, you're pinging the whole station to see if it's alive.
Now, ICMP has many types of messages; if you want to filter out, for example, ping messages, you should check the field type and if it equals ICMP_ECHO, you can return NF_DROP.
I am working on an analyzer script. It is a simple bash script that apply some logic on tcpdump sniffed capture.
My task is to find out number of concurrent sessions made by individual IPs. The logic I have applied is I have counted different source ports request by each ip for same destination IP and port i.e. 3128 as it is a proxy server.
For example, consider my dest ip is 172.31.1.1 and dest port is 3128
Now I have sniffed traffic only limited for this dest port and dest ip.
Then I have filtered out source ip and source port pair for each packet.
then I have counted number of different source port for each source IP and I think that would be equal to number of concurrent sessions made by each individual IP with this proxy server.
Now by looking at the output on a running proxy server for a 10,000 packets sample, number of sessions by each IP goes like 300,250,200 and some less also. For 1 lakh, it goes like 3000,2500 also.
Is there something wrong with my interpretation of sessions as number of concurrent session allowed by firewall is 100 per IP.
As I mentioned in my comment, if you want to know number of TCP connections from single source IP at any given time, you will need to figure out connection establishment (TCP three way handshake) and termination (four-way tear-down and reset) points. Otherwise you are counting all TCP connection, established and attempted from given IP, for the whole duration of the capture (but since ephemeral client ports could be recycled during the capture period even this count might not be accurate).
I should mention that incrementing running count of connections on a SYN and decrementing it on a FIN or RST is not going to be enough, since TCP tend to re-transmit packets. You'll need to track TCP states, so good familiarity with TCP state diagram is probably in order:
(from (http://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/Tcp_state_diagram_fixed.svg/250px-Tcp_state_diagram_fixed.svg.png).
A server is listening, let's say, on port 3000. When he receives a connection request and the connection is successful, if i call a function, let's say "getRemotePort" it will say 1234. My question is, the server will send data to the remote devise (client) on port 1234, but what about the other way around? Will the client keep sending data on the same port, in this case 3000? So everything that the server will receive (connection requests and other data) will come through the same port?
Yes it will
This is not a problem.
The point behind this is, that a connection is defined by the (LocalIP, LocalPort, RemoteIP, RemotePort) tupel - this is the only combination, that has to be unique.
On the performance side, this is no problem as well: A port is a logic construct, that has no limiting effect on the throughput of a connection, some edge cases aside (Very high latency combined with very high throughput can create a case, where a single connection can not saturate a physical link, so a second connection, requiring a second port, can speed things up. Mind though, that even in this case not the port count, but the connection count is to blame - they just happen to be 1:1)