site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, Thanks, Raj Doshi On Jun 20, 2005, at 11:39 AM, Josh Graessley wrote: Or it could be something else completely. -josh On Jun 19, 2005, at 11:16 PM, Raj Doshi wrote: Hello, This email sent to jgraessley@apple.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... I just wanted to follow up on this problem to indicate that Josh was correct and the checksum and the checksum flags were not getting copied over to the new mbuf. I added the following line of code for packets on the loopback interface to fix this: mbuf_set_csum_performed(my_new_mbuf, MBUF_CSUM_DID_IP | MBUF_CSUM_IP_GOOD | MBUF_CSUM_DID_DATA | MBUF_CSUM_PSEUDO_HDR, 65535); It seems that in addition to the four flags, the checksum value "65535" is necessary for the packet not to be dropped. It may be possible that you aren't setting the rcvif correctly in the mbuf pkthdr. There is a check that the loopback packets are received on the loopback interface. Another possibility is that the checksum related flags are not being carried over. These flags indicate what checksums were performed in hardware. The loopback uses a trick where it never calculates the checksums on transmit. When the packet is looped back, the loopback interface sets the flags indicating that the checksums were calculated in hardware on the card and the checksums are correct. If you strip the flags indicating the checksum was correct according to hardware, the checksums will be performed in software. Since they were never calculated on the outbound path, the checksums will be wrong and the packet will be dropped. Look for bad checksums using netstat -s. I would first like to thank Vincent Lubet for his help with my previous question on this list. Now, I have another question: I'm intercepting incoming packets in my kext with KPI IP filters (Mac OS X 10.4.1), sending them to a user-space process, getting them back (possibly modified) from the user-space process, and re- injecting them with ipf_inject_input. I've got this working fine in most cases, like when accessing remote web sites. However, http connections to 127.0.0.1:80 fail and result in messages like "NetInfo connection failed for server 127.0.0.1/local" in console.log. To attempt to isolate the problem, I've tried the following: 1. Immediately re-injecting the mbuf that I receive from the filter. In this case, the local connection works. 2. Immediately re-injecting a copy (using mbuf_dup) of the mbuf that I receive from the filter. In this case, the local connection fails. I am wondering what I can do so that these local connections will still work when I inject a copy of the original mbuf. If there is no good solution to this, then I am wondering exactly for which packets I need to avoid making copies of the mbuf. Thanks, Raj Doshi_______________________________________________ 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/jgraessley% 40apple.com This email sent to site_archiver@lists.apple.com