site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Unless it was a notification from something like: shutdown(s,SHUT_WR); -- Terry Ronnie On Apr 26, 2006, at 5:46 PM, Michael Smith wrote: On Apr 26, 2006, at 4:49 PM, Eric Long wrote: = Mike _______________________________________________ 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/rgmisra%40apple.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/tlambert%40apple.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... (Not that I think that's likely). In that case, the local client would expect to still get data, but not send it. That probably wouldn't do what he thinks he wants, though -- the problem is that you could get an infinite amount of data after that, and it might include the data you don't want to get through, so you can't just flush the packet on out. If he's just monitoring data content, though, he should make a local copy for however big his buffer size is, and just let it through, unless he's trying to catch bad data before it gets in, and wants to check data spanning a buffer boundary, rather than just monitoring. But if the buffer that was swallowed doesn't itself contain the data you're trying to stop, then sending a partial buffer, and keeping a local copy in the kext for the spanning check, rather than swallowing it, is still an OK thing to do (assuming the data isn't malicious unless complete - and if it's malicious when incomplete, then the check should have matched already on the packet that was swallowed. I expect that sending it on would be his way of discarding the buffer without having to actually do the necessary record keeping (just expecting the socket close code to do it for him, instead). If that's the case, then the issue is a race - and what he needs to do is a notification interlock on the close, so that the data gets propagated or dropped - if not by the close of the socket, then by himself. Otherwise he might end up with a slow leak, especially if his pattern matching is pretty slow. On Apr 26, 2006, at 6:23 PM, Ronnie Misra wrote: Perhaps the client is closing the socket because they time out waiting for the packet that you've swallowed? Anyway, as Mike points out, once the client has decided to close the socket, you're too late. And there is nothing the system could do to warn you before the client makes the decision to close the socket... You are asking for a hook to use as a warning that the socket will close. Do you mean a hook before the client calls close on the socket? I'm not sure how one would predict such a thing. A hook after the client calls close seems useless because the client is done calling read, so there is no point in injecting data. Well, I'm scanning data looking for pattern matches. I don't necessarily know the protocol, so I don't know for sure how much data to expect. If I find a partial match in a packet, I want to see if the next packet contains the end of the data I am looking for, so I swallow the packet and wait for the next packet. If it turns out there is no next packet, I've got a problem. If I discard the data, I've messed up the stream. I need to properly reinject it before the socket closes. Why? The socket is closing, nobody will ever read the data. Just throw it away; that's all the system would do if you were to reinject it anyway... This email sent to rgmisra@apple.com This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com