fragmented packet

fragmented packet

[Nicola Padovano]

Hi all! I'm write a simple netfilter module which recognize a fragmented packet.
First of all, i've used hping to send frag packet to my host (local
host), in particular i create only one packet (40 byte for default,
20bytes of header and 20 bytes of payload) specifying an MTU of 4
byte, so in this way i've to receive 5 packet (20bytes/4bytes of MTU).

So, this is the piece of code

[CODE]
#define FRAG_OFF(x) ntohs(x->frag_off) & IP_OFFSET
#define MORE_FRAG(x) ntohs(x->frag_off) & IP_MF
...
printk(KERN_INFO "sk_buff len: %d\n",skb->size);
...
struct iphdr *ip_header = (struct iphdr *)skb_network_header(skb);
...
if (FRAG_OFF || MORE_FRAG) {
   printk(KERN_INFO "!!!fragmented!!!\n");
   printk(KERN_INFO "frag off: %d\n",FRAG_OFF);
   printk(KERN_INFO "\n\n");
}
[/CODE]

then iptables (where TAR is my new target)
[IPTABLES]
iptables -t mangle -A PREROUTING -p tcp -s localhost -j TAR
[/IPTABLES]
(note: i use mangle table to have available PREROUTING hook, where the
packets are not yet defragmented)

so hpinging in this way (-c = packets' number, -m = mtu in byte)
[HPING]
hping -m 4 -c 1 localhost
[/HPING]

Now let's a look to output
[OUTPUT]
sk_buff len: 24
!!!fragmented!!!
frag off: 0

sk_buff len: 24
!!!fragmented!!!
frag off: 0

sk_buff len: 24
!!!fragmented!!!
frag off: 1

sk_buff len: 24
!!!fragmented!!!
frag off: 1

sk_buff len: 24
!!!fragmented!!!
frag off: 2
[/OUTPUT]

As you can see, there are two couples of frag with the same frag off:
the first and the second with 0 frag_off, then the third and the
fourth with 1 frag_off.
how is it possible?

Thank you guys!

-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: fragmented packet

[Jan Engelhardt]

On Saturday 2010-09-04 19:09, Nicola Padovano wrote:

>Hi all! I'm write a simple netfilter module which recognize a fragmented packet.

iptables -f? ip6tables -m frag? They already exist :)

>First of all, i've used hping to send frag packet to my host (local
>host), in particular i create only one packet (40 byte for default,
>20bytes of header and 20 bytes of payload) specifying an MTU of 4
>byte, so in this way i've to receive 5 packet (20bytes/4bytes of MTU).
>
>So, this is the piece of code
>
>[CODE]
>#define FRAG_OFF(x) ntohs(x->frag_off) & IP_OFFSET
>#define MORE_FRAG(x) ntohs(x->frag_off) & IP_MF
>...
>printk(KERN_INFO "sk_buff len: %d\n",skb->size);
>...
>struct iphdr *ip_header = (struct iphdr *)skb_network_header(skb);
>...
>if (FRAG_OFF || MORE_FRAG) {
>   printk(KERN_INFO "!!!fragmented!!!\n");
>   printk(KERN_INFO "frag off: %d\n",FRAG_OFF);
>   printk(KERN_INFO "\n\n");
>}
>[/CODE]
>
>then iptables (where TAR is my new target)
>[IPTABLES]
>iptables -t mangle -A PREROUTING -p tcp -s localhost -j TAR
>[/IPTABLES]
>(note: i use mangle table to have available PREROUTING hook, where the
>packets are not yet defragmented)

The mangle table does already receive defragmented packets (if defrag 
module is loaded).

Re: fragmented packet

[Nicola Padovano]

> iptables -f? ip6tables -m frag? They already exist :)

yes i know, but the mine is only an exercise...

> The mangle table does already receive defragmented packets (if defrag
> module is loaded).
>
i don't load the defrag module, so the packet is not you defragmented:
infact the output says "fragmented"...
the problem is: why there are some frag with the same frag off?


-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: fragmented packet

[Nicola Padovano]

(ps: i _suppose_ that i've not the defrag module because i've
"fragmented" message in my output: i've checked MF bit and fragment
offset field and they "say" to me that the packet is
fragmented...so...)

On Sat, Sep 4, 2010 at 8:31 PM, Nicola Padovano
<nicola.padovano@gmail.com> wrote:
>> iptables -f? ip6tables -m frag? They already exist :)
>
> yes i know, but the mine is only an exercise...
>
>> The mangle table does already receive defragmented packets (if defrag
>> module is loaded).
>>
> i don't load the defrag module, so the packet is not you defragmented:
> infact the output says "fragmented"...
> the problem is: why there are some frag with the same frag off?
>
>
> --
> Nicola Padovano
> e-mail: nicola.padovano@gmail.com
> web: http://npadovano.altervista.org
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: fragmented packet

[Jan Engelhardt]

On Saturday 2010-09-04 19:09, Nicola Padovano wrote:
>then iptables (where TAR is my new target)
>[IPTABLES]
>iptables -t mangle -A PREROUTING -p tcp -s localhost -j TAR
>[/IPTABLES]
>(note: i use mangle table to have available PREROUTING hook, where the
>packets are not yet defragmented)
>
>so hpinging in this way (-c = packets' number, -m = mtu in byte)
>[HPING]
>hping -m 4 -c 1 localhost
>[/HPING]

MTU=4 does not even make for a proper IPv4 packet, for which
the minimum reasonable MTU would be the IPv4 header size.
Plus perhaps at least part of the fragment, i.e. 24 octets.
God knows what happens if you use MTU=4.
An MTU of 4

>Now let's a look to output
>[OUTPUT]
>sk_buff len: 24
>!!!fragmented!!!
>frag off: 0
>
>sk_buff len: 24
>!!!fragmented!!!
>frag off: 0

This might be the reply.

>sk_buff len: 24
>!!!fragmented!!!
>frag off: 1
>
>sk_buff len: 24
>!!!fragmented!!!
>frag off: 1

Also reply.

>sk_buff len: 24
>!!!fragmented!!!
>frag off: 2

Input only, and empty fragment. You ought to check the packet size.

Re: fragmented packet

[Nicola Padovano]

> MTU=4 does not even make for a proper IPv4 packet, for which
> the minimum reasonable MTU would be the IPv4 header size.
the minimum size of ipv4 header is 20 bytes, the ethernet protocol use
mtu=16byte, so the sentence below is not valid (imho)...i can build a
layer2 protocol where the mtu is 4 bytes: IP protocol must be able to
work above my layer2

>>sk_buff len: 24
>>!!!fragmented!!!
>>frag off: 0
>>
>>sk_buff len: 24
>>!!!fragmented!!!
>>frag off: 0
>
> This might be the reply.
no, it is impossibile because i've no response with that line of hping
(i send only one packet, zero receive): infact the output is:
--- localhost hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
(0 received --- READ THE WHY BELOW )



> Input only, and empty fragment. You ought to check the packet size
the packet size is 40 bytes....


BELOW:
but...maybe i've found the "solution"...but i've to test it yet.
So: i've a 40 bytes packet, and a MTU of 4 byte. the payload size is
20 byte (because hping use the smaller ipheader: 20bytes). At this
point the fragment's number is -inevitably- 20/4 = 5. But, how can i
calculate the fragment offset?
In this way: the first packet has fragoff = 0, the second packet has
fragoff = size of the first fragment / 8 = 0!!! (rounded down), the
third packet has fragoff = (size of the first fragment+size of the
second fragment) / 8 = 1...
That's why i have no packet received, because i can't defragmented a
packet with some frags that have the same fragoff!
So in this way we have explained:
1. why i haven't receive a response packet
2. why i have the same fragoff

it's all ok, now.

what do you think Jan?

-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: fragmented packet

[Nicola Padovano]

i'm so sorry...i've said ethernet mtu=16bytes...........
i know, ethernet mtu = 1500bytes
but this doesn't chance the things...read the second part of last mail :)

Re: fragmented packet

[Changli Gao]

On Sun, Sep 5, 2010 at 5:45 PM, Nicola Padovano
<nicola.padovano@gmail.com> wrote:
> i'm so sorry...i've said ethernet mtu=16bytes...........

the minimal size of an ethernet frame is 60 bytes.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

Re: fragmented packet

[Jan Engelhardt]

On Sunday 2010-09-05 17:24, Changli Gao wrote:

>On Sun, Sep 5, 2010 at 5:45 PM, Nicola Padovano
><nicola.padovano@gmail.com> wrote:
>> i'm so sorry...i've said ethernet mtu=16bytes...........
>
>the minimal size of an ethernet frame is 60 bytes.

But loopback is not an ethernet device.

Re: fragmented packet

[Changli Gao]

On Sun, Sep 5, 2010 at 11:54 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Sunday 2010-09-05 17:24, Changli Gao wrote:
>
>>On Sun, Sep 5, 2010 at 5:45 PM, Nicola Padovano
>><nicola.padovano@gmail.com> wrote:
>>> i'm so sorry...i've said ethernet mtu=16bytes...........
>>
>>the minimal size of an ethernet frame is 60 bytes.
>
> But loopback is not an ethernet device.
>

But I don't think IP protocol can work with a MTU <= 20(sizeof(struct
iphdr)) can work. How can IP fragment/defragment works without a full
IP header.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

Re: fragmented packet

[Nicola Padovano]

the default value for mtu (in hping) is 16 bytes!!! what does it mean?
maybe hping (against the rfc) use the fragmentation on the IP
__payload__ and not on the whole IP packet...what do you think? you
can check this with wireshark!
in fact i typed this hping line:

hping -m 160 -d 140 -c 1 localhost

so we have a IP DATAGRAM size = 140data+20ipheader+20tcpheader > MTU=160

but there isn't fragmentation (check it with wireshark) but ip
datagram size is greater than mtu!

So why there isn't fragmentation? because (i suppose) the
fragmentation work only on the IP payload:
IP paylaod = 140data + 20tcpheader = 160 = MTU => no fragmentation!

what do you think? i'm pretty sure of what i say....

Re: fragmented packet

[Changli Gao]

On Mon, Sep 6, 2010 at 7:19 AM, Nicola Padovano
<nicola.padovano@gmail.com> wrote:
> the default value for mtu (in hping) is 16 bytes!!! what does it mean?
> maybe hping (against the rfc) use the fragmentation on the IP
> __payload__ and not on the whole IP packet...what do you think? you
> can check this with wireshark!
> in fact i typed this hping line:
>
> hping -m 160 -d 140 -c 1 localhost

Since you use hping, I think it has noting to do with the kernel.
Hping fragments packets in user space other than kernel space.

>
> so we have a IP DATAGRAM size = 140data+20ipheader+20tcpheader > MTU=160
>
> but there isn't fragmentation (check it with wireshark) but ip
> datagram size is greater than mtu!
>
> So why there isn't fragmentation? because (i suppose) the
> fragmentation work only on the IP payload:
> IP paylaod = 140data + 20tcpheader = 160 = MTU => no fragmentation!

Fragmentation is in IP layer. sizeof(ip packet) <= MTU. In your case,
140data + 20ipheader = 160 = MTU => no fragmentation.

>
> what do you think? i'm pretty sure of what i say....
>



-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

Re: fragmented packet

[Nicola Padovano]

those 140 bytes are the __tcp payload__ so the payload of IP is: Ip
header +TCP payload = 180...
isn't it?

On Mon, Sep 6, 2010 at 1:47 AM, Changli Gao <xiaosuo@gmail.com> wrote:
> On Mon, Sep 6, 2010 at 7:19 AM, Nicola Padovano
> <nicola.padovano@gmail.com> wrote:
>> the default value for mtu (in hping) is 16 bytes!!! what does it mean?
>> maybe hping (against the rfc) use the fragmentation on the IP
>> __payload__ and not on the whole IP packet...what do you think? you
>> can check this with wireshark!
>> in fact i typed this hping line:
>>
>> hping -m 160 -d 140 -c 1 localhost
>
> Since you use hping, I think it has noting to do with the kernel.
> Hping fragments packets in user space other than kernel space.
>
>>
>> so we have a IP DATAGRAM size = 140data+20ipheader+20tcpheader > MTU=160
>>
>> but there isn't fragmentation (check it with wireshark) but ip
>> datagram size is greater than mtu!
>>
>> So why there isn't fragmentation? because (i suppose) the
>> fragmentation work only on the IP payload:
>> IP paylaod = 140data + 20tcpheader = 160 = MTU => no fragmentation!
>
> Fragmentation is in IP layer. sizeof(ip packet) <= MTU. In your case,
> 140data + 20ipheader = 160 = MTU => no fragmentation.
>
>>
>> what do you think? i'm pretty sure of what i say....
>>
>
>
>
> --
> Regards,
> Changli Gao(xiaosuo@gmail.com)
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: fragmented packet

[Changli Gao]

On Mon, Sep 6, 2010 at 8:04 AM, Nicola Padovano
<nicola.padovano@gmail.com> wrote:
> those 140 bytes are the __tcp payload__ so the payload of IP is: Ip
> header +TCP payload = 180...
> isn't it?

After checking the code of hping, I find the 'mtu' parameter of hping
is the payload of a IP packet.

So the packet you captured should be 20iphdr + 20tcphdr + 140data,
20tcphdr + 140data == 160("mtu" of hping), no fragmentation is needed.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

Re: fragmented packet

[Nicola Padovano]

Sorry, discard last mail...
those 140 bytes are the __TCP PAYLOAD__ (check it with wireshark) so
the datagram ip size is: IP HEADER + TCP HEADER + TCP PAYLOAD =
140+20+20=180...isn't it?

On Mon, Sep 6, 2010 at 2:04 AM, Nicola Padovano
<nicola.padovano@gmail.com> wrote:
> those 140 bytes are the __tcp payload__ so the payload of IP is: Ip
> header +TCP payload = 180...
> isn't it?
>
> On Mon, Sep 6, 2010 at 1:47 AM, Changli Gao <xiaosuo@gmail.com> wrote:
>> On Mon, Sep 6, 2010 at 7:19 AM, Nicola Padovano
>> <nicola.padovano@gmail.com> wrote:
>>> the default value for mtu (in hping) is 16 bytes!!! what does it mean?
>>> maybe hping (against the rfc) use the fragmentation on the IP
>>> __payload__ and not on the whole IP packet...what do you think? you
>>> can check this with wireshark!
>>> in fact i typed this hping line:
>>>
>>> hping -m 160 -d 140 -c 1 localhost
>>
>> Since you use hping, I think it has noting to do with the kernel.
>> Hping fragments packets in user space other than kernel space.
>>
>>>
>>> so we have a IP DATAGRAM size = 140data+20ipheader+20tcpheader > MTU=160
>>>
>>> but there isn't fragmentation (check it with wireshark) but ip
>>> datagram size is greater than mtu!
>>>
>>> So why there isn't fragmentation? because (i suppose) the
>>> fragmentation work only on the IP payload:
>>> IP paylaod = 140data + 20tcpheader = 160 = MTU => no fragmentation!
>>
>> Fragmentation is in IP layer. sizeof(ip packet) <= MTU. In your case,
>> 140data + 20ipheader = 160 = MTU => no fragmentation.
>>
>>>
>>> what do you think? i'm pretty sure of what i say....
>>>
>>
>>
>>
>> --
>> Regards,
>> Changli Gao(xiaosuo@gmail.com)
>>
>
>
>
> --
> Nicola Padovano
> e-mail: nicola.padovano@gmail.com
> web: http://npadovano.altervista.org
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

Re: fragmented packet

[Jan Engelhardt]

On Monday 2010-09-06 02:10, Nicola Padovano wrote:

>Sorry, discard last mail...
>those 140 bytes are the __TCP PAYLOAD__ (check it with wireshark) so
>the datagram ip size is: IP HEADER + TCP HEADER + TCP PAYLOAD =
>140+20+20=180...isn't it?


I suggest to just use plain ping -s $((MTU-8-20)).

Re: fragmented packet

[Nicola Padovano]

hi changli, the file is sendip_handler.c....but what's the line code
where you see that ''mtu'' is only the payload?
(i'm sure that it is so, but i wanna see it from source code!)

On Mon, Sep 6, 2010 at 2:09 AM, Changli Gao <xiaosuo@gmail.com> wrote:
> On Mon, Sep 6, 2010 at 8:04 AM, Nicola Padovano
> <nicola.padovano@gmail.com> wrote:
>> those 140 bytes are the __tcp payload__ so the payload of IP is: Ip
>> header +TCP payload = 180...
>> isn't it?
>
> After checking the code of hping, I find the 'mtu' parameter of hping
> is the payload of a IP packet.
>
> So the packet you captured should be 20iphdr + 20tcphdr + 140data,
> 20tcphdr + 140data == 160("mtu" of hping), no fragmentation is needed.
>
> --
> Regards,
> Changli Gao(xiaosuo@gmail.com)
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org