to all who are interested: the problem was that hping3 use raw socket, and a raw socket isn't handled by kernel stack protocol!! (in fact, with netcat it's all ok) On Thu, Sep 9, 2010 at 6:50 PM, Nicola Padovano <nicola.padovano@xxxxxxxxx> wrote: > Hi guys! I've two (and..too) big problems. > > What I want is only get packet information in the way showed below > > -----CODE---- > this is my code (new target extension) > > [CODE] > ... > tcp_header = skb_transport_header(skb); > ip_header = skb_network_header(skb); > eth_header = skb_mac_header(skb); > > printk(KERN_INFO "xt_TAR-----> data : %p\n",skb->data); > printk(KERN_INFO "xt_TAR-----> tail : %p\n",skb->tail); > printk(KERN_INFO "xt_TAR-----> mac header: %p\n",eth_header); > printk(KERN_INFO "xt_TAR-----> ip header: %p\n",ip_header); > printk(KERN_INFO "xt_TAR-----> tcp header: %p\n",tcp_header); > printk(KERN_INFO "xt_TAR-----> id: %d\n",ntohs(ip_header->id)); > ... > [/CODE] > > --------FIRST PROBLEM------- > Let's suppose i digit this iptables line > > [IPTABLES_FIRST] > iptables -A OUTPUT -d www.google.it -j TAR > #where TAR is my target > [/IPTABLES_FIRST] > > then i use hping in this way: > > [HPING_FIRST] > hping3 -c 1 -d 100 www.google.it > #i send only one tcp packet with 100bytes of data (+40 headers) to www.google.it > [/HPING_FIRST] > > this is the output: > > [OUTPUT_FIRST] > xt_TAR-----> sk_buff len: 140 > xt_TAR-----> data : f5df2850 > xt_TAR-----> tail : f5df28dc > xt_TAR-----> mac header: (null) > xt_TAR-----> ip header: f5df2850 > xt_TAR-----> tcp header: f5df2850 > xt_TAR-----> id: 11733 > [/OUTPUT_FIRST] > > the id flag is the right one because i've checked it with wireshark, > so this is right packet. > But, as i said in the last mail, tcp and ip header have the same > value! why? i'm on the output path and i should have the transport > header's right value > Note: mac header is, rightly, pointing to null (in the output path, we > have catch the packet before that it is processed by layer2 function) > > > -------SECOND PROBLEM------ > Now let's suppose i digit this iptables line > > [IPTABLES_SECOND] > iptables -A OUTPUT -d localhost -j TAR > #where TAR is my target, note: -d LOCALHOST > [/IPTABLES_SECOND] > > then i use hping in this way: > > [HPING_SECOND > hping3 -c 1 -d 100 localhost > #i send only one tcp packet with 100bytes of data (+40 headers) to > localhost (127.0.0.1) > [/HPING_SEND] > > now the output is: > > [OUTPUT_SECOND] > xt_TAR-----> sk_buff len: 40 > xt_TAR-----> data : c3ff3210 > xt_TAR-----> tail : c3ff3238 > xt_TAR-----> mac header: (null) > xt_TAR-----> ip header: c3ff3210 > xt_TAR-----> tcp header: c3ff3224 > xt_TAR-----> id: 0 > [OUTPUT_SECOND] > > damn! Note: > 1. the skbuff len is 40 bytes (remember that i've sent 140 > bytes=100data+40headers) > 2. id flag is 0 > this means (i've checked again with wireshark) that this isn't the > packet i've sent, but it's the response packet!!! > and, to futher complicate things, in this case the ip and tcp header > have the right values (their diff is 20 bytes, in fact ip header len > is 20 bytes) > > > solutions? > -- Nicola Padovano e-mail: nicola.padovano@xxxxxxxxx web: http://npadovano.altervista.org -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
