site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Let's say .8 is my Mac: Thus in order to use the h/w for checksum calc one should: Have fun, Stauff On Aug 24, 2007, at 9:40 PM, mm w wrote: Hi platon, struct packet { struct mbuf *buf; struct iphdr header; int sum; tcp_seq seq; int size; ... /* what you want */ }; @+ Hey mm Yup exactly, that's what is written in Apple's docs but as we all have access to the kernel and overall - why on earth we should need to do this? Of course there are cases - when I change destination, metric, etc, etc. But if f.ex. I just changed packet length? Imho it's not the case for re-injection. And it actually works as expected on my test-cases - I can do whatever I want as long as I keep its destination, etc. But my case is simple I need to increase data size for say 20 bytes. I actually managed to get some weird checksum (wrong) from H/w - I will keep you informed about my progress.. Best regards, Platon On Aug 24, 2007, at 7:54 PM, mm w wrote: Hi Platon, Cheers Hi Everybody Thus some questions: Best regards, Platon. On Aug 23, 2007, at 9:05 AM, JanakiRam wrote: openspecies%40gmail.com This email sent to openspecies@gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Ok I sorted this out - it actually works as expected. The main issue is that H/W sometimes can calculate only pure TCP header & data checksum without calculating pseudo-header checksum which is complex for h/w to do. Thus stack should do it itself. If you look at your Mac tcpdump trace you may see smth like this for TCP/UDP: 00:08:52.813229 IP (tos 0x0, ttl 64, id 41585, offset 0, flags [none], proto: UDP (17), length: 70) 10.0.44.8.49382 > 10.0.44.1.domain: [bad udp cksum 754f!] 12935+ PTR? 21.24.12.64.in- addr.arpa. (42) As you see TCPDump considers cksum as incorrect! But this is a pseudo- header cksum! The other half will be computed by the driver later before sending packet. 1) Make sure that h/w actually can do _TCP and _UDP checksum offloading, see ifnet_offload 2) If you correct packet and you absolutely sure you will not re- inject it correct TCP/UDP checksum in their respective headers to contain a correct pseudo-header checksum. 3) There is a slim chance that h/w can do full (without the necessity to do pseudo-checksums) TCP/UDP checksumming (in XServes imho) but I can't find out how to figure this out ;) as far i know, it isn't implemented i understand well your problem, the problem is, the check-sum is applied to the whole of packet, if you change the size, you change it On 8/24/07, Platon Fomichev <pfomichev@alarity.com> wrote: If your modifications involve changes to packet header information you must swallow the packet entirely and reinject it. On 8/24/07, Platon Fomichev <pfomichev@alarity.com> wrote: It seems I can't figure how to correctly offload my TCP/UDP packet to the H/W network checksumming routines. It seems rather inconvenient that I have to add all typical checksumming code into the driver - because neither of mbuf API can actually re-checksum the packet. As for H/W support - I can see from the flags that my H/W supports TCP offload but if I set tcp checksum f.ex. to zero in my Interface filter the packet will not be checksummed later in the hardware. 1) Seems that there is no kernel API to do IP checksumming in Mac - is it true, if not how to do it? mbuf finalize func does not do it. 2) Seems that hardware TCP/UDP checksum offload is actually missing from Mac at all? At least it is not present on MacBook/MacBook pro. If yes why does it advertise itself using ifnet API as capable to do it? If I am wrong how can I check that my network adapter is actually doing its work and how can I benefit from this in my code (I am actively changing the packet) This email sent to site_archiver@lists.apple.com