Direct packet socket programming?

Can RISC OS do this?

#include <stdio.h>
#include <socklib.h>
#include <inetlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netdb.h>
#include <errno.h>


int hdl = -1;
int on = 1;

int main(void)
{
   char packet[256];
   struct sockaddr address;

   hdl = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); // need AF_PACKET!!!
   if (hdl < 0)
   {
      printf("Error opening socket\n");
      return 1;
   }

   on = 1;
   if ( setsockopt(hdl, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on)) < 0 )
   {
      printf("Error setting header included\n");
      return 2;
   }
   printf("Header included setting okay.\n");

   packet[ 0] = 0xFF;  // origin MAC address
   packet[ 1] = 0xFF;
   packet[ 2] = 0xFF;
   packet[ 3] = 0xFF;
   packet[ 4] = 0xFF;
   packet[ 5] = 0xFF;

   packet[ 6] = 0xB8;  // our MAC address
   packet[ 7] = 0x27;
   packet[ 8] = 0xEB;
   packet[ 9] = 0xD9;
   packet[10] = 0xE9;
   packet[11] = 0x22;

   packet[13] = 0x88; // ctrl - Ethernet_II
   packet[14] = 0x88;

   packet[15] = 0x00; // payload
   packet[16] = 0x01;

   packet[17] = 0xDE; // Ought to appear in payload and be visible
   packet[18] = 0xAD; // to WireShark on the other side...
   packet[19] = 0xBA;
   packet[20] = 0xBE;
                      // followed by some 'random' data
                      // (whatever is in packet array after...)

   on = sendto(hdl, packet, 64, 0, (struct sockaddr *)&address, (sizeof(address)));
   printf("Reply from sendto() was %d\n", on);

   // This will CRASH.
   // I need a call to say "transmit THIS (exactly) and stop farting around".
   // Help?

   socketclose(hdl);

   return 0;
}

Do not try this – it crashes. If you take out the request to include headers (the HDRINCL bit), it will spit out a packet that has a standard-looking IP header apparently with some data being an ARP request to locate 192.168.1.1 (according to WireShark). None of the identifying data in the payload is present, whatever is sent is something else.
If you leave the include-headers request and patch in a valid IP header (by adding struct ip *iph = (struct ip *)packet; followed by a lot of iph->blah = value; lines prior to the sendto call), it will send a standard-looking IP header with who-knows-what data, as above.

I need to use AF_PACKET. This doesn’t appear to be supported by RISC OS. I suspect the IP header is added because I am using AF_INET, but then, no other AF option seems to want to open a socket in raw mode. Trust me, I’ve tried ’em ALL. Boring! ;-)

What I want to appear on the wire is this:

ff ff ff ff ff ff 00 23   54 0b 01 1a 88 88 00 00
00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00

and receive something very similar.

In all cases, the first six bytes are the MAC address of the receiver (all ff = broadcast), and the next six bytes are the MAC address of the sender. The next two bytes are always &88 &88, then follows data.

The reply to the above would be:

00 23 54 0B 01 1A 00 17   13 14 12 3A 88 88 00 00
[.data data (16 bytes more than sent) data data.]

The communication works like that. No IP addresses or any of that high-level stuff.

Can RISC OS do this?

What I want to appear on the wire is this:
ff ff ff ff ff ff 00 23 54 0b 01 1a 88 88 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Hmmm? ARP is ethertype 0806

and receive something very similar.

broken?

In all cases, the first six bytes are the MAC address of the receiver (all ff = broadcast),
and the next six bytes are the MAC address of the sender.

yup.

The next two bytes are always &88 &88, then follows data.

No, sorry, checked a few references rather than the memory and the reference to ethertype 8888 says protocol unavailable http://standards.ieee.org/develop/regauth/ethertype/eth.txt

http://wiki.wireshark.org/SampleCaptures will give you decent example captures

Rick:
what you should be sending for an ARP

packet[ 0] = 0xFF;  // target MAC address
packet[ 1] = 0xFF;
packet[ 2] = 0xFF;
packet[ 3] = 0xFF;
packet[ 4] = 0xFF;
packet[ 5] = 0xFF;
packet[ 6] = 0xB8;  // our MAC address
packet[ 7] = 0x27;
packet[ 8] = 0xEB;
packet[ 9] = 0xD9;
packet[10] = 0xE9;
packet[11] = 0x22;
packet[13] = 0x08; // ctrl - Ethernet_II
packet[14] = 0x06;
packet[15] = 0x00; // hardware type = ethernet
packet[16] = 0x01; // 
packet[17] = 0x08; // protocol type = IP
packet[18] = 0x00; //
packet[19] = 0x06; // hw size
packet[20] = 0x04; // protocol size
packet[21] = 0x00; // request start
packet[22] = 0x01; //
packet[23] = 0xb8; // 6 byte sender MAC
packet[24] = 0x27; 
packet[25] = 0xeb; 
packet[26] = 0xd9; 
packet[27] = 0xe9; 
packet[28] = 0x22; 
packet[29] = 0xc0; // 4 byte hex version of sender IP 
packet[30] = 0xa8; // using 192.168.1.2 in this
packet[31] = 0x01; 
packet[32] = 0x02; 
packet[33] = 0x00; // 6 byte target MAC
packet[34] = 0x00; 
packet[35] = 0x00; 
packet[36] = 0x00; 
packet[37] = 0x00; 
packet[38] = 0x00; 
packet[39] = 0xc0; // 4 byte hex version of target IP
packet[40] = 0xa8; // using 192.168.1.1 in this
packet[41] = 0x01; 
packet[42] = 0x01; 

Now back to planning the swap of this to this

Edit: note the nice 42 bytes on the wire (which is a message you will see in the Wireshark panel…)

and receive something very similar.
broken?

Custom. Unfortunately.

No, sorry, checked a few references rather than the memory and the reference to ethertype 8888 says protocol unavailable

No, sorry, I have a capture of an entire transaction between my PC and the device I want to use with RISC OS. It uses exactly this (non-standard) protocol.

It looks to me as if this may work – http://en.wikipedia.org/wiki/Ethernet_frame#Ethernet_II – by simply setting the EtherType bytes to 88 88. I’m guessing the short preamble/start-frame is not shown by WireShark?

Can RISC OS’s internet stack send/receive Ethernet II frames?

will give you decent example captures

Want to see my capture? It is exactly as described. ;-)

I need to use AF_PACKET. This doesn’t appear to be supported by RISC OS. I suspect the IP header is added because I am using AF_INET, but then, no other AF option seems to want to open a socket in raw mode.

AF_PACKET, I believe, is the Linux synonym for AF_LINK which would be what BSD and therefore RISC OS uses. Even so, I’m reasonably sure AF_LINK isn’t what you want either as that’s for configuring or retrieving configuration information about the link layer – things like the driver name, the media type, etc.

The basic stumbling block here is you’re trying to open a socket (which is handled by the Internet module, a handler of IP) and send something that’s not IP, and that’s never going to work. Now, it’s certainly possible to do what you want – after all that’s what the Internet module must do when it wants to send a packet.

Ignoring address resolution and routing for a moment, Internet maintains a list of DCI4 drivers that have declared themselves on the system, and then registers filters with them to hook out packets of interest for itself. *ExINFO (where ‘x’ is the driver) will normally give a listing of the registered filters – one of those will be the Internet module itself.

To send raw packets you’ll need to enumerate the DCI4 drivers (or, if you’re a module, you could listen for the service call when one starts like Internet does) pick whichever one you fancy and use the DCI4 transmit SWI to send the raw packet.

To receive raw packets you’ll need to register a filter using the DCI4 filter SWI, if it’s always &8888 then a specific one, or IEEE filter if it’s not EthernetII, pick it off with the sink filter, or be rude and use a monitor filter so nobody else gets any packets at all.