Steven Wrote: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)

Just tried, I put it on lo0 using MacSniffer, whenever I tried "sudo ./throw" stuff appeared, but when I did "sudo -s" and then tried nothing appeared, so simply speaking, localhost packets are being sent when I sudo, and ./throw isn't throwing anything...

Zekaric Wrote: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.

I see, I revised my code to to put *all* unsigned shorts and longs in correct order, I didn't know what to do about the 4 bit variables, or the chars (cause the chars and one byte they shouldn't be ordered specially...)

unknown Wrote:'SYN's can be blindly spoofed'
what the heck are you doing, and does this work on mac os x?

Idk what a SYN is... but that was left over from some code I grabbed...
(which I based this version off of)

*edit*
PowerPC runs big endian *and* little endian... idk how exactly this all fits together but that is what the source said (aka, OSC was right)

MacSniffer running off lo0 saw the packets just fine without the DONTROUTE setting.
(Go MacSniffer!)
*/edit*

Success!

I looked up the SYN spoofing thing... kinda scary

So anyway, I found a great resource (old e-mail to a linux community) and finally figured out the headers required to work it all, but the major thing that both I and the old e-mail had in common, is that they didn't work till we added the bind function.

I also found the IP headers... for future reference here's a list of headers and why they are required.

I haven't tested the headers netinet/tcp.h or netinet/udp.h
tcp.h should have the TCP header struct and udp.h should have the UDP header struct... I have not tested to see what other headers they require...

on mac you only need include libstdc++

Please note this is as of 10.2.8, dev tools... I haven't upgraded any of my netinet so far, if I find source code to update my sockets stuff I would gladly upgrade

As akb825 nearly says, little-endian mode was an optional feature of PowerPC processors, could only be switched to by a privileged process, and wasn't quite full-featured, IIRC -- some instructions weren't available in little-endian mode or something. G3s and G4s had it, G5s didn't.

IOW, you can basically ignore the idea that PowerPCs are little-endian. For all intents and purposes, they're always big-endian.

Raw sockets are *only* useful for implementing things like ICMP pingers and port scanners. If you're fighting with them out of some misplaced idea that you can somehow write a better UDP stack than Apple it's time to get realistic

Of course, if you're just messing with them because you think they're cool and want to know how they work, fine

OneSadCookie Wrote:Raw sockets are *only* useful for implementing things like ICMP pingers and port scanners. If you're fighting with them out of some misplaced idea that you can somehow write a better UDP stack than Apple it's time to get realistic

Of course, if you're just messing with them because you think they're cool and want to know how they work, fine

Exactly
No use using something I don't know how it works

for example, I had no clue why connect, listen, or accept were required... it was just soooo complicated, then I learned it's part of the proccess of getting a connection and requires many behind the scenes packets.

Steven Wrote:Correct me if I'm wrong, but isn't the port a property of the TCP or UDP packet? (Ex: port makes no sense on an ICMP packet?)

Therefore, binding to a specific port on a raw socket makes no sense?

That's the problem if I didn't bind the packets, it wouldn't work
sendto would not register in either en0 or lo0 on tcpdump (I'm using MacSniffer)

Unknown Wrote:To be honest I think you should just save yourself a huge amount of bother and use TCP/UDP instead of IP. There is really no advantage to filling in your own TCP headers in any normal situation.

I understand that, and I would rather use something like HawkNL or raknet to run my networking (or SDL_net). I'm making this a requirement of myself to run a working raw sockets program.

I re-wrote everything from scratch, this *should* work... but it doesn't...
I'm not pressing anybody to take a look, but I will say, it's super organized...http://pastebin.ca/209566

Quote:for example, I had no clue why connect, listen, or accept were required... it was just soooo complicated, then I learned it's part of the proccess of getting a connection and requires many behind the scenes packets.

If you don't understand the purpose of listen, connect and accept, your chances of understanding it by writing raw sockets code is slim. That's like not understanding how a C if statement works, and learning assembler to find out.

Go get a good basic network programming book. Get several. Study the code of others.