Hello,

I have written a code to send raw data using PF_PACKET to an interface.
Before, on FC4, I was able to see the packets sent using tcpdump.
However, using the same code on Ubuntu , I5.10 cannot capture the
message send. Maybe I have to enable some special options in TCPDUMP?
I have tried on both, wireless and regular ethernet activated
interfaces, but still getting the same results. Please let me know what
do you think.

#include <stdio.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <net/if.h>
#include <netpacket/packet.h>
#include <net/ethernet.h>
#include <string.h>
#include <netinet/in.h>
#include <unistd.h>

int main( void )
{
struct sockaddr_ll sll;
struct ifreq ifreq;
int fd;
char *string = "--- Message Text ---";

memset(&sll, 0, sizeof sll);
sll.sll_family = PF_PACKET;
sll.sll_protocol = htons (ETH_P_ALL);
sll.sll_ifindex = 4;

fd = socket (PF_PACKET, SOCK_RAW, htons (ETH_P_ALL));
strcpy (ifreq.ifr_name, "eth0");
ioctl (fd, SIOCGIFINDEX, &ifreq);
sll.sll_ifindex = ifreq.ifr_ifindex;
bind (fd, (struct sockaddr *) &sll, sizeof sll);

while(1)
{
sleep(1);
write (fd, string, strlen (string));
}

return 0;
}

[ Post a follow-up to this message ]

I am only getting packets like these:

~$ sudo tcpdump
Password:
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:20:42.210899 IP 192.168.2.110.54663 > ...msgr.hotmail.com.1863: P
1623852837:1623852842(5) ack 3665126600 win 2258 <nop,nop,timestamp
26514564 22075996>

bobrics wrote:
> Hello,
>
> I have written a code to send raw data using PF_PACKET to an interface.
> Before, on FC4, I was able to see the packets sent using tcpdump.
> However, using the same code on Ubuntu , I5.10 cannot capture the
> message send. Maybe I have to enable some special options in TCPDUMP?
> I have tried on both, wireless and regular ethernet activated
> interfaces, but still getting the same results. Please let me know what
> do you think.
>
> #include <stdio.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <netpacket/packet.h>
> #include <net/ethernet.h>
> #include <string.h>
> #include <netinet/in.h>
> #include <unistd.h>
>
> int main( void )
> {
>   struct sockaddr_ll sll;
>   struct ifreq ifreq;
>   int fd;
>   char *string = "--- Message Text ---";
>
>   memset(&sll, 0, sizeof sll);
>   sll.sll_family = PF_PACKET;
>   sll.sll_protocol = htons (ETH_P_ALL);
>   sll.sll_ifindex = 4;
>
>   fd = socket (PF_PACKET, SOCK_RAW, htons (ETH_P_ALL));
>   strcpy (ifreq.ifr_name, "eth0");
>   ioctl (fd, SIOCGIFINDEX, &ifreq);
>   sll.sll_ifindex = ifreq.ifr_ifindex;
>   bind (fd, (struct sockaddr *) &sll, sizeof sll);
>
>   while(1)
>   {
>     sleep(1);
>     write (fd, string, strlen (string));
>   }
>
>   return 0;
> }

[ Post a follow-up to this message ]

bobrics wrote:
> Hello,
>
> I have written a code to send raw data using PF_PACKET to an interface.
> Before, on FC4, I was able to see the packets sent using tcpdump.
> However, using the same code on Ubuntu , I5.10 cannot capture the
> message send. Maybe I have to enable some special options in TCPDUMP?
> I have tried on both, wireless and regular ethernet activated
> interfaces, but still getting the same results. Please let me know what
> do you think.
For what it's worth, use the pcap library for packet capturing,
it's quite portable and easy to use. (and also what tcpdump uses)

[ Post a follow-up to this message ]

bobrics wrote:
> Hello,
>
> I have written a code to send raw data using PF_PACKET to an interface.
> Before, on FC4, I was able to see the packets sent using tcpdump.
> However, using the same code on Ubuntu , I5.10 cannot capture the
> message send. Maybe I have to enable some special options in TCPDUMP?
> I have tried on both, wireless and regular ethernet activated
> interfaces, but still getting the same results. Please let me know what
> do you think.

If you want tcpdump to make sense of your packets, you need to prepend
them with protocol headers (i.e. ethernet headers and perhaps IP
headers, if they are IP packets).

Robert
>
> #include <stdio.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <netpacket/packet.h>
> #include <net/ethernet.h>
> #include <string.h>
> #include <netinet/in.h>
> #include <unistd.h>
>
> int main( void )
> {
>   struct sockaddr_ll sll;
>   struct ifreq ifreq;
>   int fd;
>   char *string = "--- Message Text ---";
>
>   memset(&sll, 0, sizeof sll);
>   sll.sll_family = PF_PACKET;
>   sll.sll_protocol = htons (ETH_P_ALL);
>   sll.sll_ifindex = 4;
>
>   fd = socket (PF_PACKET, SOCK_RAW, htons (ETH_P_ALL));
>   strcpy (ifreq.ifr_name, "eth0");
>   ioctl (fd, SIOCGIFINDEX, &ifreq);
>   sll.sll_ifindex = ifreq.ifr_ifindex;
>   bind (fd, (struct sockaddr *) &sll, sizeof sll);
>
>   while(1)
>   {
>     sleep(1);
>     write (fd, string, strlen (string));
>   }
>
>   return 0;
> }
>

[ Post a follow-up to this message ]

What I need is to write my own protocol for the link layer, so I do not
care about TCP/IP headers. Before, I was able to send my own
information to an interface, and the headers were completely
overwritten by my data, and I was able to see that using tcp dump on
FC4. Maybe it has something to do with listening in promiscuous mode?

Thank you

Robert Harris wrote:
> bobrics wrote: 
>
> If you want tcpdump to make sense of your packets, you need to prepend
> them with protocol headers (i.e. ethernet headers and perhaps IP
> headers, if they are IP packets).
>
> Robert

[ Post a follow-up to this message ]

bobrics wrote:
> What I need is to write my own protocol for the link layer, so I do not
> care about TCP/IP headers. Before, I was able to send my own
> information to an interface, and the headers were completely
> overwritten by my data, and I was able to see that using tcp dump on
> FC4. Maybe it has something to do with listening in promiscuous mode?

Yes, but if you don't use ethernet headers, other machines on the
network won't know whether the packets are for them or not. You are free
to invent your own ethernet type (i.e. the 13th and 14th bytes of the
ethernet header).

Robert

> [snip]

[ Post a follow-up to this message ]

My main idea was to control ethernet packets completely. The receiver
on the other side will listen to everything, including the garbage and
will try to make sense of it. So, it would probably understand my own
headers, even if they are ethernet. There's no hub in between, and I
can assume it'll be two directly connected transceivers. I want to find
out how can I take advantage of layer 2 and minimize the overhead to
measure the actual data transfer speeds.

1. To clarify, can I modify the ethernet headers when using a raw
socket? i.e. when I am defining it as socket (PF_PACKET, SOCK_RAW,
htons (ETH_P_ALL)); ?

2. Which option/function exactly gives the control of whether a user or
kernel will fill in the header? I would like to explore both of the
options: full user control, including the optional bytes 13 and 14; and
also the kernel option.

3. Also, when the packet is filled out by a kernel, can I still modify
these optional bytes 13 and 14?




> If you want tcpdump to make sense of your packets, you need to prepend
> them with protocol headers (i.e. ethernet headers and perhaps IP
> headers, if they are IP packets).

[ Post a follow-up to this message ]

I can assume here that between my TX and RX there's only one media - a
wire or equivalent, not known to either side, so any arrving frame is
intented for Rx. Also, I might not know the mac address of the Rx
module... it can be separated by a several chained ethernet devices...
so I cannot write the receiver's mac address into the ethernet header
of my frame directly (in other words, it's not on the same lan).
Here is my model:
Tx(eth0) --> intermediate(eth0) -->can be wire or point-to-point
optical link--> intermediate(eth0) --> Rx(eth0, promisuous mode)

Here, I have another question then. In order for the first intermediate
NIC in the chain to accept the packet from Tx and pass it on, does this
packet have to be ethernet type? It it would drop it otherwise, then I
have no choice but to use ethernet headers, or at least some fields
from it, like type, crc and destination mac address (which is address
of the first intermediate NIC).

Once the packet propagates through the chain and transmitted from the
last intermediate interface, Rx (set to promisuous mode) should capture
the packets and will take care of stripping them from the headers.

Thank you

Robert Harris wrote:[vbcol=seagreen]
> bobrics wrote: 
>
> Yes, but if you don't use ethernet headers, other machines on the
> network won't know whether the packets are for them or not. You are free
> to invent your own ethernet type (i.e. the 13th and 14th bytes of the
> ethernet header).
>
> Robert
> 

[ Post a follow-up to this message ]

I can assume here that between my TX and RX there's only one media - a
wire or equivalent, not known to either side, so any arrving frame is
intented for Rx. Also, I might not know the mac address of the Rx
module... it can be separated by a several chained ethernet devices...
so I cannot write the receiver's mac address into the ethernet header
of my frame directly (in other words, it's not on the same lan).
Here is my model:
Tx(eth0) --> intermediate(eth0) -->can be wire or point-to-point
optical link--> intermediate(eth0) --> Rx(eth0, promisuous mode)

Here, I have another question then. In order for the first intermediate
NIC in the chain to accept the packet from Tx and pass it on, does this
packet have to be ethernet type? It it would drop it otherwise, then I
have no choice but to use ethernet headers, or at least some fields
from it, like type, crc and destination mac address (which is address
of the first intermediate NIC).

Once the packet propagates through the chain and transmitted from the
last intermediate interface, Rx (set to promisuous mode) should capture
the packets and will take care of stripping them from the headers.

Thank you

Robert Harris wrote:[vbcol=seagreen]
> bobrics wrote: 
>
> Yes, but if you don't use ethernet headers, other machines on the
> network won't know whether the packets are for them or not. You are free
> to invent your own ethernet type (i.e. the 13th and 14th bytes of the
> ethernet header).
>
> Robert
> 

[ Post a follow-up to this message ]

bobrics wrote:
> I can assume here that between my TX and RX there's only one media - a
> wire or equivalent, not known to either side, so any arrving frame is
> intented for Rx. Also, I might not know the mac address of the Rx
> module... it can be separated by a several chained ethernet devices...
> so I cannot write the receiver's mac address into the ethernet header
> of my frame directly (in other words, it's not on the same lan).
> Here is my model:
> Tx(eth0) --> intermediate(eth0) -->can be wire or point-to-point
> optical link--> intermediate(eth0) --> Rx(eth0, promisuous mode)
>
> Here, I have another question then. In order for the first intermediate
> NIC in the chain to accept the packet from Tx and pass it on, does this
> packet have to be ethernet type? It it would drop it otherwise, then I
> have no choice but to use ethernet headers, or at least some fields
> from it, like type, crc and destination mac address (which is address
> of the first intermediate NIC).

There is nothing to stop you writing arbitrary bytes into an ethernet
packet and reading it in promiscuous mode at another NIC. But NICs
"know" about MAC addresses and if you encapsulate your messages with
ethernet headers at the start and CRCs at the end (which the NIC will
always calculate for you), then you can send a packet to a specific NIC
on your network just by putting its MAC address in the ethernet header.

As for an intermediate NIC passing a packet on, you need a routing
protocol for it to work. These days, most people use IP but you can use
anything you want or else invent your own.

Robert

>
> Once the packet propagates through the chain and transmitted from the
> last intermediate interface, Rx (set to promisuous mode) should capture
> the packets and will take care of stripping them from the headers.
>
> Thank you
>
> Robert Harris wrote: 
>

[ Post a follow-up to this message ]