March 2007 - Darwin-dev - lists.apple.com

Darwin 8.8 versions
by Mo McRoberts 31 Mar '07

31 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, Any answers are much appreciated! Many thanks, Mo. -- mcroberts // juebmuncki / sysadmin :: become interactive / 25 carlton court / glasgow / g5 9jp :: registered in scotland no. SC215662 T: 0141 418 0555 M: 07837 274 053 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This is possibly slightly off-topic, I apologise if there's a more appropriate list for this—I couldn't find one. I'm having a little trouble getting confirmation for this, but I seem to remember the situation being: * Darwin 8.8.0 was released (corresponding to Mac OS X 10.4.8/ppc), but didn't support x86 platforms * A short while later (2006-11-08, I think?) Darwin 8.8.1 was released, corresponding to Mac OS X 10.4.8 for Intel. Is anybody able to confirm whether this is actually the case, or if I've missed something somewhere? The darwinsource page just shows 8.8/ x86 and 8.8/ppc, though all of the differences between the two releases are increased version numbers for x86. Also, is it possible to build and run what I think is 8.8.1 (10.4.8.x86) for PPC, or does it _only_ support x86? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Possible problem with readdir() and/or lstat()
by John Hayes 30 Mar '07

30 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Hz3U8cQdZ8SM8RlTNUaSGLVo8ZjmQnQ/HDz5pQdAG2WVha68S0pbV/d8a6zWCxyuDdflh9EcJT/nn4zTwcPcAq3mTtBkLWF/UI2aeeA9n/+bGDzalE7Dwwp2bXVtoksDU85UACumuNrzfrAaOP45uBs3hwIionj1flXWTTTd5Es= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=coABXYTIeU9iPzMzAJTQhvOx9/fAmb1bueCETw6bTi1vBTOYDGU2YHInutG8poFVjBwpSnLrw+yOOv8NqGRkjtK/dP2jtm2aejO6b8mOPil2CUiMZazdInz/3XfYFjcYkJnwzOJvp+avFk5rZQ5EgrH2w5YmGGizcMTDpUGIs8c= entry->d_name is relative to dir so the lstat() call is failing. You are displaying the result from the lstat("..") call. -john [Apologies for the double-post; I just realized darwin-userlevel was the wrong group for this.] % cat test.c #include <sys/stat.h> #include <dirent.h> #include <stdio.h> #include <assert.h> int main( int argc, char** argv ) { DIR* dir ; struct dirent* entry ; struct stat buf ; assert(argc == 2) ; dir = opendir(argv[1]) ; assert(dir != 0) ; while( (entry = readdir(dir)) != 0 ) { lstat(entry->d_name, &buf) ; printf("name: %s --- S_ISDIR: %d\n", entry->d_name, S_ISDIR(buf.st_mode)) ; } return 0 ; } % gcc test.c -o test % file * file1: ASCII text file2: ASCII text somedir: directory test: Mach-O executable i386 test.c: ASCII C program text % ./test . name: . --- S_ISDIR: 1 name: .. --- S_ISDIR: 1 name: file1 --- S_ISDIR: 0 name: file2 --- S_ISDIR: 0 name: somedir --- S_ISDIR: 1 name: test --- S_ISDIR: 0 name: test.c --- S_ISDIR: 0 % file somedir/* somedir/file3: ASCII text somedir/file4: ASCII text somedir/somedir2: directory % ./test somedir name: . --- S_ISDIR: 1 name: .. --- S_ISDIR: 1 name: file3 --- S_ISDIR: 1 name: file4 --- S_ISDIR: 1 name: somedir2 --- S_ISDIR: 1 Note that file3 and file4 are not directories. ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/jahayes%40gmail.com This email sent to jahayes(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On 3/30/07, Jeff Sparks <jeffrsparks(a)yahoo.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Possible problem with readdir() and/or lstat()
by Jeff Sparks 30 Mar '07

30 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=wJ3LQ7CJYPaeCsWFu9EBOdmfMOwx6e9UefCajpb7AuTzcv4Yzpr8LnAYQkUrMtSp674ZV+030x///rxqSMxP21J+Zw6e82eSeqH4/pPSljmUWY8+O9+6pWDbgMxj5w2yVDLcI2mMb3K35ZECEe4hlWhGKealTuIpKJVCfECHLNE=; [Apologies for the double-post; I just realized darwin-userlevel was the wrong group for this.] % cat test.c #include <sys/stat.h> #include <dirent.h> #include <stdio.h> #include <assert.h> int main( int argc, char** argv ) { DIR* dir ; struct dirent* entry ; struct stat buf ; assert(argc == 2) ; dir = opendir(argv[1]) ; assert(dir != 0) ; while( (entry = readdir(dir)) != 0 ) { lstat(entry->d_name, &buf) ; printf("name: %s --- S_ISDIR: %d\n", entry->d_name, S_ISDIR(buf.st_mode)) ; } return 0 ; } % gcc test.c -o test % file * file1: ASCII text file2: ASCII text somedir: directory test: Mach-O executable i386 test.c: ASCII C program text % ./test . name: . --- S_ISDIR: 1 name: .. --- S_ISDIR: 1 name: file1 --- S_ISDIR: 0 name: file2 --- S_ISDIR: 0 name: somedir --- S_ISDIR: 1 name: test --- S_ISDIR: 0 name: test.c --- S_ISDIR: 0 % file somedir/* somedir/file3: ASCII text somedir/file4: ASCII text somedir/somedir2: directory % ./test somedir name: . --- S_ISDIR: 1 name: .. --- S_ISDIR: 1 name: file3 --- S_ISDIR: 1 name: file4 --- S_ISDIR: 1 name: somedir2 --- S_ISDIR: 1 Note that file3 and file4 are not directories. ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Something in my code causes Intel wireless association to die.
by Terry Simons 28 Mar '07

28 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Ben, Thanks for the reply. Thanks, - Terry On Mar 28, 2007, at 2:01 PM, Ben Byer wrote: Ben On Mar 27, 2007, at 8:29 PM, Terry Simons wrote: Sweet. That was the problem. Can someone comment on whether this is expected behavior? ;) - Terry P.S. Thanks for the replies Matt. ;) On Mar 27, 2007, at 9:03 PM, Ben Byer wrote: On Mar 27, 2007, at 4:48 PM, Terry Simons wrote: Has anyone seen this before? Try applying this patch: http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/inet.c?r1=1.72&r2=1.73 (explanation is provided in a comment inside the patch.) Ben _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/galimore%40mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… The problem is going to affect any networking application that tries to enumerate the interfaces on the system and unknowingly opens the wlt interface. My application, for instance, doesn't use pcap at all. I am doing raw enumeration and socket handling. I suspect that Wireshark is doing some of its own interface handling as well... which might explain why it has the issue. I don't think it's a very big deal... The symptoms are obvious, and the fix is known so I'm a happy developer. ;) I haven't looked at the Atheros driver code, but my understanding is that this is an "unintended consequence" of the way the Atheros driver / BPF interface is implemented; I'm not aware of any immediate plans to change that code, so it's probably a safer bet to change the libpcap code, unless we find a lot of other bits of code that are broken by this ... quirk. Interesting that this only affects the Atheros systems. I had a friend try on a Broadcom based Intel Mac and it didn't exhibit the same issue, although he does have a "wlt" interface. Must be something specific to the Atheros driver's implementation of the monitor mode bits. My application, which appears to work fine on PowerPC Macs, causes the wireless card on Intel macs (MacBook Pro for sure) to lose association. I'm not sure what's causing this... but it definitely looks like a bug. I'm using BPF and calling network IOCTLs... so I'm pretty sure it's something in there, but I haven't been able to locate the exact issue yet. Any lurkers privy to the inner workings of the Atheros Airport driver? This email sent to galimore(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Something in my code causes Intel wireless association to die.
by Ben Byer 28 Mar '07

28 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Ben On Mar 27, 2007, at 8:29 PM, Terry Simons wrote: Sweet. That was the problem. Can someone comment on whether this is expected behavior? ;) - Terry P.S. Thanks for the replies Matt. ;) On Mar 27, 2007, at 9:03 PM, Ben Byer wrote: On Mar 27, 2007, at 4:48 PM, Terry Simons wrote: Has anyone seen this before? Try applying this patch: http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/inet.c?r1=1.72&r2=1.73 (explanation is provided in a comment inside the patch.) Ben _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/galimore%40mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I haven't looked at the Atheros driver code, but my understanding is that this is an "unintended consequence" of the way the Atheros driver / BPF interface is implemented; I'm not aware of any immediate plans to change that code, so it's probably a safer bet to change the libpcap code, unless we find a lot of other bits of code that are broken by this ... quirk. Interesting that this only affects the Atheros systems. I had a friend try on a Broadcom based Intel Mac and it didn't exhibit the same issue, although he does have a "wlt" interface. Must be something specific to the Atheros driver's implementation of the monitor mode bits. My application, which appears to work fine on PowerPC Macs, causes the wireless card on Intel macs (MacBook Pro for sure) to lose association. I'm not sure what's causing this... but it definitely looks like a bug. I'm using BPF and calling network IOCTLs... so I'm pretty sure it's something in there, but I haven't been able to locate the exact issue yet. Any lurkers privy to the inner workings of the Atheros Airport driver? This email sent to galimore(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Something in my code causes Intel wireless association to die.
by Kent Harris 28 Mar '07

28 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com while true ; do /sbin/ping -c 1 -t 2 ${Airport1} > /dev/null r=$? if [ $r -ne 0 ] ; then /usr/bin/syslog -s -l critical "Reconnecting to Airport" ${airport} -a fi sleep ${checkIntervalSeconds} done The comment referred to above is summarized from a macosxhints column: - Kent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Opening the "wlt" device causes network de-association. On my Intel mac mini, "tcpdump -D" does it every time. However, there seems to be something else as I randomly loose association several times a day. Indeed, I launch the following script via launchd at system startup (probably should let launchd do the periodicity -- think I'll go change that): #!/bin/sh # Re-associate to preferred network -- see comment in com.vine.ipfw.plist # Airport1="10.0.1.1" checkIntervalSeconds=60 airport="/System/Library/PrivateFrameworks/Apple80211.framework/ Versions/Current /Resources/airport" # Note about Airport (Mac mini) access. You must: # (1) In network preferences > Airport, set the "By default, Join:" to # "Preferred network." # (2) In AirPort > Options..., set "If no preferred networks are found:" # to "Keep looking for recent networks." # (3) In Utilities > Keychain Access, select your Network under Login # Keychains. Check the "Show password:" box and make sure it is # correct. Under "Access Control" tab, select the "Allow all # applications to access this item." (Perhaps installing the correct # application access would also work but I'm unsure as to the app. # Note there is a system keychain entry also -- you can't see the # password -- but you can see the access control and this may # actually be the relevant guy as opposed to the login keychain.) The mini routes to the internet via the wireless and operates unattended for long periods of time so maintaining connectivity is critical. Interestingly enough, the failure incidence dropped dramatically with the Apple 10.4.9 update. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Something in my code causes Intel wireless association to die.
by Terry Simons 28 Mar '07

28 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Sweet. That was the problem. Can someone comment on whether this is expected behavior? ;) - Terry P.S. Thanks for the replies Matt. ;) On Mar 27, 2007, at 9:03 PM, Ben Byer wrote: On Mar 27, 2007, at 4:48 PM, Terry Simons wrote: Has anyone seen this before? Try applying this patch: http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/inet.c?r1=1.72&r2=1.73 (explanation is provided in a comment inside the patch.) Ben _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/galimore%40mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Interesting that this only affects the Atheros systems. I had a friend try on a Broadcom based Intel Mac and it didn't exhibit the same issue, although he does have a "wlt" interface. Must be something specific to the Atheros driver's implementation of the monitor mode bits. My application, which appears to work fine on PowerPC Macs, causes the wireless card on Intel macs (MacBook Pro for sure) to lose association. I'm not sure what's causing this... but it definitely looks like a bug. I'm using BPF and calling network IOCTLs... so I'm pretty sure it's something in there, but I haven't been able to locate the exact issue yet. Any lurkers privy to the inner workings of the Atheros Airport driver? This email sent to galimore(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Something in my code causes Intel wireless association to die.
by Ben Byer 28 Mar '07

28 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 27, 2007, at 4:48 PM, Terry Simons wrote: Has anyone seen this before? Try applying this patch: http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/inet.c?r1=1.72&r2=1.73 (explanation is provided in a comment inside the patch.) Ben _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… My application, which appears to work fine on PowerPC Macs, causes the wireless card on Intel macs (MacBook Pro for sure) to lose association. I'm not sure what's causing this... but it definitely looks like a bug. I'm using BPF and calling network IOCTLs... so I'm pretty sure it's something in there, but I haven't been able to locate the exact issue yet. Any lurkers privy to the inner workings of the Atheros Airport driver? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Something in my code causes Intel wireless association to die.
by Matt Johnston 28 Mar '07

28 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.13 (2006-08-11) On Wed, Mar 28, 2007 at 10:28:20AM +0800, Matt Johnston wrote: > On Tue, Mar 27, 2007 at 05:48:47PM -0600, Terry Simons wrote: > > My application, which appears to work fine on PowerPC Macs, causes > > the wireless card on Intel macs (MacBook Pro for sure) to lose > > association. > > The same happens with MacPorts' libpcap 0.9.4 - when you run > tcpdump/wireshark linked against that the wireless stops > working. The system libpcap version is also allegedly 0.9.4, > I didn't track down the difference between them. I suspect > that there's something odd going on in kernelspace rather > than userspace. Just to clarify - Having checked using install_name_tool on the tshark (terminal wireshark) and tcpdump binaries, it seems that it's wireshark itself that has problems, not libpcap. Tcpdump works fine with either libpcap. Matt _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Something in my code causes Intel wireless association to die.
by Matt Johnston 28 Mar '07

28 Mar '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.13 (2006-08-11) On Tue, Mar 27, 2007 at 05:48:47PM -0600, Terry Simons wrote: > My application, which appears to work fine on PowerPC Macs, causes > the wireless card on Intel macs (MacBook Pro for sure) to lose > association. > > I'm not sure what's causing this... but it definitely looks like a bug. > > Has anyone seen this before? The same happens with MacPorts' libpcap 0.9.4 - when you run tcpdump/wireshark linked against that the wireless stops working. The system libpcap version is also allegedly 0.9.4, I didn't track down the difference between them. I suspect that there's something odd going on in kernelspace rather than userspace. Matt _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0