views:

40

answers:

1

Long story short, I am trying to build a very bare bones UDP SKB just to get something onto the wire. The scenario is as follows:

I have a kernel module loading that (among other things) overrides the memory location of the standard udp_sendmsg function in /net/ipv4/udp.c. From here I would like to construct an skb to the point where I can simply put it onto the wire. Normally, udp_sendmsg simply does a little UDP bookkeeping, tacks on a UDP header and sends it down to the IP layer for routing, L3/L2 headers etc. Basically I am bringing some of that functionality up into the sendmsg function. At this time, I am just allocating an skb:

    skb = alloc_skb(1500, GFP_KERNEL);
    //skb has 1500 bytes of tail room only
    skb_reserve(skb, 500);
    //now has head and tail but no data space
    data = skb_put(skb, 500);
    //now we have an skb with 500 head, 500 data sec, 500 tail

And then (after some route table seteup) I am trying to add a udp_hdr:

    struct udphdr *uh;
    skb->transport_header = skb_push(skb, sizeof(struct udphdr));
    uh = udp_hdr(skb);
    uh->source = 5555;
    uh->dest = dport;
    uh->len =  18;
    uh->check = 0;

and an ip_hdr (only the basics filled):

    struct iphdr *iph;
    skb->network_header = skb_push(skb, sizeof(struct iphdr));
    iph = ip_hdr(skb);
    iph->version = 4;
    iph->ihl = 5;
    iph->tos = inet->tos;
    iph->tot_len = htons(skb->len);
    iph->protocol = IPPROTO_UDP;
    iph->saddr = saddr;
    iph->daddr = daddr;
    skb->dst = dst_clone(&rt->u.dst);

Note: I got most of this stuff from this page but they are using an older kernel (pre 2.6.24) where the network and transport headers were unions and called nh and h respectively. The new way involves using skb->transport_header / skb->network_header and using these helper functions but apparently I am doing something wrong because I get a kernel oops when I try to invoke the udp_sendmsg

Note: this ran without an oops and dumped junk to the wire when instead of:

 skb->transport_header = skb_push(skb, sizeof(struct udphdr));

I used:

skb_reset_transport_header(skb);

(and equivalent for network_header. But after reading the link above and looking at the source for the reset function in linux/sk_buff.h, it didn't seem like it was doing what I wanted.

Please also note that any assignment statement above with (in this context) undefined variables is simply because I didn't include the entire function.

I realize this question might fall into a very specific domain but any guidance on correct usage of the newer skb construction would be greatly helpful. My buddy google is coming up pretty dry.

The Oops Call Trace:

 [<ffffffff813dbf98>] oops_end+0xb9/0xc1
 [<ffffffff81030e21>] no_context+0x1f6/0x205
 [<ffffffff81030fd3>] __bad_area_nosemaphore+0x1a3/0x1c9
 [<ffffffff8101184e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff8103100c>] bad_area_nosemaphore+0x13/0x15
 [<ffffffff813dd30a>] do_page_fault+0x125/0x222
 [<ffffffff813db485>] page_fault+0x25/0x30
 [<ffffffffa010924f>] ? udp_sendmsg_offload+0x1e3/0x250 [testmodule]
 [<ffffffffa010922e>] ? udp_sendmsg_offload+0x1c2/0x250 [testmodule]
 [<ffffffff81390a00>] inet_sendmsg+0x54/0x5d
 [<ffffffff8132f142>] __sock_sendmsg+0x61/0x6c
 [<ffffffff8132f8b9>] sock_sendmsg+0xcc/0xe5
+1  A: 

skb_push() returns a pointer to the transport header, but skb->transport_header is a sk_buff_data_t, which is supposed to be an offset - see how skb_transport_header() works. You also need to convert the header information into network byte order.

The part where you set the UDP header should be:

struct udphdr *uh;
skb_push(skb, sizeof(struct udphdr));
skb_reset_transport_header(skb);
uh = udp_hdr(skb);
uh->source = __constant_htons(5555);
/* ... */

and similarly for the IP header:

struct iphdr *iph;
skb_push(skb, sizeof(struct iphdr));
skb_reset_network_header(skb);
iph = ip_hdr(skb);
iph->version = 4;
/* ... */
caf
Yep I agree. I ran into that yesterday when looking at skbuff that the use of the skb->transport_header depends on NET_SKBUFF_DATA_USES_OFFSET which in turn depends on __WORDSIZE. Since I am on a 64 bit platform, it would seem that the preprocessor is indeed using this method. Also thank you for pointing out the byte order, After hacking that bit in I totally forgot
agent0range
PS this gets around the kernel oops (at least where it was happening before) but I am still having no luck with my goal. I suppose that is for another posting though.
agent0range