Ick.. yes, writing things out of brain sometimes results in "I am an idiot"
You are right, IP header is different size, but you have to "pack them into ethernet"
Ethernet header is 14 bytes (2* MAC (6) + Type (2) = 14)
The IP header has 20 bytes .
ICMP has 8 bytes overhead
Results in 32 bytes ...
Was complicated to explain here, as I do not belive, that he direct spoke about the skb->buffer[] of the network card direct, as more about the buffer after IP_reassembly.
>1>in case of fragmention i am getting only one packet at the
>hook,While analyzing the ip header it says this is the assembled
>packet(skb->len=1528,offset=0,MF=0).
So my intention was, as I belived, that he wantet to know the internal handling buffer, which is indeed "payload + 28 (IP+ICMP)"
Sorry for making the mistake that IP is 24 bytes and icmp is 4 bytes. ( I am used to code with embedded IP stacks, and there the 24+4 rule is correct(not on all stacks), as you "hack" the icmp into the IP options field.
Information Request or Information Reply Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Franz
-----Ursprüngliche Nachricht-----
Von: linux-net-owner@xxxxxxxxxxxxxxx [mailto:linux-net-owner@xxxxxxxxxxxxxxx] Im Auftrag von Jeff Haran
Gesendet: Donnerstag, 8. März 2007 19:19
An: Lehner Franz; Kanhu Rauta; linux-net@xxxxxxxxxxxxxxx
Betreff: RE: IP Defragmentation
> -----Original Message-----
> From: linux-net-owner@xxxxxxxxxxxxxxx
> [mailto:linux-net-owner@xxxxxxxxxxxxxxx] On Behalf Of Lehner Franz
> Sent: Thursday, March 08, 2007 2:32 AM
> To: Kanhu Rauta; linux-net@xxxxxxxxxxxxxxx
> Subject: AW: IP Defragmentation
>
> Oh boy.
> In a "normal" ethernet environment, the MTU size of the
> ethernet is 1500.
> Means: the maximum packet size on the cable is 1500 bytes at one shot.
>
> As the ping packet and ANY other packet needs mac-address, ip
> adress ---
> -> in a default IPv4 header, the IP header has exactly 6*4 = 24 bytes.
I believe the default IPv4 header is 20 bytes. From RFC 791:
3.1. Internet Header Format
A summary of the contents of the internet header follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In a default IP header, there will be no options, thus the header ends at the Destination Address field.
Jeff Haran
Brocade
> The ICMP (ping) is a sub of IP, and has exactly 4 bytes for
> type, code and 16 bit chechsum Summary = 28 bytes.
>
> So sending a 1500 bytes big ping will always result when
> having a mtu size of 1500 on an ipv4 in 2 packets.
>
> Packet 1: 24+4+1472
> Packet 2: 24+4+28
>
> skb->data[] is the buffer coming from kernel, and is highly
> dependent on the MTU setting of the interface.
> (look to ifconfig)
> And this buffer is more the network buffer of the network
> card, and not a kernel buffer.
> Also, on most network cards with DMA and internal ram on the
> chip, the skb->data[] is not a real memory as more a IO
> mapping to the network card.
>
> Look to eg. A modern ethernet card
> http://lxr.linux.no/source/drivers/net/eepro100.c
>
> 1448 cpu_to_le32(pci_map_single(sp->pdev, skb->data,
> 1449 skb->len,
> PCI_DMA_TODEVICE));
> 1450 sp->tx_ring[entry].tx_buf_size0 = cpu_to_le32(skb->len);
>
>
> You should not mix the socket pipe with the network buffer
> for the card.
> Look to ping.c to see how socket is accessed.
>
> Franz
>
> -----Ursprüngliche Nachricht-----
> Von: linux-net-owner@xxxxxxxxxxxxxxx
> [mailto:linux-net-owner@xxxxxxxxxxxxxxx] Im Auftrag von Kanhu Rauta
> Gesendet: Donnerstag, 8. März 2007 07:16
> An: netfilter-devel@xxxxxxxxxxxxxxxxxxx;
> linux-net@xxxxxxxxxxxxxxx; kernelnewbies@xxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx
> Betreff: IP Defragmentation
>
> Hi list,
>
> I am using kernel 2.6.20.1. I have written a module,which
> will register a function at local_in hook, i have found a
> strange behavior with the packets getting in my callback function i.e
>
> [let say i am sending 1500 bytes to this machine from the
> network] ping -s 1500 <ip>
>
> 1>in case of fragmention i am getting only one packet at the
> hook,While analyzing the ip header it says this is the
> assembled packet(skb->len=1528,offset=0,MF=0).
>
> While dumping the data(for 0 to 1528 print skb->data[i]) it
> shows that only 1472 bytes are valid data and rest 28 bytes
> are something garbage.
> I verified this with ethereal.
>
> 2>I have dumped these packets in ip_local_deliver function after
> ip_defrag and before NF_HOOK,But the result is same.
>
> Can Anybody let me know why i am not getting the complete data ?
>
> Regards,
> kanhu
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-net" in the body of a message to
> majordomo@xxxxxxxxxxxxxxx More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-net" in the body of a message to
> majordomo@xxxxxxxxxxxxxxx More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
