> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Lehner Franz
> Sent: Thursday, March 08, 2007 2:32 AM
> To: Kanhu Rauta; [email protected]
> 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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag von Kanhu Rauta
> Gesendet: Donnerstag, 8. März 2007 07:16
> An: [EMAIL PROTECTED];
> [email protected]; [EMAIL PROTECTED];
> [email protected]
> 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
> [EMAIL PROTECTED] 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
> [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
