In C I bind a datagram socket (AF_INET, SOCK_DGRAM) to INADDR_ANY. I then periodically use this socket to send and receive datagrams, and monitor the flow of packets with pcap. The problem is, I can't tell whether a packet is incoming or outgoing using pcap.
The transmission/receiving and the pcap monitoring are running in separate threads, and for synchronisation reasons they can't communicate. I only want to track the incoming packets, not the ones being sent, so does anyone have an idea as to how I can do that?
I thought already of testing the destination ip address, but I can't figure out any way to get my local ip. the machine this is running on doesn't have a static ip, much less an assigned domain name, and it seems that getsockname doesn't work on sockets bound to INADDR_ANY. Also tried using ioctl(sockfd, SIOCGIFCONF, &buffer), which didn't work either - sets buffer.ifc_len=0.
Found a solution. I can get my own ip using this:
char *command = malloc(100);
sprintf(command,"ifconfig %s|grep -o \"inet addr:[^ ]\"|grep -o -e \"[0-9]\.[0-9]\.[0-9]\.[0-9]*\"",device);
char path[1035];
FILE *fp;
fp = popen(command,"r");
fgets(path, 1034, fp);
pclose(fp);
my_ip = malloc(sizeof(char)*(1+strlen(path)));
memcpy(my_ip, path, strlen(path)-1);
my_ip[strlen(path)-1] = 0;
Related
I am trying to understand the USBIP tool code from Linux (https://github.com/torvalds/linux/tree/master/tools/usb/usbip).
USBIP has a command that attaches a remote USB from an IP to a client system. If you look at the code (https://github.com/torvalds/linux/blob/master/tools/usb/usbip/src/usbip_bind.c#L130) below, which binds the USB, if the function calls close(sockfd); and close the socket, then how the communication is done between client and server for USB data.
From Docs (https://docs.kernel.org/usb/usbip_protocol.html):
Once the client knows the list of exported USB devices it may decide
to use one of them. First the client opens a TCP/IP connection to the
server and sends an OP_REQ_IMPORT packet. The server replies with
OP_REP_IMPORT. If the import was successful the TCP/IP connection
remains open and will be used to transfer the URB traffic between the
client and the server.
It says connection remains open if import is successful, then what is the purpose of close(sockfd);. I can also see sockfd is sent inside query_import_device(sockfd, busid); but if it is closed how this is used?
static int attach_device(char *host, char *busid)
{
int sockfd;
int rc;
int rhport;
// creates a TCP connection to the specified host on the specified port.
sockfd = usbip_net_tcp_connect(host, usbip_port_string);
if (sockfd < 0) {
err("tcp connect");
return -1;
}
// sends a query to the connected host to import the device specified by "busid".
rhport = query_import_device(sockfd, busid);
if (rhport < 0)
return -1;
// closes the previously established TCP connection.
close(sockfd);
// records details of the connection, such as the host and port, the busid of the device, and the assigned rhport.
rc = record_connection(host, usbip_port_string, busid, rhport);
if (rc < 0) {
err("record connection");
return -1;
}
return 0;
}
If you look at the source code of usbip helper program, query_import_device(), it establishes the connection and then calls import_device() to finish it.
In turn, import_device() calls usbip_vhci_attach_device(), that calls usbip_vhci_attach_device2()... that eventually writes the sockfd and some extra data to the /sys/*/attach pseudo file for the given device.
To see what happens next we need to go to kernel mode. So, looking at the source code of the usbip, at function attach_store(). This function parses the sockfd back into an integer file descriptor and, most notably, does this:
struct socket *socket;
socket = sockfd_lookup(sockfd, &err);
This converts a file descriptor into a real kernel socket object. And it increases the reference count. Note how if any of the further checks fail, it calls sockfd_put(socket); to decrease that reference count.
But if the function succeeds, the socket is stored into the device. It is just as if an userland program had done a call to dup(): it doesn't matter if the original sockfd is closed, the kernel keeps the actual socket opened as long as it is needed.
You can see that the value of sockfd is also stored in the device, but it isn't actually used for anything other than reading back from /sys, so it doesn't matter if it is no longer a valid file descriptor.
So the close is actually necessary because the kernel dups the socket internally, that keeps the connection opened. And you do not want to keep an extra FD referencing the same socket, if you try to use that socket for anything that could mess up the device connection. The responsible thing to do is just to close it.
So, after I got this error, I've been looking for an answer in here, almost everyone had a difficult way to fix this error but no one explained why this error occurs at all, so I don't find this question to be exactly duplicate.
I wrote a TCP socket in C and I used "getaddrinfo" function to make the socket work with hostnames, well it worked perfectly! you can find my codes on github.
but when I tried to create a UDP socket by "getaddrinfo" I got this error:
Servname not supported for ai_socktype
client.c
const char *host = argv[1];
const char *service = argv[2];
const char *string = argv[3];
struct addrinfo addrCriteria;
memset(&addrCriteria, 0, sizeof(addrCriteria));
addrCriteria.ai_family = AF_UNSPEC;
addrCriteria.ai_socktype = SOCK_DGRAM;
addrCriteria.ai_protocol = IPPROTO_UDP;
struct addrinfo *servAddr;
int ret = getaddrinfo(host, service, &addrCriteria, &servAddr);
if(ret != 0)
sysError(gai_strerror(ret));
I realized that when I give "service" a numeric input like 8080, no errors would return but when I use a string as service name like "tproxy" which points to port/8081, 'gai_strerror' returns mentioned error.
Obviously, gai_strerror says: "service names not supported for 'SOCK_DGRAM' socket types", but why? I mean the exact reason for "getaddrinfo" not supporting name services over UDP sockets?
Is there any other way to use service names with UDP sockets instead of port numbers? how?
TL;DR: There is no tproxy UDP port.
If you look up the tproxy service for UDP sockets in your service database,
getent services tproxy/udp
You get no output, because tproxy is not an UDP service. If you look at all tproxy services regardless of the protocol, getent services | grep -e tproxy, you'll see
tproxy 8081/tcp
which means that tproxy service is only defined for TCP protocol.
This means that if you ask getaddrinfo() for an UDP socket for service 8081, you will not find anything, because tproxy is only defined for TCP and not UDP.
Compare to the case where you ask for and UDP socket for xmpp-client service. At least my service database (getent services xmpp-client/udp) responds with
xmpp-client 5222/udp jabber-client
and indeed, getaddrinfo() happily provides the socket description for such UDP sockets (using xmpp-client or jabber-client as the service).
So, there are services like xmpp-client that do have both TCP and UDP ports defined. On my system, getent services | grep -e xmpp-client shows
xmpp-client 5222/tcp jabber-client
xmpp-client 5222/udp jabber-client
Because TCP and UDP are different protocols over IP, it makes sense that a service could use a different port number for TCP and UDP communications. So, it is unreasonable to assume that the service database should just return the same port numbers for TCP and UDP sockets.
In other words, you encounter the error because you mistakenly assume that because some service uses a TCP port, with a name registered in the service database, you should be able to use that name to specify an UDP port number, too.
TCP and UDP are separate protocols, and their port number spaces are separate. For example, TCP port 512 is used by the Unix exec r-service, whereas UDP port 512 is used by the biff mail notification service.
When a non-numeric value is given for the service parameter, it is looked up (on Linux) in the /etc/services file. This file maps a service name to a port/protocol. Below are some sample entries:
ssh 22/tcp
telnet 23/tcp
domain 53/tcp # name-domain server
domain 53/udp
The reason you're getting an error is because there is no UDP entry in your /etc/services file for "tproxy". Take a look at this file and look for an entry that does specify a UDP port such as "domain". That should have entries for both 53/tcp and 53/udp. If you pass in "domain" as the service name you should get a result back.
I am writing a proxy in C (Windows 8.1 Environment). I did the same in Linux without any trouble but in windows things look different.
First of all, I am aware of MS Windows restrictions for sending RAW TCP Data and read this post. I also found WinPcap as a potential solution. The difference is I need to add Ethernet frame (DstMac, SrcMac, and Protocol Type) and ran the following codes:
if ((fp = pcap_open_live(d->name, // name of the device
65536, // portion of the packet to capture. It doesn't matter in this case
1, // promiscuous mode (nonzero means promiscuous)
1000, // read timeout
errbuf // error buffer
)) == NULL)
{
fprintf(stderr, "\nUnable to open the adapter. %s is not supported by WinPcap\n", d->name);
}
then I created a packet:
u_char * data;
data = (u_char *)malloc(sizeof(u_char)*(ip_size+14));
memcpy((void*)data, (void*)dmac, 6);
memcpy((void*)(data + 6), (void*)smac, 6);
USHORT TmpType = 8;
memcpy((void*)(data + 12), (void*)&TmpType, 2);
memcpy(data+14, iphdr, ip_size); //iphdr is the full packet -(minus) ethernet header
//ip_size is the sizeof(iphdr)
pcap_sendpacket(fp, data, ip_size+14); //14: size of ethernet header
free(data);
In my test the first iphdr is a TCP Syn packet. When I send it to the network, I can capture it in Wireshark. However, the remote server does not respond to this packet and I got [TCP Out-of-Ordfer] messages and then a few RST packet and nothing happens.
my questions are:
1- Is winpcap the only feasible solution in windows with C?
2- If no, could you please provide any example/resource for developing RAW TCP sockets in C?
3- If yes, what causes the server does not response my manually crafted TCP Syn.
PS: I use the same code for creating TCP SYN in linux and it works perfectly. So, I have no doubt the tcphdr contain the IP header, TCP header and payload with correct checksums in both IP, and TCP headers.
I'm programming in Linux environment.
I want to establish a TCP socket between two PCs, and multiplexing it.
To be specific, here is the pseudo-code:
void func_in_process0()
{
socket s = socket(AF_INET, SOCK_STREAM, 0);
connect(s, "1.1.1.1", 8080);
socket s1 = ADD_CHANNEL(s, 1); // key part
SEND_FILE_DESCRIPTOR_TO_PROCESS(s1, process1);
socket s2 = ADD_CHANNEL(s, 2); // key part
SEND_FILE_DESCRIPTOR_TO_PROCESS(s2, process2);
WAIT_FOR_PROCESS_TO_FINISH(process1);
WAIT_FOR_PROCESS_TO_FINISH(process2);
close(s);
}
void func_in_process1()
{
socket s1 = GET_SOCKET_FROM_PROCESS0();
send(s1, "abcdefg");
close(s1);
}
void func_in_process2()
{
socket s2 = GET_SOCKET_FROM_PROCESS0();
send(s2, "abcdefg");
close(s2);
}
The key part is how to implement function ADD_CHANNEL.
I found a document TCP Session Control Protocol which provides exactly the function I want.
But I don't think it is implemented in Linux kernel.
I can implement this protocol in userspace, but variable "s1" and "s2" will not be file descriptor and can't be sent to other processses.
Edit:
process0, process1 and process2 are all on localhost.
socket "s" is a client socket.
1.1.1.1 is a remote PC, who is the server. so proc1 and proc2 both sends packet to 1.1.1.1 through the CHANNEL.
the server is CHANNEL aware too.
Edit2:
I read the SCP Protocol, but it still has no in-kernel implementation.
I learned the SCTP multi-streaming, which is implemented in kernel, but there's no API that creates sub-socket so the problem remains.
Sure, they can be file descriptors. Create two pipes and give one end to each of the other two processes. Your 'multiplexor' will read from, and write two, the other ends of the two bidirectional pipes.
I want to use pcap to capture packets
and then send the captured packets to another host
my source code snippets are like:
for(;;){
pcap_packet = pcap_next(pcap_handler, &pcap_header);
if(pcap_packet !=NULL)
printf("capture a packet with length of %d\n", pcap_header.len);
// send the packet as payload to the sender, excluding the Ethernet Header
n = send(sd_proxy, pcap_packet+ETHERNET_HDR_LEN, pcap_header.len-ETHERNET_HDR_LEN, 0);
if(n<0){
shutdown(connfd, SHUT_RDWR);
close(connfd);
break;
} new
}
so basically, I want program to be blocked by the pcap_next, once a
the socket sd_proxy establishes a TCP connection with the other host,
if the other host initiate an active TCP close, I want to detect this
active close. Ideally, I should use a select and a n=recv(rd_fd, ...)
if the other host initiates a active close, select will notice there is something with rd_fd and then I see whether 'n=0' or not.
but with pcap, select can't cooperate with pcap
so how to finish my task?
thanks!
select can't cooperate with pcap
Why not? Have you tried using pcap_get_selectable_fd() on pcap_handler and adding the resulting file descriptor to the file descriptor set in your select() call?
You're working on Linux, so that should Just Work.
(If you were running on a system that uses BPF, such as *BSD or OS X, you might have problems with this, at least with older versions of those OSes; various *BSDs have had their select-with-BPF bugs fixed for a while; on OS X, I fixed it in Lion, so it could have problems on Snow Leopard and earlier.)