site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DbK9iGb6odEjbEAjGesiJyPtLsS0IoRDlVp0LhvmBlqKegX5Wu5oGJPZJfu/y+I5/8RKR9JIebPcf9vlw/Z0h4HbmCo95cow9MUPebeOsdAWlq2yjw61qs74jowQcY9I1e1QVHjQ6X70Ow0I80jfxSIPEudQZNMB30YKor35CBY= Well I rebuilt my NKE to use the EJUSTRETURN/ipf_inject_output model for inspecting outbound traffic. This seems to be working great, so apparently my prior attempts were doing something wrong. Anyways, that bit is operating beautifully, but I've gotten into some trouble on the inbound side. Basically I'm flagging "interesting" TCP connections as they are detected on the outbound side, and then waiting for return traffic. When this traffic arrives it is slightly adjusted. To do this, my inbound filter hook function does some simple steps: - Allocate a buffer and copy the original packet data into it via mbuf_copydata() - Detect the TCP payload section of the packet and adjust it - Duplicate the original mbuf passed to the hook via mbuf_dup - Use mbuf_copyback to copy over the adjusted data buffer into the duplicated mbuf - Send the newly built packet to ipf_inject_input - Discard the original packet by returning EJUSTRETURN This is working excellently on vanilla Ethernet connections. The adjusted data shows up in the final client application and everything is great and very stable (automated tests have run over 10,000 adjusted packets across the running NKE without problems). Unfortunately, something goes wrong on both my Airport-enabled iBook and the AIrport Extreme connection on my Mini. On these connections, the modified packet never reaches the client application up in userland. ipf_inject_input returns 0 and no errors occur during the construction process. I've seen on other platforms (specifically Linux) that modifying a TCP packet in this way can cause the TCP stack to drop the packet because the checksumming becomes invalid. Even though just the payload (and not any of the IP/TCP headers) is modified, I suspect that may be happening somehow here as well - perhaps Airport's hardware checksumming is working differently from the Ethernet NIC? I vaguely remember reading somewhere on the list about the loopback interface setting a flag that effectively bypassed the checksum validation in the TCP stack. I've tried a couple of things like mbuf_inbound_modified() but that seems to cause the packet to get dropped in all connections. Is there a way to directly compute the checksums or something so that this modified packet will pass through the stack properly? Or am I barking up entirely the wrong tree with this modification method? Thanks in advance, Frank _______________________________________________ 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... This email sent to site_archiver@lists.apple.com