I am trying to get an ICMP packet using the recvfrom() function. The function receives a packet including the IP header, I only need the ICMP portion.
Is it possible to somehow configure the socket so that recvfrom() receives only an ICMP packet through it, without the IP header?
I create socket like this:
int sock_fd;
if ((sock_fd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) == -1) {
perror("socket");
return ERROR;
}
UPDATE: I got an answer that this is impossible. So, if I make the buffer large, since the length of the IP header can be different, will recvfrom() write only one packet to the buffer, or can it be that the beginning of the next packet will be written to the end of the buffer?
Related
I have a simulator application which Unix Domain datagram sockets, which sends data to socket path for.ex /var/lib/XYZ.
sendto is returning -2 which is due to other end no peer is there(no other unix domian socket application is running)
I would like to write a datagram client/peer application using Unix Domain Sockets for receiving data from the server/simulator(which is sending data to /var/lib/XYZ).
My code is as follows:
#define BUF_SIZE 1024
#define SV_SOCK_PATH "/var/lib/XYZ"
#define SV_SOCK_PATH2 "/var/lib/ABC"
creation of Unix Domain sockets as below:
struct sockaddr_un svaddr, claddr;
....
sfd = socket(AF_UNIX, SOCK_DGRAM, 0);
if (sfd == -1)
printf("socket creation failed");
memset(&claddr, 0, sizeof(struct sockaddr_un));
claddr.sun_family = AF_UNIX;
strncpy(claddr.sun_path, SV_SOCK_PATH2, sizeof(claddr.sun_path) - 1);
if (bind(sfd, (struct sockaddr *) &claddr, sizeof(struct sockaddr_un)) == -1)
printf("bind failed");
/* Construct address of server */
memset(&svaddr, 0, sizeof(struct sockaddr_un));
svaddr.sun_family = AF_UNIX;
strncpy(svaddr.sun_path, SV_SOCK_PATH, sizeof(svaddr.sun_path) - 1);
while(1)
{
int len=sizeof(struct sockaddr_un);
numBytes = recvfrom(sfd, resp, BUF_SIZE, 0, (struct sockaddr*)&svaddr,&len);
if (numBytes == -1)
printf("recvfrom error");
else{
printf("no of bytes received from server: %d",(int)numBytes);
printf("Response %d: %s\n", (int) numBytes, resp);
}
}
remove(claddr.sun_path);
//exit(EXIT_SUCCESS);
}
but the program is not receiving anything...is there anything missed out??
When it comes to datagrams, there is no real client or server. Either side attempting to send is responsible for addressing datagrams to the other. So, in your code, the setup is all wrong. You're apparently attempting to direct the "server" (but really not a server, just the other peer) to send to you via svaddr but that isn't how it works.
For a datagram AF_UNIX socket, the sender either needs to explicitly specify the receiver's address in a sendto call, or it needs to first connect its socket to the receiver's address. (In the latter case, it can then use send instead of sendto since the peer address has been specified via connect.)
You can't specify the sending peer's address in the recvfrom call. The socket address argument in the recvfrom is intended to return to you the address from which the datagram was sent. Whatever is in that variable will be overwritten on successful return from recvfrom.
One way datagram peer programs are often structured: the "server" creates a well-known path and binds to it, then a "client" creates its own endpoint and binds to it (constructing a unique socket address for itself), then the client can sendto the server's well-known socket. The server, by using recvfrom to obtain the client's address along with the datagram, can then use sendto along with the address to return a message to the client (without needing to connect its socket). This provides a sort of client-server paradigm on top of the fundamentally equal-peer orientation of the datagram socket.
Finally, I should mention that it's usually a good idea to use fully specified pathnames to ensure both peers are using the same address even if started from different directories. (Normally, with AF_UNIX, the address is a path name in the file system used to "rendezvous" between the two peers -- so without a full path "some_socket" is "./some_socket" in the current working directory. Some systems, such as linux, also support an abstract "hidden" namespace that doesn't require a full path, but you must use an initial null byte in the name to specify that.)
I have implemented a RAW Socket in linux to send and receive ICMP Packets,
I have created RAW Socket using socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) and start receiving the Packets using recvfrom. Initially i was receiving the packets with buffer len set to 1000 in recvfrom and then typecast the packets according to the ICMP and IP headers.
But when i start receiving the packets header and data individually (first receive the 20 necessary bytes for IP Headers and then finding the data len from that header and receive that much bytes of data using recvfrom ).
I was not been able to receive the data part as i am not been able to receive the second data part.
First Method :
n=recvfrom(sockfd,buf,1000,0,(struct sockaddr *)&cliaddr,&clilen);
struct iphdr *ip_hdr = (struct iphdr *)buf;
struct icmphdr *icmp_hdr = (struct icmphdr *)((char *)ip_hdr + (4 * ip_hdr->ihl));
Second Method :
struct iphdr ip_hdr;
struct icmphdr icmp_hdr;
n=recvfrom(sockfd, &ip_hdr, 20 ,0,(struct sockaddr *)&cliaddr,&clilen);
len = ip_hdr->tot_len - ip_hdr.ihl*4 ;
n=recvfrom(sockfd, &icmp_hdr, len ,0,(struct sockaddr *)&cliaddr,&clilen);
In Second Case, the second receive do not receive anything.
Raw sockets don't provide a "stream" paradigm. Hence you can receive as much of the packet as you want in the initial recvfrom call. But whatever part of it you didn't receive will then be dropped. So your first method is the way to go: provide a large enough buffer to receive the IP header and its ICMP payload. Then parse it after you've received it.
The same is true of UDP packets. Reference this question and this one. UDP is obviously a different protocol, but all the same considerations apply.
I am trying to send UDP packet to my server 10.20.1.2 with port number 20000. I have implemented UDP client on PC and when i send data using sendto API , at the same time i monitor data on wireshark wireshark shows it as an ARP packet.
18967 5440.858646 PcsCompu_ef:b4:89 Broadcast ARP 42 Who has 10.20.1.2? Tell 192.168.1.70
192.168.1.70 is my machine ip where UDP client is running.
I am not sure how UDP packet is getting converted into ARP packet ?
I understand ARP is for finding MAC address of target node but here i already know MAC address of target device , How can i add it in my udp client so it directly starts UDP communication . My target device is one embedded camera , i am not expecting it to reply on ARP request so i want to prevent sending ARP request.
Below is my UDP client code :
Any inputs are highly appreciated. Thanks in advance.
/*
Simple udp client
*/
#include<stdio.h> //printf
#include<string.h> //memset
#include<stdlib.h> //exit(0);
#include<arpa/inet.h>
#include<sys/socket.h>
#define SERVER "10.20.1.2"
#define PORT 20000 //The port on which to send data
char message[3]={0x00, 0x00 , 0x24};
int main(void)
{
struct sockaddr_in si_other;
int s, i, slen=sizeof(si_other);
int ret;
if ( (s=socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) == -1)
{
printf("socket failed");
}
memset((char *) &si_other, 0, sizeof(si_other));
si_other.sin_family = AF_INET;
si_other.sin_port = htons(PORT);
if (inet_aton(SERVER , &si_other.sin_addr) == 0)
{
fprintf(stderr, "inet_aton() failed\n");
exit(1);
}
ret = sendto(s, message, sizeof(message) , 0 , (struct sockaddr *) &si_other, slen);
close(s);
return 0;
}
Some clarifications regarding networking.
1. ARP must be sent and replied
Your camera has IP interface, which means it must handle ARP requests fine without any doubts. ARP is essential part of communicating via IP, camera without ARP support makes no sense. And ARP isn't a result of converting UDP, it's a preliminary step before sending actual UDP datagram. Once ARP reply is discovered with destination MAC-address, UDP packet is sent to that destination. The issue you see isn't about hardcoding MAC to avoid ARP.
2. Your code looks fine
Compiled it locally with minor corrections (missing #include <unistd.h> header with close() declaration), tested on several targets, client works as expected.
3. Something is wrong with your network topology
You are sending message from 192.168.1.70 to 10.20.1.2, which is weird. 192.168.0.0/24 and 10.0.0.0/8 are private IP addresses from different ranges, so they normally can't reach each other without black magic (like NAT traversal). And, what is much weirder, during your attempt ARP request is sent to strange destination. Let me illustrate different cases:
if both devices are in same subnet (e.g. 192.168.1.70 sends to 192.168.1.71), then message is sent directly, so client asks "who has 192.168.1.71" in ARP request.
if devices are in different subnets (e.g. 192.168.1.70 sends to 8.8.8.8), then message is sent through gateway, thus ARP request reads "who has 192.168.1.1" or whatever your gateway address is. Gateway MAC may be already in cache, in which case ARP isn't sent at all.
in your case subnets are obviously different, but ARP is asking about direct destination address rather than gateway MAC address.
It's a shot in the dark, but probably you have two network interfaces on your PC, one connected to 192.168.0.0 subnet, the other to 10.0.0.0 and ARP request is sent from both. If you sniff the wrong interface, you see weird ARP request and don't see UDP, which is actually sent after it. By the way, seeing single arp request is also confusing, because it should be repeated several times if noone answers.
Anyway, you need to check network topology and/or simplify it. Remove unnecessary network interfaces, configure PC and camera to be on the same subnet connected to the same switch/router and investigate further.
For a non-blocking datagram socket, like UDP, when I call write()/send() on the socket, each call of write()/send() or read()/recv() deals with exactly 1 packet.
I'm wondering if a raw socket, like the below, is a datagram socket or not?
int on = 1;
rawfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
setsockopt(IPPROTO_IP, IP_HDRINCL, &on, sizeof(on));
That depends on the kind of IP header you will include in your packets (TCP or UDP). Actually it's more easier to include the UDP header since the kernel will manage some TCP mechanism.
So you have to add the UDP header in your packets, then it will be a datagram socket.
When you send data out, TCP/IP stack will add TCP/UDP header, IP header and then Ethernet header, and network work card transmit the whole packet out. For raw socket, you prepare all the headers(TCP/UDP, IP and MAC), and network work card transmit the whole packet out. So whether it is datagram depends on the header you add is TCP or UDP.
I am reading data from a socket with recv function and keep getting error when I receive ICMP destination unreachable packet. I truly don't know where the problem is. I tried setting the socket to different options but none of them worked for me. I use RAW socket.
Here is my setsockopt:
setsockopt(sock, IPPROTO_IP, IP_HDRINCL, (char *)&optval, sizeof(optval))
optval is set to 1
here is my recv:
// read response from socket
if ((len = recv(sock, buffer, BUFFER_MAX, 0)) == -1)
fprintf(stderr,"Error with reading data - %d\n",errno);
BUFFER_MAX is defined as 65536
If somebody has met with similar problem, could you please explain me there is always errno code 90, when trying to recieve ICMP dest. unreachable packet? ECHO reply works fine.