> -----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
