Print MAC address from Ethernet header - c

I want to check the Ethernet header of packet that is porececed by iptables (1.4), so i need to write a module that catch packet and apply my function. I am looking for the mac destination value in the Ethernet header (just for test purpose), so the code should be like this:
static bool match(const struct sk_buff *skb, struct xt_action_param *par)
{
struct ethhdr *hdr;
hdr = eth_hdr(skb);
printk(KERN_INFO "hdr->h_dest 0x%x\n", hdr->h_dest);
printk(KERN_INFO "MACPROTO=%04x\n", hdr->h_proto);
The problem is that i cant get the correct value, i have some thing that is not even in the real frame (i checked that with Wireshark), so is it the right function to get Ethernet header attributs?
update:
i used the solution presented in the post, but still have wrong output, it's like if the structure point to wrong place
This image show result when i use nc to send "aaa" string, the ethernet header should be the same in the to frame, but as present in the result, it's not.

struct ethhdr is defined as such:
/*
* This is an Ethernet frame header.
*/
struct ethhdr {
unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
unsigned char h_source[ETH_ALEN]; /* source ether addr */
__be16 h_proto; /* packet type ID field */
} __attribute__((packed));
But your code is trying to print that byte array using %x:
printk(KERN_INFO "hdr->h_dest 0x%x\n", hdr->h_dest);
That makes no sense, and probably causes a compiler warning to be generated. This is kernel code - you are using -Werror and -Wall, right?
Good news: printk supports printing MAC addresses directly. From documentation/printk-formats.txt:
MAC/FDDI addresses:
%pM 00:01:02:03:04:05
%pMR 05:04:03:02:01:00
%pMF 00-01-02-03-04-05
%pm 000102030405
%pmR 050403020100
For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
specifiers result in a printed address with ('M') or without ('m') byte
separators. The default byte separator is the colon (':').
Where FDDI addresses are concerned the 'F' specifier can be used after
the 'M' specifier to use dash ('-') separators instead of the default
separator.
For Bluetooth addresses the 'R' specifier shall be used after the 'M'
specifier to use reversed byte order suitable for visual interpretation
of Bluetooth addresses which are in the little endian order.
Passed by reference.
So you can just use this:
printk(KERN_INFO "hdr->h_dest 0x%pM\n", hdr->h_dest);
These format specifiers are provided anywhere vsnprintf is used. Here's an example:
switch (dev->type) {
case ARPHRD_ETHER:
nf_log_buf_add(m, "MACSRC=%pM MACDST=%pM MACPROTO=%04x ",
eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest,
ntohs(eth_hdr(skb)->h_proto));
return;
default:
break;
}

Related

C creating a raw UDP packet

I am interested in creating a DNS (using UDP protocol to send it) response packet, however I found limited information how to create your own packet.
Most tutorials are like this https://opensourceforu.com/2015/03/a-guide-to-using-raw-sockets/
They use structs to fill in the fields and connect them into 1 sequence. But I am concerned that the compiler can pad the struct, making it "corrupted" (make the packet longer then it should be)
I fully know that there are struct attributes, that don't allow the compiler to pad structs, but I don't want to use them
Can anyone point me some resources on packet creation. I can use Libpcap and raw sockets
You do it like this:
// helper function to add uint32_t to a buffer
char *append_uint32(char *buf_position, uint32_t value) {
// network protocols usually use network byte order for numbers,
// htonl is POSIX function so you may have to make your own on other platform
// http://pubs.opengroup.org/onlinepubs/9699919799/functions/htonl.html
value = htonl(value);
memcpy(buf_postion, &value, sizeof value);
return buf_position + sizeof value;
}
// example code using the function:
// generate packet with numbers 0...9 in network byte order
void func() {
char buf[sizeof(int32_t) * 10];
char *bptr = buf;
for(uint32_t i=0; i<10; ++i) {
bptr = append_uint32(bptr, i);
}
// do something with buf (use malloc instead of stack if you want return it!)
}

Constructing a new IPv6 address from a Contiki uip address in C

I'm inexperienced with both Contiki and C but I'm trying to do the following:
Basically, I get a structure, event, which has a type, an id and a uip ip6address.
Using this event, I want to construct a uip ipv6 multicast address with a fixed prefix (ff1e).
At the moment I have the following code:
static uip_ds6_maddr_t *
derive_mcast_addr(struct eventstruc* event)
{
int ff1e;
//Fixed multicast prefix to be used by LooCI.
uint8_t mlcPrefix = ff1e;
//Type of the event
uint8_t eventType = event->type;
//Publisher Component ID of the sender
uint8_t * srccomp = event->source_cid;
// IPv6 address of the sender
uip_ip6addr_t * srcaddr = event->source_node);
// A derived multicast address is
// mlcPrefix + ":" + eventType + ":" +srccomp + ":0:" + (last 64bits srcAddr)
}
I'm unsure if this code is decent and on how to get the last 64 bits of the src address, especially since they might not be in the expected format.
For example, if the source address is 0::0:0:0:0 then I'd just need the 0:0:0:0 part. If it was, say, 2001::a00:27ff:fef7:30a7, I'd just need a00:27ff:fef7:30a7.
Also, there is the added complexity of Contiki uip...
Anybody have a decent idea?
First, your uint8_t variables are probably not wide enough, you might need:
//Fixed multicast prefix to be used by LooCI.
uint16_t mlcPrefix = 0xff1e;
I'm not familiar with Contiki, but based on this: http://dak664.github.io/contiki-doxygen/a00424_source.html uip_ip6addr_t is really this:
typedef union uip_ip6addr_t {
u8_t u8[16]; /* Initializer, must come first!!! */
u16_t u16[8];
} uip_ip6addr_t;
If that's the case, then you can get the lower 64 bits by looking at:
srcaddr->u16[4]
srcaddr->u16[5]
srcaddr->u16[6]
srcaddr->u16[7]
Or it could be indexes 0-3 depending on how things are stored in uip_ip6addr_t.
To put things back together, you can put your upper 64 bits in u16[0] through u16[3] and then put the original lower 64 bits back in u16[4] through u16[7].
If uip_ds6_maddr_t is this:
typedef struct uip_ds6_maddr {
uint8_t isused;
uip_ipaddr_t ipaddr;
} uip_ds6_maddr_t;
And you have a pointer uip_ds6_maddr_t *dst then you could do:
dst->ipaddr.u16[0] = mlcPrefix;
And so on.

Modify header of a captured packet

I am trying to modify the IP header to include more IP options with the use of the libnetfiletr_queue. So far I have managed to come to the point where I obtain the packet as shown below.
if (nfq_set_mode(qh, NFQNL_COPY_PACKET, 0xffff) < 0) {
fprintf(stderr, "Unable to set nfq_set_mode\n");
exit(1);
}
Then I managed to go far as shown below,
static int my_callBack(struct nfq_q_handle *qh, struct nfgenmsg *nfmsg,struct nfq_data *tb)
{
int id = 0;
int packet_len;
unsigned char *data;
struct nfqnl_msg_packet_hdr *packet_hdr;
unsigned char *data;
packet_hdr = nfq_get_msg_packet_hdr(tb);
if (packet_hdr) {
id = ntohl(packet_hdr->packet_id);
}
packet_len = nfq_get_payload(tb, &data);
if (packet_len >= 0) {
//print payload length
printf("payload_length = %d ", packet_len);
//modify packet ip header
}
return nfq_set_verdict(qh, id, NF_ACCEPT, 0, NULL);
}
But from here onwards I am a bit confused on how to proceed on modifying the IP header of the captured packet at //modify packet ip header comment.Example on a modification to the IP header (such as traffic class(IPV6)/ IP options/ version/ flags/ destination address) is ok since I only need to understand how the modification works :).
I have tried many resources and could not succeed in proceeding any further. You expert advice and help on this query will be very much appreciated. :)
Thank you very much :)
To modify the values of an IP header, start by defining a structure to represent your header. You find what the structure should be by reading the RFC spec for the protocol you're trying to access.
Here's a link to the RFC for IPv6: https://www.rfc-editor.org/rfc/rfc2460#section-3
The first row of the IPv6 header is a bit tricky, because they aren't using byte-aligned fields. The Version field is 4-bits wide, the Traffic Class is 8-bits wide, and the Flow Label is 20-bits wide. The whole header is 320 bits (40 bytes) and 256 of those are src and dest address. Only 64-bits are used for the other fields, so it's probably easiest to define your struct like this:
struct ipv6_hdr {
uint32_t row1;
uint16_t payload_length;
uint8_t next_header;
uint8_t hop_limit;
uint16_t src[8];
uint16_t dest[8];
};
To extract the row one values, you can use some masking:
#define VERSION_MASK 0xF0000000
#define TRAFFIC_CLASS_MASK 0x0FF00000
#define FLOW_LABEL_MASK 0x000FFFFF
struct ipv6_hdr foo;
...
nfq_get_payload(tb, &foo); // Just an example; don't overflow your buffer!
// bit-wise AND gets masked field from row1
uint8_t version = (uint8_t) ((foo->row1 & VERSION_MASK) >> 28); // shift (32-4) bits
Once you point your struct to the data payload, assuming your byte array matches this format, modifying the header values becomes simple assignment:
version = 6;
// bit-wise OR puts our value in the right place in row1
foo->row1 &= ~(VERSION_MASK) // clear out the old value first
foo->row1 = ((uint32_t) version << 28) | foo->row1;
I chose to make the src and dest addresses in the struct an array of 16-bit values because IPv6 addresses are a series of 8, 16-bit values. This should make it easy to isolate any given pair of bytes.
You will have to determine what format your data payload is in before applying the proper struct to it.
For info on how to create an IPv4 header, check its RFC: https://www.rfc-editor.org/rfc/rfc791#section-3.1
Hope this helps (you may have to fiddle with my code samples to get the syntax right, it's been a few months).
editing with info about checksums as requested in comments
Follow this RFC for generating checksums after modifying your header: https://www.rfc-editor.org/rfc/rfc1071
The key take-away there is to zero the checksum field in the header before generating the new checksum.

arp_send: what is the difference between target_hw and dest_hw?

I am trying to generate arp requests from within the kernel but I do not understand the difference between the 'target MAC address' and the 'destination MAC address'. The kernel function that I am using is this one:
void arp_send(int type, int ptype, __be32 dest_ip,
struct net_device *dev, __be32 src_ip,
const unsigned char *dest_hw, const unsigned char *src_hw,
const unsigned char *target_hw)
Does anyone know the difference between 'target_hw' (the target MAC address) and 'dst_hw' (the destination MAC address)? For me they should be the same...
The arp_send function is a generic one, used to send both ARP requests and responses.
In your case (ARP request) the target_hw is the information you want to learn, so this field can be ignored (set to NULL, see RFC826 example)
dest_hw will also be NULL - which will result in using broadcast address (see arp_create comment)
I'm assuming IPv4 over Ethernet here. For other Layer2/3 protocols it might look different.

Convert source IP address from struct iphdr* to string equivalent using Linux netfilter

I want to convert the source & destination IP addresses from a packet captured using netfilter to char *.
In my netfilter hook function, I have:
sock_buff = skb; // argument 2 of hook function
// ip_header is struct iphdr*
ip_header = (struct iphdr *)skb_network_header(sock_buff);
// now how to convert ip_header->saddr & ip_header->daddr to char *
// ip_header->saddr & ip_header->daddr are of type __be32
Thanks.
The kernel's family of printf() functions has a special format specifier for IP-addresses (%pI4 for IPv4-addresses, %pI6 for IPv6).
So with IPv4, you could use something like:
char source[16];
snprintf(source, 16, "%pI4", &ip_header->saddr); // Mind the &!
Or write to dynamically allocated memory.
If you simply want to print debug-output, you can also use printk(). For the many other features of %p, see this document.
Try in4_pton() function in net/core/utils.c (definition: https://elixir.bootlin.com/linux/latest/source/net/core/utils.c#L118)
#include <linux/inet.h>
char source[16];
in4_pton(source, -1, &ip_header->saddr, '\0', NULL);

Resources