January 2008 - Macnetworkprog

Re: delete the entry from loginwindow.plist using command
by Mike Fischer 31 Jan '08

31 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com Am 30.01.2008 um 21:05 schrieb Quinn <eskimo1(a)apple.com>: This is just one of the problems you encounter when accessing this file directly. From your question it seems that you want to add and remove Login Items, correct? As you probably noticed there are no official APIs for this. Actually, that's changed in 10.5, where we now have a proper API to modify both the per-user and global login items list. See "LSSharedFileList.h" for details. Cool! I hadn't seen that yet, even thought it is mentioned in TN2083. Alas, I haven't yet had time to write a sample that shows how to use this. It's a pretty simple API though. Thanks! Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… At 22:01 +0100 29/1/08, Mike Fischer wrote: It could also use a bit more documentation. But I agree, that it is basically usable. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
by Peter Sichel 31 Jan '08

31 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com On Jan 31, 2008, at 12:02 AM, Hostile Fork wrote: - Peter _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… While I ponder why THAT's going on, I thought I'd follow up on your bpftransmit suggestion. Unfortunately, documentation on Berkeley Packet Filters isn't very widespread... so I'm having trouble constructing a simple series of lines of code that will build a broadcast UDP packet and put it onto the ethernet card. Could you by any chance point me at a sample I might adapt? There's a good example of using bpftransmit in the Darwin "bootp" project. That's where I cribbed mine from. This email sent to site_archiver(a)lists.apple.com

1 0

Re: accept() and setsockopt() and port scans
by Quinn 31 Jan '08

31 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com There are two cases here. The specified option is invalid at the specified socket level or the socket has been shut down. <http://www.opengroup.org/onlinepubs/009695399/functions/setsockopt.html> <http://developer.apple.com/bugreporter/> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… At 10:53 +1300 31/1/08, Glenn Anderson wrote: Sometimes when this happens, accept() returns an address_len of 0. I see this on both Mac OS X 10.4 and 10.5. On Mac OS X 10.5 setsockopt(x, SOL_SOCKET, SO_NOSIGPIPE, ...) also fails with EINVAL in this case. Depending on the timing of the RST, I have also seen a correct address_len from accept() but the subsequent setsockopt() fails. Is accept() returning an address_len of 0 and setsockopt() failing with EINVAL intended behavior? If it is intended, is it documented anywhere? The man pages for these calls definitely don't mention this behavior. A. accept returns a valid address and setsockopt fails afterwards -- This seems like reasonable behaviour on behalf of the kernel. It gave you back a valid socket but the socket shut down before you called setsockopt. The standard specifically states that EINVAL can be caused by: I suspect that the UNIX '03 conformance changes are the reason why you're seeing different behaviour on 10.4 vs 10.5. B. accept returns a null address -- This smells like a bug to me. Definitely Radar-worthy IMHO. Please send me the bug number. Also, if you can include code that reproduces the problem, that will definitely improve the chances of it getting fixed (-: While debugging this, I couldn't help wondering if there any way to check the state of a socket to see if the connection has shut down, like OTGetEndpointState under OS 9? I expect that your best bet is <x-man-page://2/getpeername>. This is traditionally used by sockets code to test whether a connection is in place. For example, when doing non-blocking connects, you typically use getpeername to determine whether the connect succeeded or failed. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
by Hostile Fork 31 Jan '08

31 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=HkwhU3fi6ryzgYyPFx7xs9SpPIJsM1sHOlonj2OnK2Q=; b=CjxxB3GqpTIytb60q3NP2JFEaQot6F0eCLyJmU5QMdCtAFyinnIASSFw6uyg811KJzc/IfhwlNuNjnGS5TpuWTI3JI68HQFSshMwMfBDGH6BD84p8eHfpQugw0O7HzrxR/+peVHlm660WnishkFDASvoAxwi2W5qw+yGUPK2zcY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=JX+PLK5pKDayc6dSJ4/C90gRleV2KuSR4IkrWRJSFb0D2g9deh72WqrgE3Tji9ffB1XxkEVO+mE9rkCL/FG+euSd2c0NzkhFQxpOLaB55y6nwkutc0K74OKfWmxSGnJnvUX8ylhA0neMEdUZ7OxTLPmD60bI5f9TIunOKJsmqAY= _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

accept() and setsockopt() and port scans
by Glenn Anderson 30 Jan '08

30 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com Glenn. _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… I have run in to some issues with accept() and setsockopt() with TCP port scans. What is happening is over the network is this: C: SYN S: SYN+ACK C: ACK C: RST Sometimes when this happens, accept() returns an address_len of 0. I see this on both Mac OS X 10.4 and 10.5. On Mac OS X 10.5 setsockopt(x, SOL_SOCKET, SO_NOSIGPIPE, ...) also fails with EINVAL in this case. Depending on the timing of the RST, I have also seen a correct address_len from accept() but the subsequent setsockopt() fails. Is accept() returning an address_len of 0 and setsockopt() failing with EINVAL intended behavior? If it is intended, is it documented anywhere? The man pages for these calls definitely don't mention this behavior. While debugging this, I couldn't help wondering if there any way to check the state of a socket to see if the connection has shut down, like OTGetEndpointState under OS 9? Seems like the only way to find out that the connection has shut down is to write to it or read from it, and on 10.5 setsockopt() failing means writing to the socket produces a SIGPIPE. This email sent to site_archiver(a)lists.apple.com

1 0

Re: delete the entry from loginwindow.plist using command
by Mike Fischer 30 Jan '08

30 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com Am 30.01.2008 um 11:37 schrieb sunil prajapati: Thanks Mike for your help. And your question is? >From Apple's technote on Daemons and Agents: Mike Thanks, Sunil. On Jan 30, 2008 10:46 AM, Mike Fischer <mike_fischer(a)mac.com> wrote: Am 30.01.2008 um 05:52 schrieb sunil prajapati: > How can I launch my application at login time for each user? > Because I know only one way that is loginwindow.plist. As u said > loginwindow.plist is managed by system so don't do anything with > this. So please suggest some other method to launch my application > at login time. Did you read the technote I referenced in my answer? Did you look at the sample code I mentioned? If not, please do so, as the answers are all there. Also since the file "loginwindow.plist" is located in each users ~/ Library/Preferences/ folder modifying one (directly or as suggested by the technote and sample code) will not affect other users in any way. If you need to launch something for *any* user at login then the sample code will likely not help you. Instead you should carefully read the technote. Since you did not state the actual (high-level) task you are trying to accomplish or the minimum system version you need to support I can't give any more advice than to read. HTH Mike PS. Please don't continue discussions off the mailing list. Others might be interested in the answers and others might chime in with useful tipps. -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Note: I read this list in digest mode! Send me a private copy for faster responses. -- Thanks & Regards, Sunil Prajapati Software Developer in Macintosh -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… The link which have given there is one sample code "LoginItemsAE" which is used to add and delete the entry from ~/Library/ Preferences/loginwindow.plist. I want the same kind of functionality which will be used for all the users i.e. plist which will be common for every user. My application is GUI based and I want to launch it after login so I can use "lauchd" . In the link of technote there is detail information for "Global Login Item". It is mentioned as: A global login item is a login item that is launched when any user logs in. Installing a global login item is roughly equivalent to installing that login item for all users on the system: every time a user logs in, loginwindow launches that user's login items and all global login items. In Mac OS X 10.5 and later you can install a global login item using the shared file lists interface to Launch Services. How we can go for global login item? I give up! I suggested multiple times that you need to read the technote. Obviously you at least looked at it (after ignoring the suggestion at first) but you didn't really read all of it. If you had you would not have to ask this question again. I again strongly suggest reading the technote and in addition to also read: <http://catb.org/~esr/faqs/smart-questions.html> Please do not contact me privately again. If you have questions ask them on the appropriate mailing list. > On Jan 30, 2008 2:31 AM, Mike Fischer <mike_fischer(a)mac.com> wrote: > Am 29.01.2008 um 21:07 schrieb "sunil prajapati" > <skumar2011(a)gmail.com>: > > > Hi Guys, > > > > I successfully entered my application in loginwindow.plist through > > command > > line. But unable to delete that entry. > > Does this have anything to do with the topic of this mailing list? > > > > How to remove the my added entry from loginwindow.plist from > > command line > > or shells script? > > First of all the loginwindow.plist is an implementation detail > managed by the system. You should not access it directly. You should > most definitely not modify this file! > > > >> From net I found one script which remove the entry from > > loginwindow.plist,but > > it remove whole entries from the plist. > > > > The command is: > > > > #!/bin/sh > > theApp="your app" > > nl=`echo "x" | tr 'x' '\34'` # what is the proper way to set ascii > > to a > > variable? > > aaa=`defaults read loginwindow AutoLaunchedApplicationDictionary` > > bbb=`echo -n "$aaa" | sed "s/^[()]$//;s/},/}$nl/" | tr '\n\34' '\00 > > \n'| grep > > -va "$theApp" | tr '\n\00' ',\n' | sed 's/^,$//'` > > defaults write loginwindow AutoLaunchedApplicationDictionary > "($bbb)" > > > > Waiting for helpful reply. > > This is just one of the problems you encounter when accessing this > file directly. From your question it seems that you want to add and > remove Login Items, correct? As you probably noticed there are no > official APIs for this. > > Depending on your needs you might consider either launchd(8) > (LaunchAgents, 10.5+ only). Or if you really need a Login Item then > you should use the Apple sanctioned method shown in the Sample Code > project 'LoginItemsAE' (<http://developer.apple.com/samplecode/ > LoginItemsAE/index.html>). It's not an API but it get's the job done > in a way that is not totally broken and dangerous like your code > above. > > See: <http://developer.apple.com/technotes/tn2005/tn2083.html> > > > > -- > > Thanks & Regards, > > > > Sunil Prajapati > > Software Developer in Macintosh > >

1 0

Re: Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
by Peter Sichel 30 Jan '08

30 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com On Jan 30, 2008, at 2:57 AM, Hostile Fork wrote: Kind Regards, - Peter Sichel Sustainable Softworks http://www.sustworks.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… I am porting a WinSock DHCP-like server to OS/X, and have run into a wall. I've written a Mac OS X DHCP Server that has been shipping for some time. After using packet sniffers I've found a smoking gun that OS/X may be ignoring broadcast UDP packets that are sent from the serviced network to 255.255.255.255 to the serviced port #8567. (FYI: This machine has two network cards, and the devices that are making DHCP requests are connected on a network through the second card which has a static IP address... the first card is used for plain ol' internet access.) It's a little complicated, but I'll point out that send()s to that static IP subnet are seeming to work and get a reaction, so the connection is at least somewhat "alive". I vaguely recall running into some issues in the BSD stack around which network interface(s) will receive broadcast packets that caused me to use libpcap to receive the packets at the data link layer. Compared to other network stacks (like Mentat/TCP) which just work, broadcast is kind of broken in the BSD stack. It's common practice to use libpcap for receive and bpftransmit for send when implementing DHCP servers or clients. As I remember, in Mentat/TCP broadcast packets were always duplicated and sent upstream or downstream to every broadcast enabled interface. In BSD, the packet is not automatically duplicated. The first broadcast enabled interface receives inbound broadcasts, and sending requires that you use the subnet broadcast address to determine which interface will transmit the packet. The critical flaw in this is that computers with one or more dynamically configured interfaces have become so common that the behavior is unpredictable in the field. This email sent to site_archiver(a)lists.apple.com

1 0

Re: delete the entry from loginwindow.plist using command
by Jerry Krinock 30 Jan '08

30 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com On 2008 Jan, 30, at 1:49, Quinn wrote: IMPORTANT: If you manipulate the list of login items (either per- user or global) by directly modifying plist files, you will break on future versions of Mac OS X. Use the new API! Alternatively, use the LoginItemsAE technique, which works back to 10.2 and should continue to work for the foreseeable future. Yes, I was going to reply to this thread and mention LoginItemsAE, but I didn't because as usual with login/startup/daemon/background stuff I was only 50% sure that I was understanding the problem correctly. Also, Quinn, regarding LoginItemsAE, I've been using it for a couple years, and I've always seen occasional "No response from System Events" errors on slow Macs, like 500 MHz G3s. So I increased the timeout from 5 to 10 seconds in there, and added a loop to relaunch System Events when this happens, and that made it better. But now, under Leopard, I'm getting these errors occasionally even on my Intel Core Duo Mac Mini. And relaunching System Events doesn't help immediately. I haven't enough data to file a bug report yet, but if anyone has any tips on this, let me know. Another issue: what would be the appropriate forum to discuss this? I don't think it's macnetworkprog. _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: delete the entry from loginwindow.plist using command
by Quinn 30 Jan '08

30 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… At 22:01 +0100 29/1/08, Mike Fischer wrote: This is just one of the problems you encounter when accessing this file directly. From your question it seems that you want to add and remove Login Items, correct? As you probably noticed there are no official APIs for this. Actually, that's changed in 10.5, where we now have a proper API to modify both the per-user and global login items list. See "LSSharedFileList.h" for details. Alas, I haven't yet had time to write a sample that shows how to use this. It's a pretty simple API though. Currently Mac OS X has a compatibility shim that syncs between the plist files and the backing store for the new API. That compatibility shim will not be present forever. IMPORTANT: If you manipulate the list of login items (either per-user or global) by directly modifying plist files, you will break on future versions of Mac OS X. Use the new API! Alternatively, use the LoginItemsAE technique, which works back to 10.2 and should continue to work for the foreseeable future. This email sent to site_archiver(a)lists.apple.com

1 0

Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
by Hostile Fork 30 Jan '08

30 Jan '08

site_archiver(a)lists.apple.com Delivered-To: macnetworkprog(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:mime-version:subject:date:x-mailer; bh=wqzvcu24oSEOMnXkg1Ndd4GxaXihHZrZ+NWJua9UeCY=; b=FC9DZbtKjVE4qnmxkxusrXGQNKjCJk+V06xZgrCkhAI3GNn8dvc9kgPU/B9pbS3JVNlWVFbaObk6zuNZFJJfG/Tyu8F2BShWWxpZusIx4lVXzN3TQHwPxrImZ2hBcroPOjt/WUdotTC+HeYP3k9JDj9Y7g7MT9zAggkuj/qcypg= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:mime-version:subject:date:x-mailer; b=Xu++PU71Vpoes+zi7cnfc1DLutv0WkgHtOUtwS3wXSJGblrmxPpCpbE/ofUDH3FLYvyMtkrOccWJygZSUHkMSUe2KkLZXJQMRpsIA5NSE1548gw2WTzv+cXprnFDlLX44/7GcSasm6FCnVhcSPkbrrwROIndVISCEhrng84Eo7Q= Hello Mac Network programmers...! http://lists.apple.com/archives/Macnetworkprog/2003/Jun/msg00023.html http://developer.apple.com/qa/nw/nw53.html http://savannah.nongnu.org/task/?6995 --- http://hostilefork.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… I am porting a WinSock DHCP-like server to OS/X, and have run into a wall. After using packet sniffers I've found a smoking gun that OS/X may be ignoring broadcast UDP packets that are sent from the serviced network to 255.255.255.255 to the serviced port #8567. (FYI: This machine has two network cards, and the devices that are making DHCP requests are connected on a network through the second card which has a static IP address... the first card is used for plain ol' internet access.) It's a little complicated, but I'll point out that send()s to that static IP subnet are seeming to work and get a reaction, so the connection is at least somewhat "alive". The evidence that I have that packets are being ignored is that running netcat directly to the IP address with a UDP packet unblocks my recvall() call, while packets sent to the same port but broadcast to 255.255.255.255 from 0.0.0.0 will not unblock the recvall(). The packet sniffer shows that the mac is receiving these broadcast packets. And curiously, it works to run the Windows version of the DHCP server under VMWare if the two network cards are bridged as virtual devices for Windows. Under VMWare, Windows will unblock the recv call in response to the 255.255.255.255 message that shows up in the sniffer! The OS/X firewall is turned off and there is no other firewall running that I know of, so that isn't likely to be the problem the way it was here: I've seen other people having this issue, and read this technical note which they were referred to: I'm using Berkeley sockets API, so the best I can say is that my bind() call is using INADDR_ANY, which is 0.0.0.0. I also took the precaution of adding SO_BROADCAST to the sockoptions, even though it wasn't in the Windows code and I'm not certain it affects receivers. I added it anyway because this UNIX page says that when SO_BROADCAST is enabled, "datagram sockets receive packets sent to a broadcast address and they are allowed to send packets to a broadcast address.": I'm kind of at a loss for what I might test next...this is pretty much blocking me, no pun intended. Does anyone have any ideas? Something I could try to generate more information? I've attached some data about the ignored packet, if that helps. Thanks muchly...! [HERE'S THE PACKET THAT WOULD NOT BUMP THE recvall() OUT OF BLOCK STATE, EVEN THOUGH NETCAT OF UDP PACKETS TO PORT 8567 ON THIS MACHINE WORKED FINE] Frame 5 (346 bytes on wire, 346 bytes captured) Arrival Time: Jan 29, 2008 20:31:36.492649000 Time delta from previous packet: 4.249231000 seconds Time since reference or first frame: 12.623832000 seconds Frame Number: 5 Packet Length: 346 bytes Capture Length: 346 bytes Frame is marked: False Protocols in frame: eth:ip:udp:data Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: SystemAA_00:1f:a2 (00:00:37:00:1f:a2), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ...1 .... .... .... .... = IG bit: Group address (multicast/ broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: SystemAA_00:1f:a2 (00:00:37:00:1f:a2) Address: SystemAA_00:1f:a2 (00:00:37:00:1f:a2) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Frame check sequence: 0x22b03d15 [correct] Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 328 Identification: 0x0001 (1) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x79a5 [correct] Good: True Bad : False Source: 0.0.0.0 (0.0.0.0) Destination: 255.255.255.255 (255.255.255.255) User Datagram Protocol, Src Port: 8568 (8568), Dst Port: oap-admin (8567) Source port: 8568 (8568) Destination port: oap-admin (8567) Length: 308 Checksum: 0x42e8 [correct] Good Checksum: True Bad Checksum: False Data (300 bytes) 0000 ff ff ff ff ff ff 00 00 37 00 1f a2 08 00 45 00 ........7.....E. 0010 01 48 00 01 00 00 40 11 79 a5 00 00 00 00 ff ff .H....@.y....... 0020 ff ff 21 78 21 77 01 34 42 e8 01 01 06 00 e9 73 ..!x!w.4B......s 0030 ff a2 00 00 80 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 00 00 00 00 00 00 00 00 37 00 1f a2 00 00 00 00 ........7....... 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0110 00 00 00 00 00 00 63 82 53 63 35 01 01 37 09 36 ......c.Sc5..7.6 0120 33 3a 3b 01 03 06 0f 1c 39 02 02 40 ff 00 00 00 3:;.....9..@.... 0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0150 00 00 00 00 00 00 22 b0 3d 15 ......".=. This email sent to site_archiver(a)lists.apple.com

1 0