The need for connect/listen on raw sockets?

Member
Posts: 277
Joined: 2004.10
Post: #1
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...)

Global warming is caused by hobos and mooses
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
How could either make sense, given that there's no protocol at this level?
Quote this message in a reply
Member
Posts: 277
Joined: 2004.10
Post: #3
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;
}

Global warming is caused by hobos and mooses
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
you don't have nearly enough htonl and htons calls in that code, whatever other problems it might have.
Quote this message in a reply
Member
Posts: 277
Joined: 2004.10
Post: #5
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...
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #6
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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
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!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
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...
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #9
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)
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #10
JOOI, is this working code on mac OS?

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #11
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...

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Quote this message in a reply
Member
Posts: 277
Joined: 2004.10
Post: #12
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)

Global warming is caused by hobos and mooses
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #13
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...)
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #14
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)

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Quote this message in a reply
Member
Posts: 131
Joined: 2004.10
Post: #15
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
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Connect to Server from Iphone BugSniper 6 9,559 Jul 15, 2009 04:57 PM
Last Post: BugSniper
  Cocoa/Objective-C and TCP Sockets... TimMcD 2 6,239 Jun 13, 2009 06:15 PM
Last Post: TimMcD
  Server/database interaction in C++ using sockets wyrmmage 2 5,297 Jan 20, 2007 02:17 PM
Last Post: wyrmmage
  Using threads to set a timeout on a connect() call SOUR-Monkey 6 7,672 Feb 13, 2005 09:59 PM
Last Post: ggadwa