iDevGames Forums
The need for connect/listen on raw sockets? - Printable Version

+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Tools & Technology (/forum-10.html)
+--- Thread: The need for connect/listen on raw sockets? (/thread-3810.html)

Pages: 1 2


The need for connect/listen on raw sockets? - BinarySpike - Oct 15, 2006 07:42 PM

I've been doing some raw sockets tutorials, but none of them work right...

So I was wondering, is there a need for connect/listen or bind using a raw socket? (read and write based)

I can't find *anything* that is up to date or uses other code bases...

btw, IPv4 if it makes any difference... (I don't know what I support...)


The need for connect/listen on raw sockets? - OneSadCookie - Oct 15, 2006 08:03 PM

How could either make sense, given that there's no protocol at this level?


The need for connect/listen on raw sockets? - BinarySpike - Oct 15, 2006 08:27 PM

Um...
I generated IP and UDP headers, I didn't provide a payload, and I sent using send...

I haven't found *anything* and I've been searching for two days... just a couple outdated tutorials...

My RAW sockets reader didn't accept it either... here's the code for both...
(I was just wondering cause I saw a tutorial that had bind and connect in it)

I've tried three styles, and none of them get caught... I'm not sure how to tell they are being sent either... I don't need a catcher! I need a thrower mainly...
(although I will need a catcher after a while)


Throw
Code:
#include <iostream.h>
#define P 5000

#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define maxBufSize 4096

struct IPHeader {
unsigned char ip_hl:4, ip_v:4; /* this means that each member is 4 bits */
unsigned char ip_tos;
unsigned short int ip_len;
unsigned short int ip_id;
unsigned short int ip_off;
unsigned char ip_ttl;
unsigned char ip_p;
unsigned short int ip_sum;
unsigned int ip_src;
unsigned int ip_dst;
}; /* total ip header length: 20 bytes (=160 bits) */


struct UDPHeader {
unsigned short int uh_sport;
unsigned short int uh_dport;
unsigned short int uh_len;
unsigned short int uh_check;
}; /* total udp header length: 8 bytes (=64 bits) */


unsigned short csum (unsigned short *buf, int nwords)
{
  unsigned long sum;
  for (sum = 0; nwords > 0; nwords--)
    sum += *buf++;
  sum = (sum >> 16) + (sum & 0xffff);
  sum += (sum >> 16);
  return ~sum;
}

int main(int argc, char * argv[])
{
char datagram[maxBufSize];

IPHeader *iph = (IPHeader *) datagram;
UDPHeader *udph = (UDPHeader *) datagram + sizeof(IPHeader);
memset(datagram, 0, maxBufSize);

int fd = socket (PF_INET, SOCK_RAW, IPPROTO_UDP);

sockaddr_in sin;
sin.sin_family = AF_INET;
sin.sin_port = htons(P);
sin.sin_addr.s_addr = inet_addr ("127.0.0.1");


iph->ip_hl = 5;
  iph->ip_v = 4;
  iph->ip_tos = 0;
  iph->ip_len = sizeof (IPHeader) + sizeof (UDPHeader);    /* no payload */
  iph->ip_id = htonl (54321);   /* the value doesn't matter here */
  iph->ip_off = 0;
  iph->ip_ttl = 255;
  iph->ip_p = 6;
  iph->ip_sum = 0;              /* set it to 0 before computing the actual checksum later */
  iph->ip_src = inet_addr("1.2.3.4");/* SYN's can be blindly spoofed */
  iph->ip_dst = sin.sin_addr.s_addr;
  
  udph->uh_sport = htons(1234);
  udph->uh_dport = sin.sin_port;
  udph->uh_len = sizeof(UDPHeader);
  udph->uh_check = 0;

  iph->ip_sum = csum ((unsigned short *) datagram, iph->ip_len >> 1);
  int one = 1;
  const int *val = &one;
  int error = setsockopt(fd, IPPROTO_IP, IP_
  if (setsockopt (fd, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0)
        printf ("Warning: Cannot set HDRINCL!\n");




if (write(fd, datagram, maxBufSize) > 0)
cout << "caught packet" << endl;
cout << "quiting" << endl;
return 0;
}

Catch
Code:
#include <iostream.h>


#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>



int main(int argc, char * argv[])
{
int fd = socket (PF_INET, SOCK_RAW, IPPROTO_TCP);
char buffer[8192]; /* single packets are usually not bigger than 8192 bytes */
while (true)
    {
        if (read (fd, buffer, 8192) > 0)
            cout << "caught packet" << endl;
    }
cout << "quiting" << endl;
return 0;
}



The need for connect/listen on raw sockets? - OneSadCookie - Oct 15, 2006 08:31 PM

you don't have nearly enough htonl and htons calls in that code, whatever other problems it might have.


The need for connect/listen on raw sockets? - BinarySpike - Oct 15, 2006 10:04 PM

OneSadCookie Wrote:you don't have nearly enough htonl and htons calls in that code, whatever other problems it might have.

Those shouldn't matter if I'm running localhost though...
Any tutorials would be nice if you don't have any insightful information...


The need for connect/listen on raw sockets? - akb825 - Oct 15, 2006 11:13 PM

At the very bottom of this page is some sample code for a server/client. If you want to connect with a specific IP address, you can just copy the address info for the server replacing INADDR_ANY with the IP address.


The need for connect/listen on raw sockets? - OneSadCookie - Oct 16, 2006 12:12 AM

BinarySpike Wrote:Those shouldn't matter if I'm running localhost though...

Why shouldn't they? You think nothing tries to parse the IP header you create?

Maybe it does, maybe it doesn't. I wouldn't like to make a blanket statement without any evidence!


The need for connect/listen on raw sockets? - OneSadCookie - Oct 16, 2006 12:13 AM

akb825 Wrote:At the very bottom of this page is some sample code for a server/client. If you want to connect with a specific IP address, you can just copy the address info for the server replacing INADDR_ANY with the IP address.

He's trying to do raw socket stuff, not standard TCP/UDP stuff... Maybe I'm blind, but I didn't see anything on that page about raw sockets...


The need for connect/listen on raw sockets? - akb825 - Oct 16, 2006 12:39 AM

Sorry, I thought "raw sockets" meant using sockets directly. Blush Be careful, though: according to Wikipedia, raw sockets are limited under Windows. (in case you want Windows compatibility)


The need for connect/listen on raw sockets? - unknown - Oct 16, 2006 04:26 AM

JOOI, is this working code on mac OS?


The need for connect/listen on raw sockets? - Steven - Oct 16, 2006 03:28 PM

Could you be having problems with your setting both the source and destination addresses to 1.2.3.4? That likely isn't your IP address...


The need for connect/listen on raw sockets? - BinarySpike - Oct 16, 2006 05:42 PM

Steve Wrote:Could you be having problems with your setting both the source and destination addresses to 1.2.3.4? That likely isn't your IP address...

sin.sin_addr.s_addr = inet_addr ("127.0.0.1");
...
iph->ip_src = inet_addr("1.2.3.4");
iph->ip_dst = sin.sin_addr.s_addr;

Source is 1.2.3.4 and destination is 127.0.0.1

I didn't notice source, thanks Smile


Quote:Why shouldn't they? You think nothing tries to parse the IP header you create?

Maybe it does, maybe it doesn't. I wouldn't like to make a blanket statement without any evidence!

I didn't, you use hton functions to convert a variable's byte ordering

And should only be needed if you send packets to another architecture that has the opposite bit ordering (in this case I should be able to send it to another mac computer fine)

But, there are routers, that might run off a different bit ordering, but again when you send to 127.0.0.1 you are routed by your kernel, or on some older computer ethernet hardware.

So if you connect localhost you never leave your computer, and I haven't read anything to say that the kernel and programs use different bit ordering...

That's what I've read, and been told since I began sockets. (I wrote a socket library that handled sockets but I didn't know about byte ordering, so mac-to-windows didn't work, I am sure mac-to-mac worked fine)


The need for connect/listen on raw sockets? - OneSadCookie - Oct 16, 2006 06:23 PM

BinarySpike Wrote:And should only be needed if you send packets to another architecture that has the opposite bit ordering (in this case I should be able to send it to another mac computer fine)

But, there are routers, that might run off a different bit ordering, but again when you send to 127.0.0.1 you are routed by your kernel, or on some older computer ethernet hardware.

So if you connect localhost you never leave your computer, and I haven't read anything to say that the kernel and programs use different bit ordering...

That's what I've read, and been told since I began sockets. (I wrote a socket library that handled sockets but I didn't know about byte ordering, so mac-to-windows didn't work, I am sure mac-to-mac worked fine)

No, *everything* uses network byte order for these protocol headers. Even if you're sending to yourself, you still need to make sure that you put the bytes in the right order, if there's the slightest chance that the OS might try to interpret them.

(and remember, Macs have two different byte orders these days...)


The need for connect/listen on raw sockets? - Steven - Oct 16, 2006 08:45 PM

BinarySpike: Have you tried using something like Ethereal (now WireShark?)

It can be invaluable to see both if the packet actually gets on the wire and then it will show you how it interprets the packet (so you can see if it is valid)


The need for connect/listen on raw sockets? - Zekaric - Oct 17, 2006 08:48 AM

I don't know if this will help any. In the past we've been bitten by this at work. Structures may not be as compact as you have declared them. There may be padding inside that allows the values to be aligned on byte boundaries. This may be an issue if you are sending the raw structure over the wire and the other end is expecting a certain values at certain byte locations other than byte boundaries.

Just in case, you might want to look for a #pragma pack() sort of preprocessor command that will ensure the byte ordering of the structures.

This is on top of making sure the values are in network order because everything inbetween the send and recieve (OS, Internet) is expecting network order. But then OSC has pretty much berrated you on that point. Smile