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.
Related
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.
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 am checking out the behaviors of Websocket.
Is Websocket message oriented unlike TCP stream?
For example, when I send data ABC, DEF, GHI, then is it guaranteed to receive data ABC, DEF, GHI? In TCP stream, it is not guranteed: we may receive AB, DEFG, HI.
Yes, it is message-oriented (well, actually frame-oriented).
Per RFC 6455:
After a successful handshake, clients and servers transfer data back
and forth in conceptual units referred to in this specification as
"messages". On the wire, a message is composed of one or more
frames. The WebSocket message does not necessarily correspond to a
particular network layer framing, as a fragmented message may be
coalesced or split by an intermediary.
...
The WebSocket Protocol is designed on the principle that there should
be minimal framing (the only framing that exists is to make the
protocol frame-based instead of stream-based and to support a
distinction between Unicode text and binary frames). It is expected
that metadata would be layered on top of WebSocket by the application
layer, in the same way that metadata is layered on top of TCP by the
application layer (e.g., HTTP).
Conceptually, WebSocket is really just a layer on top of TCP that
does the following:
adds a web origin-based security model for browsers
adds an addressing and protocol naming mechanism to support
multiple services on one port and multiple host names on one IP
address
layers a framing mechanism on top of TCP to get back to the IP
packet mechanism that TCP is built on, but without length limits
includes an additional closing handshake in-band that is designed
to work in the presence of proxies and other intermediaries
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).