I was writing a multithreaded ping program. I created rawsockets on each thread (for each IP) and sent ICMP Echo Request to each using sendto() and then I did recvfrom() in each thread. I am getting messages from IPs in various sockets(like if I had used socket S1 for sendto for IP1, I get echo-replies from IP1 to S1, S2 etc). Do I need to do a bind?
Also another problem is that even though I send only 1 ICMP request I get back many echo replies from target. Is there any way I can limit this? This is causing me to miss some of the other ICMP packets. Is there a way for my program to ask the target to stop sending ICMP echo's?
Thanks,
Raw sockets pick up all incoming packets; you will need to do your own filtering, or - better yet - only open one raw socket, and detect all of the incoming echo replies on a single thread.
Your duplicate packets may be because of the multiple raw sockets - you'll get one copy of each incoming packet per socket. Also note that in some cases internet packets can be duplicated (this is rare, however).
Related
I am learning about the ping implementation in C.
The problem is, I was using a raw sockets to receive the packet. For all packets we have a identification value in ICMP header.
I was running the ping in multiple terminal.
For example, I was running three ping google.com in three terminals.
For the first ping the identification value is 23456, the second ping identification value is 34564, and the third ping identification value is 98763.
My problem is the second ping have to receives the identification with 34564 packet, but it receives the identification value as 23456.
For each ping the new raw socket is creating. But it receives another ping packet.
Can anyone please explain me, why it receives another ping packet ?
UPDATE:-
I have another one doubt. The doubt is,
raw sockets reads the packet from where and how it identify the packet is for this raw socket ?
UPDATE 1:-
Here is the link for the codes.
ping_common.c
ping.c
ping.h
What's you are seeing is by design of the raw socket, because raw sockets are meant to receive all the raw packets. So to only receive the reply to certain ICMP packets, you need to apply filters on the socket. First you can use ICMP_FILTER socket options to restrict receiving of certain ICMP types:
struct icmp_filter filter;
filter.data = <bit mask of ICMP types, like ICMP_REPLY>;
setsockopt(sock, SOL_RAW, ICMP_FILTER, &filter, sizeof filter)
Second, you can attach socket filter to enforce only receive the package with the given ICMP ID:
struct sock_fprog filter;
// set filter to check ID with your own ID
setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &filter, sizeof filter);
To answer your other doubt:
raw sockets reads the packet from where and how it identify the packet is for this raw socket ?
Raw socket sit along side other protocol handlers after IP layer. From book "Understanding Linux Network Internals" Chapter 25.5:
Here are some examples of interactions between protocols:
IP protocol
The ip_local_deliver_finish routine, described in Chapter 24, delivers
ingress ICMP messages to the receive routine icmp_rcv registered by
the ICMP protocol, but it also delivers them to the raw IP sockets
that registered against the ICMP protocol (raw_v4_input).
I'm maintaining some network driver and I've got some problems with lost of data. The effect is that when I send for example ICMP or UDP ping using ping or nping some of the udp/icmp packets are lost.
I'm sure that on ping/nping side of the transmission the ping reply is received by my driver and the kernel (tcpdump shows incoming udp or icmp packets as a reply).
But application ping/nping shows sometimes that for example 80% packets are lost. I suspect that those packets are lost somewhere between kernel and user space.
I know that for UDP there is procedure udp_rcv() for maintenance of UDP packets, but I don't know which procedure is next in the path of delivering of the packet to user space application.
Linux kernel is in version 3.3.8.
My question is - how to trace the whole path of transition of the packet from my driver to user space socket buffer?
udp_rcv() is a callback that is passed to struct net_protocol as a .handler.
You may either look at usage of this handler field in the structure, or you can also see if some error occurs. There is a callback err_handler. Maybe packet loss happens here and error handler will be called.
P. S. Remember that UDP does not guarantee 100% transmit success, and one lost packet out of 100 might be expected behavior. (:
We want to receive packets from udp sockets, the udp packets have variable length and we don't know how long they really are until we receive them (parts of them exactly, length were written in the sixth byte).
We tried the function lrs_set_receive_option with MarkerEnd only to find it has no help on this issue. The reason why we want to receive by packets is that we need to respond some packet by sending back user-defined udp packets.
Is there anybody knows how achieve that?
UPDATE
The LR version seems to be v10 or v11.
We need respond an incoming udp packet by sending back a udp packet immediately.
The udp packet may be like this
| orc code | packet length | Real DATA |
Issue is we can't let loadrunner return data for each packets, sometimes it returns many packets in a buffer, sometimes it waits until timeout though when there has been an incoming packet in the socket buffer. While in the c programming language world, when calling recvfrom(udp socket) we are returned only one udp packet per time (per call) which is want we really want.
If you need raw socket support to intercept at the packet level then you are likely going to have to jump to a DLL virtual user in Visual Studio with the raw socket support.
As to your question on UDP support: Yes, a Winsock user supports both core transport types, UDP and TCP. TCP being the more common variant as connection oriented. However, packet examination is at layer 3 of the OSI model for the carrier protocol IP. The ACK should come before you receive the dataflow for your use in the script. You are looking at assembled data flows in the data.ws when you jump to the TCP and UDP level.
Now, you are likely receiving a warning on receive buffer size mismatch which is taking you down this path with a mismatch to the recording size. There is an easy way to address this. If you take your send buffer and construct it using the lrs_set_send_buffer() function, then anything that returns will be taken as correct, ignoring the previously recorded buffer size and not having to wait for a match or timeout before continuing.
I want to make a chat room using raw socket in C. I have following problems:
Q 1 : Can I use select function to handle multiple connections in case of raw sockets ?
Q 2 : Port nos in sockets are real ports or logically implemented for various applications on transport layer??
Q 3 : I am having one computer only so using lo ( local loop) as my interface. So the process which is initiating the chat has send first and then receive call, so it's receiving it's own data. How to restrict it?
Any help would be appreciated since that would help me in increasing my confidence on raw sockets.
Thanks :)
If you want this to be a real, usable chat system, stop. Don't use raw sockets. Huge mistake.
If you are just playing around because you want to put “raw sockets” under the “Experience” section of your résumé, you may read on.
You can use the select function to detect when a raw socket has a packet available to receive, and when it can accept a packet to transmit. You can pass multiple file descriptors to a single call to select if you want to check multiple raw sockets (or whatever) simultaneously.
Port numbers are part of the TCP and UDP protocols (and some other transport layer protocols). The kernel doesn't look for port numbers when receiving packets for raw sockets.
The raw(7) man page‚ states:
All packets or errors matching the protocol number specified for the raw socket are passed to this socket.
And it also states:
A raw socket can be bound to a specific local address using the bind(2) call. If it isn't bound, all packets with the specified IP protocol are received.
Therefore you probably want to at least use different IP addresses for each end of the “connection”, and bind each end to its address.
“But!” you say, “I'm using loopback! I can only use the 127.0.0.1 address!” Not so, my friend. The entire 127.0.0.0/8 address block is reserved for loopback addresses; 127.0.0.1 is merely the most commonly-used loopback address. Linux (but perhaps not other systems) responds to every address in the loopback block. Try this in one window:
nc -v -l 10150
And then in another window:
nc -s 127.0.0.1 127.0.0.2 10150
You will see that you have created a TCP connection from 127.0.0.1 to 127.0.0.2. I think you can also bind your raw sockets to separate addresses. Then, when you receive a packet, you can check whether it's from the other end's IP address to decide whether to process or discard it.
Just curious, why do you want to use raw sockets? Raw sockets (AF_INET, SOCK_RAW) allow you to send out "raw" packets, where you are responsible for crafting everything but the MAC and IP layers.
A1: There are no "connections" with raw sockets. Just packets.
A2: There are no "ports" with raw sockets. Just packets. "Port numbers" as we know them are part of the TCP or UDP protocols, both of which are above the level at which we work with raw sockets.
A3: This is not specific to raw sockets - you would have this issue regardless of your protocol selection. To really answer this, we would need to know much more about your proposed protocol, since right now, you're simply blasting out raw IP packets.
When receiving on an ICMP socket, (SOCK_RAW with IPPROTO_ICMP), since
there is no concept of "port" in the ICMP protocol, how can an
application determine that a received packet is not part of some other
TCP/UDP/whatever socket transmission that is also happening at the
same time?
For example, suppose you have an application with 2 threads. Thread 1
sets up a TCP server socket, and continuously receives data from a
connected client. Thread 2 continuously sends echo request packets
(ping) to the same client using an ICMP socket, and then receives echo
replys. What is to prevent Thread 2 from receiving one of the TCP
packets instead?
ICMP is a different protocol from TCP and UDP, as determined by the protocol field in the IP header. When you open a socket with IPPROTO_ICMP, you're telling the socket to transmit and receive only packets with IP headers whose protocol field is set to ICMP.
Similarly, sockets opened with IPPROTO_TCP or IPPROTO_UDP respond only to packets whose IP headers contain a protocol field that is set to TCP or UDP, respectively.
You can check the ICMP header for the type and see if its ICMP Echo Response (Type 0). Also in ICMP, the response will contain the request you had sent in the first place.
Received UDP & TCP packets never passed to raw sockets . IF a process wants to read IP datagram containing UDP or TCP packets the packets must be read at data link layer . check this link
http://aschauf.landshut.org/fh/linux/udp_vs_raw/ch01s03.html
if the packet is not cached at layer 2 then it is processed by kernel .
And if the packet is of icmp protocol and it is of type echo request or timestamp request or address mask request then it is entirely processed by kernel otherwise it will passed to RAW SOCKETS.
Another one all datagrams with a protocol field that the kernel does not understand are passed to raw sockets only basic processing of ip is done on them
At last if datagram arrives in fragments then nothing is passed to raw sockets until all fragments are arived and reassembled .
If you want to learn more, then read this book.