November 2006 - Darwin-kernel

Re: TCP_KEEPALIVE
by jblist＠mac.com 06 Nov '06

06 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com The places this doesn't hold true are: (1) Some place along the path, you've firewalled off ARP packets, OR -Joe _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… (2) You have a Cisco PiiX firewall or other stateful firewall that tracks connection state, and has a connection timeout in order to prevent a DOS attack via connection table overflow over time (in which case, it's configurable, but you are likely either failing to configure it, or you don't have rights to configure it). You'll also see this type of behavior in any other kind of firewall that performs it's function by NAT'ing your inside IP address to an external IP address. The translation table typically has an idle timeout and will delete your NAT session after a period of inactivity. The firewalls will sometimes send RST's in both directions indicating that the connection is being closed abortively. This email sent to site_archiver(a)lists.apple.com

1 0

Re: pseudo-device pty >32
by Terry Lambert 05 Nov '06

05 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Sun, 5 Nov 2006, Terry Lambert wrote: Uh, trust the code: % ls /dev/pty* | wc -l 128 128 > 32. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Nov 5, 2006, at 12:55 PM, Tim Baur wrote: And technically, if you are willing to dig around a little bit for the information (exercise left up to the student), it's pretty trivial to get it up to 256 without hacking any source code. there may be 128 /dev/pty there, but if you attempt to open more then 32 shell's, you'll find the limit of 32 and resulting fork/ resource errors. That is a different problem. That has to do with number of processes allowed in a session by default, coupled with incorrrect resource limits settings. In other words, it's an administrative pilot error that's at fault, and not a problem with the implementation. To understand the resource limit inheritance model, you should look at the archives of this list, since I've posted about this twice in the past. Basically, it boils down to resource limits being inherited from your parent process, and Mac OS X's parent/child relationship not being what you are assuming it is, particularly for things launched via Launch Services. Depending on what version of Mac OS X you are using, the answer on how to exceed these administrative limits varies; it's easier if you are at least running something modern enough that it had a launchd (this is covered in detail in the list archives). This email sent to site_archiver(a)lists.apple.com

1 0

Re: TCP_KEEPALIVE
by Terry Lambert 05 Nov '06

05 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 4, 2006, at 10:15 AM, Michael Ledford wrote: Hello, I really recommend: Unix Network Programming, Vol. 1: The Sockets Networking API W. Richard Stevens Addison-Wesley Professional ISBN: 0131411551 The places this doesn't hold true are: (1) Some place along the path, you've firewalled off ARP packets, OR - -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I have a network program that when used in the wild normally goes through commercially available broadband routers. The problem as I'm sure many people have had is after an unspecified and unconfigurable amount of idle time the router closes the route causing any traffic to fail. Now I know we could implement a connection tickle in the application level to be sent down the line but since OS X and darwin appeared to support TCP_KEEPALIVE why not use what is already there? :-) The only problem is that appears TCP_KEEPALIVE doesn't actually do anything. So, I have cobbled together a sample socket client and server app from others so I didn't have to write much code. :-) In the client SO_KEEPALIVE is specified and TCP_KEEPALIVE is a ridiculously low value. When using tcpdump I do not see any tickle packets. Keep-Alives are for servers, so if you are setting this on the connect socket rather than the accept socket, then don't expect it to behave like you want it to. That said, if you change the code so that you are using it correctly, and things still fail... RFC compliant routers don't do this, unless you've turned on an RFC- violating option, or they inherently violate RFC's; this is because intermediate routers that aren't trying to "outsmart" something don't know from connections, just packets, and their job is only to get a packet from one interface to another, based on destination IP address an ARP table entry. (2) You have a Cisco PiiX firewall or other stateful firewall that tracks connection state, and has a connection timeout in order to prevent a DOS attack via connection table overflow over time (in which case, it's configurable, but you are likely either failing to configure it, or you don't have rights to configure it). In case #1, setting a Keep-Alive will help you, but realize that the default Keep-Alive period mandated by RFC 1122 is *no less than 2 hours*. Any system participating in setting the Keep-Alive is therefore free to ignore your requested interval, and crank it up to 2 hours, unless the requested interval is less than two hours. Also, since implementing Keep-Alives is optional, they may choose not to implement them at all. This includes any stateful firewall in the middle dropping Keep-Alives that happen in under the RFC 122 interval. In case #2, it's entirely possible that the firewall is filtering the Keep-Alive packets out and discarding them, since instead of a simple DOS, you could have a DOS with Keep-Alives set that gets around the firewall hard timeout. The firewall is probably (no probably about it, if it's a Cisco product) looking for actual data over the connection, rather than simply spurious ACKs designed to keep the connection up without necessarily doing any useful work. Also note that in either case, the retry interval is such that, if you are over the timeout window such that it sends Keep-Alives, and there is no response in a set number of probe attempts, many systems will drop the connection (see also RFC 2525, "Known TCP Implementation Problems", section 2.9; I wasn't an editor, but I contributed to 2.15... 8-)). Frankly, your best bet is an in-band tickle packet, but an even better approach would probably be to redesign your communications channel so that keeping a connection up for an ungodly amount of time with no data flowing over it becomes unnecessary to its proper operation. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Getting Notifications of Device Arrival and Departure without IOKit
by Terry Lambert 05 Nov '06

05 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 4, 2006, at 12:27 AM, NAHieu wrote: Hello, I am writing a plain KEXT which is not based on IOKit. Is there any way to get notified in kernelspace when an external device (such as USBkey) is connected to machine? Any pointer is highly appreciated. The event notification framework is part of IOKit. My recommendation is that you use IOKit. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I found related documentation at http://developer.apple.com/documentation/DeviceDrivers/Conceptual/Accessing… . Unfortunately the proposed method relies on IOKit, which is not used in my project. Many thanks. If you want to have a driver outside of IOKit do this, then you will need to provide at least an IOKit stub to talk to your device and forward notifications (e.g. via callback function registration between the KEXTs). This email sent to site_archiver(a)lists.apple.com

1 0

Re: pseudo-device pty >32
by Tim Baur 05 Nov '06

05 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Sun, 5 Nov 2006, Terry Lambert wrote: Uh, trust the code: % ls /dev/pty* | wc -l 128 128 > 32. -tbaur _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… And technically, if you are willing to dig around a little bit for the information (exercise left up to the student), it's pretty trivial to get it up to 256 without hacking any source code. there may be 128 /dev/pty there, but if you attempt to open more then 32 shell's, you'll find the limit of 32 and resulting fork/resource errors. This email sent to site_archiver(a)lists.apple.com

1 0

Re: pseudo-device pty >32
by Terry Lambert 05 Nov '06

05 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 4, 2006, at 12:19 AM, Tim Baur wrote: from pty(4) Uh, trust the code: % ls /dev/pty* | wc -l 128 128 > 32. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… In configuring, if an optional count is given in the specification, that number of pseudo terminal pairs are configured; the default count is 32. unfortunately, it appears this is a compile time option from what I've been able to find thus far and I continue to run into this limit almost daily. it has definitely become a pain point. would be ideal if it was at least doubled in the default kernel -- or, a runtime variable. thoughts? there have been previous threads [1] on the topic, dating back to 2002. And technically, if you are willing to dig around a little bit for the information (exercise left up to the student), it's pretty trivial to get it up to 256 without hacking any source code. This email sent to site_archiver(a)lists.apple.com

1 0

TCP_KEEPALIVE
by Michael Ledford 04 Nov '06

04 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello, Thanks, Michael _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com I have a network program that when used in the wild normally goes through commercially available broadband routers. The problem as I'm sure many people have had is after an unspecified and unconfigurable amount of idle time the router closes the route causing any traffic to fail. Now I know we could implement a connection tickle in the application level to be sent down the line but since OS X and darwin appeared to support TCP_KEEPALIVE why not use what is already there? :-) The only problem is that appears TCP_KEEPALIVE doesn't actually do anything. So, I have cobbled together a sample socket client and server app from others so I didn't have to write much code. :-) In the client SO_KEEPALIVE is specified and TCP_KEEPALIVE is a ridiculously low value. When using tcpdump I do not see any tickle packets. So here's what I have, a sample server and client at http:// colby.mledford.com/source/echoserv.tar.gz Feel free to download and verify...I'm testing on 10.4.8. make ./echoserv [port] tcpdump (with appropriate switches for the interface over which the client will communicate to the server) ./client hostname [port] At this point the two are connected and you should have tcpdump output... and since TCP_KEEPALIVE is set to 10 seconds you should see a packet every ten seconds... except I never do. If I were to leave the client in this state for two hours I would eventually see the packet. So i know that SO_KEEPALIVE is working but it seems TCP_KEEPALIVE affects nothing and no error is returned when setting it. Anyone have any thoughts or insight on this? Does it work in darwin? Is there something I'm missing? smime.p7s

1 0

Re: How to get the current process in kernel context?
by Michael Smith 04 Nov '06

04 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 3, 2006, at 10:26 PM, NAHieu wrote: I want to get information about the process (such as its pathname) in the current kernel context. How can I do that in MacOSX? (I am on 10.4.8) Perhaps you could elaborate on your requirements a little? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Processes do not have "pathnames" as such; there are several paths that are related to a running process. This email sent to site_archiver(a)lists.apple.com

1 0

Getting Notifications of Device Arrival and Departure without IOKit
by NAHieu 04 Nov '06

04 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=W34Eh7q6qf4Ysh2dVKGbu7xqXzZdxGWtmSoEn3fhVgZa6vn+GH1P6k8Q/vM8K0vTIKvTUeAKcYkGDVBqDBtpaZ8gbkmwkafheRni+ZWWcZqCtWNgWdaZGEEqvL2BP9uMmze9a7QYagh5E7wvN6BhjGLrWFcMh4kEU9t+NAu3TSY= Hello, I am writing a plain KEXT which is not based on IOKit. Is there any way to get notified in kernelspace when an external device (such as USBkey) is connected to machine? I found related documentation at http://developer.apple.com/documentation/DeviceDrivers/Conceptual/Accessing…. Unfortunately the proposed method relies on IOKit, which is not used in my project. Any pointer is highly appreciated. Many thanks. H _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

pseudo-device pty >32
by Tim Baur 04 Nov '06

04 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com from pty(4) there have been previous threads [1] on the topic, dating back to 2002. thanks, -tbaur In configuring, if an optional count is given in the specification, that number of pseudo terminal pairs are configured; the default count is 32. unfortunately, it appears this is a compile time option from what I've been able to find thus far and I continue to run into this limit almost daily. it has definitely become a pain point. would be ideal if it was at least doubled in the default kernel -- or, a runtime variable. thoughts? [1] http://lists.apple.com/archives/darwinos-users/2002/Jun/ msg00088.html _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0