In a network simulation with omnet++5.4 inet 3.6, how can I set a UDP Application in .ini file to send packets from array A[sizeofA] to array B[sizeofB]?
A and B are two sets of nodes with different sizes and there should be send to the nearest node.
and if there is another set of nodes that called C[sizeofC], how can I set UDP traffic form B to C? I mean B acts as a router here.
appreciate for your help, in advance.
Related
How do you change the sample message that gets broadcast to vehicles in the veins_inet sample application?
I can see that TraCI comes equipped with many functions that generate information about a node, such as speed, acceleration, location etc. I would like to include such information in the messages the nodes broadcast and that can be read in Pcap recordings made by each node. Currently the default message is just the RoadID of the node.
In simuLTE, the LteHandoverManager is trying to send a self-constructed packet "X2HandoverControlMsg" to the SCTP layer for further processing. After receiving the packet, however, the SCTP layer discards it and sends a self-defined "DATA" packet to the IP layer.
The problem is: I want to send customized packets constructed in the LteHandoverManager and pass through the layers including SCTP, IP and PPP all the way down to the destination node. Does anybody know if it is possbiel to do that and how?
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'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).