The need for connect/listen on raw sockets?
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...)
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
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
Catch
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
Post: #4
you don't have nearly enough htonl and htons calls in that code, whatever other problems it might have.
Post: #5OneSadCookie 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...
Post: #7BinarySpike 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!
Post: #8akb825 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...
Post: #9
Sorry, I thought "raw sockets" meant using sockets directly. 
Be careful, though: according to Wikipedia, raw sockets are limited under Windows. (in case you want Windows compatibility)
Be careful, though: according to Wikipedia, raw sockets are limited under Windows. (in case you want Windows compatibility)
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?
Post: #12Steve 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
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
Post: #13BinarySpike 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...)
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)
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?
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.
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.
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| Connect to Server from Iphone | BugSniper | 6 | 8,165 |
Jul 15, 2009 04:57 PM Last Post: BugSniper |
|
| Cocoa/Objective-C and TCP Sockets... | TimMcD | 2 | 5,368 |
Jun 13, 2009 06:15 PM Last Post: TimMcD |
|
| Server/database interaction in C++ using sockets | wyrmmage | 2 | 4,749 |
Jan 20, 2007 02:17 PM Last Post: wyrmmage |
|
| Using threads to set a timeout on a connect() call | SOUR-Monkey | 6 | 6,697 |
Feb 13, 2005 09:59 PM Last Post: ggadwa |
|