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

Re: X-compling on intel for 10.3 PPC
by Conrad G T Yoder 20 Feb '07

20 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcdUmHixtwJ1mMCLEduMwQARJHiCXA== Thread-topic: X-compling on intel for 10.3 PPC User-agent: Microsoft-Entourage/11.3.3.061214 At 2/14/07 12:58 PM -0500, Rob McKeever <rmckeever(a)apple.com> wrote: > > You might find TechNote 2163 "Building Universal I\/O Kit Drivers" > helpful: > > <http://developer.apple.com/technotes/tn2006/tn2163.html> > > While I realize you're not building a kext, the steps to do this > from inside Xcode are the same. If you're trying to do this from > MAkefiles, you should be able to use Xcode to help you see what you > should be doing for each of the steps. For any who are interested, I found the solution, which is a workaround for an apparent bug in Xcode 2.3 (gcc 4.0.1 build 5341). Not sure if this bug exists in more recent releases. gcc is generating calls to cxa_atexit (which exists only in 10.4 system libs) in C++ code, in spite of the switch '-mmacosx-version-min=10.3' being used. Thanks be to google, I tried the super-ultra-nsa-grade-secret gcc switch '-fno-use-cxa-atexit', and that did the trick. Anyone know offhand if this is fixed in later gcc releases? -Conrad -- Liberty, Equality, Fraternity, Information. _______________________________________________ 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 smime.p7s

1 0

Re: Bug in TCP stack: RST has wrong sequence number?
by Daniel Hartmeier 19 Feb '07

19 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Resent-date: Tue, 20 Feb 2007 00:43:31 +0100 Resent-from: dhartmei(a)benzedrine.cx Resent-message-id: <20070219234331.GG24501(a)insomnia.benzedrine.cx> Resent-to: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.12-2006-07-14 On Mon, Feb 19, 2007 at 09:26:04PM +0100, Axel Rau wrote: > >This is perhaps a corner case in the protocol spec. I'm not sure I > >buy the conclusion above, but it would be good to hear from the > >experts. > > > >As I read 793, the reset is generated with the current state of the > >window as the sequence number. From your trace, it looks like the > >sender (.106) sent data and then immediately reset the connection. > >The last ack from the receiver (.20) was ...252, so using ...252 > >seems right to me (the sender can't assume that the ...290 segment > >was/will be received). Judging from the following resets, the > >stack will use the last-acked sequence number. > Any comments, Daniel? RFC 793 seems to imply that reset generation should be using SND.NXT as sequence number, which isn't the last-acked sequence number, but the next sequence number to be used for further segments. But if we look at how Darwin checks th_seq on reset reception, we see if (thflags & TH_RST) { if ((SEQ_GEQ(th->th_seq, tp->last_ack_sent) && SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) || (tp->rcv_wnd == 0 && tp->last_ack_sent == th->th_seq)) { and there's a difference between this and other BSDs, which use if (tiflags & TH_RST) { if (th->th_seq != tp->last_ack_sent && th->th_seq != tp->rcv_nxt && th->th_seq != (tp->rcv_nxt + 1)) goto drop; This is more strict than the RFC suggests, not allowing the broader range of "whatever is inside the window", but requiring an exact (or at most off-by-one) match, to make RST attacks (guessing sequence numbers) harder. But it also allows last_ack_sent, which at least acknowledges that some stacks use the last-acked sequence number in reset generation. What I don't understand is how Darwin's tcp_output() is intentionally using the last-acked value for reset generation. Looking at tcp_output.c, it does if (len || (flags & (TH_SYN|TH_FIN)) || tp->t_timer[TCPT_PERSIST]) th->th_seq = htonl(tp->snd_nxt); else th->th_seq = htonl(tp->snd_max); And snd_nxt/_max should not be tracking last-acked, but the right edge, i.e. tcp_input() is not updating snd_nxt/_max based on ACKs, but only tcp_output() is updating it, based on segments sent (even if not acknowledged). In our example, the right edge should definitely be ...290, no? Daniel _______________________________________________ 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: Bug in TCP stack: RST has wrong sequence number?
by Axel Rau 19 Feb '07

19 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Am 19.02.2007 um 20:43 schrieb Justin C. Walker: On Feb 19, 2007, at 09:31 , Axel Rau wrote: Hi, Bug ID# 5008062. Axel --------------------------------------------------------------------- Axel Rau, ☀Frankfurt , Germany +49 69 9514 18 0 _______________________________________________ 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… while trying to analyze a problem with hanging Mail.app, which talks to an IMAP server through an OpenBSD firewall, I got some interesting diagnose from Daniel Hartmeier (daniel(a)benzedrine.cx) from the OpenBSD project: I quote from his posting in the OpenBSD pf list: http://marc.theaimsgroup.com/?l=openbsd-pf&m=117176062511692&w=2 and sends a RST. But the sequence number (th_seq) used in the RST is not valid. It should be 2634574290 (past the last segment the client sent), not 2634574252 (past the second-to-last segment, not including the payload in the FIN+PSH). This looks like a bug in the client's TCP/IP stack, and how to fix it depends on the client's OS. IMO, the RST is invalid, and pf is right in blocking it. This is perhaps a corner case in the protocol spec. I'm not sure I buy the conclusion above, but it would be good to hear from the experts. As I read 793, the reset is generated with the current state of the window as the sequence number. From your trace, it looks like the sender (.106) sent data and then immediately reset the connection. The last ack from the receiver (.20) was ...252, so using ...252 seems right to me (the sender can't assume that the ...290 segment was/will be received). Judging from the following resets, the stack will use the last-acked sequence number. Any comments, Daniel? I'd file a bug report, but I'm not convinced the behavior you see is incorrect (from the standard). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Bug in TCP stack: RST has wrong sequence number?
by Justin C. Walker 19 Feb '07

19 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Feb 19, 2007, at 09:31 , Axel Rau wrote: Hi, Client is Darwin 8.8 / Mac OS X 10.4.8. Questions: Is this a known problem? Should I provide more data? Should I file a kernel bug? Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Enhancement of the Director's Income -------- When LuteFisk is outlawed, Only outlaws will have LuteFisk -------- _______________________________________________ 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… while trying to analyze a problem with hanging Mail.app, which talks to an IMAP server through an OpenBSD firewall, I got some interesting diagnose from Daniel Hartmeier (daniel(a)benzedrine.cx) from the OpenBSD project: I quote from his posting in the OpenBSD pf list: http://marc.theaimsgroup.com/?l=openbsd-pf&m=117176062511692&w=2 and sends a RST. But the sequence number (th_seq) used in the RST is not valid. It should be 2634574290 (past the last segment the client sent), not 2634574252 (past the second-to-last segment, not including the payload in the FIN+PSH). This looks like a bug in the client's TCP/IP stack, and how to fix it depends on the client's OS. IMO, the RST is invalid, and pf is right in blocking it. This is perhaps a corner case in the protocol spec. I'm not sure I buy the conclusion above, but it would be good to hear from the experts. As I read 793, the reset is generated with the current state of the window as the sequence number. From your trace, it looks like the sender (.106) sent data and then immediately reset the connection. The last ack from the receiver (.20) was ...252, so using ...252 seems right to me (the sender can't assume that the ...290 segment was/will be received). Judging from the following resets, the stack will use the last-acked sequence number. I'd file a bug report, but I'm not convinced the behavior you see is incorrect (from the standard). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Bug in TCP stack: RST has wrong sequence number?
by Garth Cummings 19 Feb '07

19 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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

Bug in TCP stack: RST has wrong sequence number?
by Axel Rau 19 Feb '07

19 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, Client is Darwin 8.8 / Mac OS X 10.4.8. Questions: Is this a known problem? Should I provide more data? Should I file a kernel bug? 10:17:00.633731 192.168.220.106.49194 > 192.168.221.20.993: S [tcp sum ok] 2634573257:2634573257(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 1476581172 0,sackOK,eol> (DF) (ttl 64, id 24581, len 64) 10:17:00.634253 192.168.221.20.993 > 192.168.220.106.49194: S [tcp sum ok] 1101854058:1101854058(0) ack 2634573258 win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 3164055978 1476581172> (ttl 63, id 57608, len 60) 10:17:00.634448 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573258:2634573258(0) ack 1101854059 win 65535 <nop,nop,timestamp 1476581172 3164055978> (DF) (ttl 64, id 24582, len 52) 10:17:00.635132 192.168.220.106.49194 > 192.168.221.20.993: P 2634573258:2634573398(140) ack 1101854059 win 65535 <nop,nop,timestamp 1476581172 3164055978> (DF) (ttl 64, id 24583, len 192) 10:17:00.670983 192.168.221.20.993 > 192.168.220.106.49194: . [tcp sum ok] 1101854059:1101854059(0) ack 2634573398 win 65535 <nop,nop,timestamp 3164055978 1476581172> (ttl 63, id 48209, len 52) 10:17:00.867819 192.168.221.20.993 > 192.168.220.106.49194: P 1101854059:1101854197(138) ack 2634573398 win 65535 <nop,nop,timestamp 3164055978 1476581172> (ttl 63, id 55328, len 190) 10:17:00.868017 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573398:2634573398(0) ack 1101854197 win 65535 <nop,nop,timestamp 1476581172 3164055978> (DF) (ttl 64, id 24584, len 52) 10:17:00.869397 192.168.220.106.49194 > 192.168.221.20.993: P [tcp sum ok] 2634573398:2634573404(6) ack 1101854197 win 65535 <nop,nop,timestamp 1476581172 3164055978> (DF) (ttl 64, id 24585, len 58) 10:17:00.871208 192.168.221.20.993 > 192.168.220.106.49194: . [tcp sum ok] 1101854197:1101854197(0) ack 2634573404 win 65535 <nop,nop,timestamp 3164055978 1476581172> (ttl 63, id 23338, len 52) 10:17:00.871402 192.168.220.106.49194 > 192.168.221.20.993: P 2634573404:2634573457(53) ack 1101854197 win 65535 <nop,nop,timestamp 1476581172 3164055978> (DF) (ttl 64, id 24586, len 105) 10:17:00.887903 192.168.221.20.993 > 192.168.220.106.49194: P 1101854197:1101854474(277) ack 2634573457 win 65535 <nop,nop,timestamp 3164055978 1476581172> (ttl 63, id 63011, len 329) 10:17:00.888095 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573457:2634573457(0) ack 1101854474 win 65535 <nop,nop,timestamp 1476581172 3164055978> (DF) (ttl 64, id 24588, len 52) 10:17:00.889419 192.168.220.106.49194 > 192.168.221.20.993: P 2634573457:2634573558(101) ack 1101854474 win 65535 <nop,nop,timestamp 1476581172 3164055978> (DF) (ttl 64, id 24589, len 153) 10:17:01.071461 192.168.221.20.993 > 192.168.220.106.49194: . [tcp sum ok] 1101854474:1101854474(0) ack 2634573558 win 65535 <nop,nop,timestamp 3164055979 1476581172> (ttl 63, id 56417, len 52) 10:17:01.374192 192.168.221.20.993 > 192.168.220.106.49194: P 1101854474:1101854527(53) ack 2634573558 win 65535 <nop,nop,timestamp 3164055979 1476581172> (ttl 63, id 6441, len 105) 10:17:01.374358 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573558:2634573558(0) ack 1101854527 win 65535 <nop,nop,timestamp 1476581173 3164055979> (DF) (ttl 64, id 24656, len 52) 10:17:01.375085 192.168.220.106.49194 > 192.168.221.20.993: P 2634573558:2634573611(53) ack 1101854527 win 65535 <nop,nop,timestamp 1476581173 3164055979> (DF) (ttl 64, id 24657, len 105) 10:17:01.375982 192.168.221.20.993 > 192.168.220.106.49194: P 1101854527:1101854724(197) ack 2634573611 win 65535 <nop,nop,timestamp 3164055979 1476581173> (ttl 63, id 12323, len 249) 10:17:01.376221 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573611:2634573611(0) ack 1101854724 win 65535 <nop,nop,timestamp 1476581173 3164055979> (DF) (ttl 64, id 24658, len 52) 10:17:01.377190 192.168.220.106.49194 > 192.168.221.20.993: P 2634573611:2634573664(53) ack 1101854724 win 65535 <nop,nop,timestamp 1476581173 3164055979> (DF) (ttl 64, id 24660, len 105) 10:17:01.471565 192.168.221.20.993 > 192.168.220.106.49194: . [tcp sum ok] 1101854724:1101854724(0) ack 2634573664 win 65535 <nop,nop,timestamp 3164055979 1476581173> (ttl 63, id 33299, len 52) 10:17:01.898550 192.168.221.20.993 > 192.168.220.106.49194: P 1101854724:1101854809(85) ack 2634573664 win 65535 <nop,nop,timestamp 3164055980 1476581173> (ttl 63, id 51829, len 137) 10:17:01.898791 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573664:2634573664(0) ack 1101854809 win 65535 <nop,nop,timestamp 1476581174 3164055980> (DF) (ttl 64, id 24718, len 52) 10:17:02.274974 192.168.220.106.49194 > 192.168.221.20.993: P 2634573664:2634573717(53) ack 1101854809 win 65535 <nop,nop,timestamp 1476581175 3164055980> (DF) (ttl 64, id 24729, len 105) 10:17:02.297482 192.168.221.20.993 > 192.168.220.106.49194: P 1101854809:1101855198(389) ack 2634573717 win 65535 <nop,nop,timestamp 3164055981 1476581175> (ttl 63, id 42604, len 441) 10:17:02.297714 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573717:2634573717(0) ack 1101855198 win 65535 <nop,nop,timestamp 1476581175 3164055981> (DF) (ttl 64, id 24735, len 52) 10:17:03.224143 192.168.220.106.49194 > 192.168.221.20.993: P 2634573717:2634573770(53) ack 1101855198 win 65535 <nop,nop,timestamp 1476581177 3164055981> (DF) (ttl 64, id 24783, len 105) 10:17:03.272199 192.168.221.20.993 > 192.168.220.106.49194: . [tcp sum ok] 1101855198:1101855198(0) ack 2634573770 win 65535 <nop,nop,timestamp 3164055983 1476581177> (ttl 63, id 25096, len 52) 10:17:04.953197 192.168.221.20.993 > 192.168.220.106.49194: P 1101855198:1101855475(277) ack 2634573770 win 65535 <nop,nop,timestamp 3164055986 1476581177> (ttl 63, id 8732, len 329) 10:17:04.953471 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573770:2634573770(0) ack 1101855475 win 65535 <nop,nop,timestamp 1476581181 3164055986> (DF) (ttl 64, id 24798, len 52) 10:17:04.962397 192.168.220.106.49194 > 192.168.221.20.993: P 2634573770:2634573823(53) ack 1101855475 win 65535 <nop,nop,timestamp 1476581181 3164055986> (DF) (ttl 64, id 24813, len 105) 10:17:04.963429 192.168.221.20.993 > 192.168.220.106.49194: P 1101855475:1101855544(69) ack 2634573823 win 65535 <nop,nop,timestamp 3164055986 1476581181> (ttl 63, id 35389, len 121) 10:17:04.963646 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573823:2634573823(0) ack 1101855544 win 65535 <nop,nop,timestamp 1476581181 3164055986> (DF) (ttl 64, id 24814, len 52) 10:17:07.550567 192.168.220.106.49194 > 192.168.221.20.993: P 2634573823:2634573860(37) ack 1101855544 win 65535 <nop,nop,timestamp 1476581186 3164055986> (DF) (ttl 64, id 24975, len 89) 10:17:07.551444 192.168.221.20.993 > 192.168.220.106.49194: P 1101855544:1101855597(53) ack 2634573860 win 65535 <nop,nop,timestamp 3164055992 1476581186> (ttl 63, id 52262, len 105) 10:17:07.551666 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573860:2634573860(0) ack 1101855597 win 65535 <nop,nop,timestamp 1476581186 3164055992> (DF) (ttl 64, id 24976, len 52) 10:17:07.563908 192.168.220.106.49194 > 192.168.221.20.993: P 2634573860:2634573913(53) ack 1101855597 win 65535 <nop,nop,timestamp 1476581186 3164055992> (DF) (ttl 64, id 24996, len 105) 10:17:07.673176 192.168.221.20.993 > 192.168.220.106.49194: . [tcp sum ok] 1101855597:1101855597(0) ack 2634573913 win 65535 <nop,nop,timestamp 3164055992 1476581186> (ttl 63, id 1287, len 52) 10:17:09.485981 192.168.221.20.993 > 192.168.220.106.49194: P 1101855597:1101855874(277) ack 2634573913 win 65535 <nop,nop,timestamp 3164055995 1476581186> (ttl 63, id 10046, len 329) 10:17:09.486189 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573913:2634573913(0) ack 1101855874 win 65535 <nop,nop,timestamp 1476581190 3164055995> (DF) (ttl 64, id 25027, len 52) 10:17:09.496367 192.168.220.106.49194 > 192.168.221.20.993: P 2634573913:2634573966(53) ack 1101855874 win 65535 <nop,nop,timestamp 1476581190 3164055995> (DF) (ttl 64, id 25042, len 105) 10:17:09.497287 192.168.221.20.993 > 192.168.220.106.49194: P 1101855874:1101855943(69) ack 2634573966 win 65535 <nop,nop,timestamp 3164055996 1476581190> (ttl 63, id 16994, len 121) 10:17:09.497438 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634573966:2634573966(0) ack 1101855943 win 65535 <nop,nop,timestamp 1476581190 3164055996> (DF) (ttl 64, id 25043, len 52) 10:17:12.183395 192.168.220.106.49194 > 192.168.221.20.993: P 2634573966:2634574003(37) ack 1101855943 win 65535 <nop,nop,timestamp 1476581195 3164055996> (DF) (ttl 64, id 25496, len 89) 10:17:12.184361 192.168.221.20.993 > 192.168.220.106.49194: P 1101855943:1101855996(53) ack 2634574003 win 65535 <nop,nop,timestamp 3164056001 1476581195> (ttl 63, id 23630, len 105) 10:17:12.184560 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634574003:2634574003(0) ack 1101855996 win 65535 <nop,nop,timestamp 1476581195 3164056001> (DF) (ttl 64, id 25498, len 52) 10:17:12.199688 192.168.220.106.49194 > 192.168.221.20.993: P 2634574003:2634574072(69) ack 1101855996 win 65535 <nop,nop,timestamp 1476581195 3164056001> (DF) (ttl 64, id 25522, len 121) 10:17:12.274259 192.168.221.20.993 > 192.168.220.106.49194: . [tcp sum ok] 1101855996:1101855996(0) ack 2634574072 win 65535 <nop,nop,timestamp 3164056001 1476581195> (ttl 63, id 18949, len 52) 10:17:14.278606 192.168.221.20.993 > 192.168.220.106.49194: P 1101855996:1101856321(325) ack 2634574072 win 65535 <nop,nop,timestamp 3164056005 1476581195> (ttl 63, id 11598, len 377) 10:17:14.278850 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634574072:2634574072(0) ack 1101856321 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25560, len 52) 10:17:14.285932 192.168.220.106.49194 > 192.168.221.20.993: P 2634574072:2634574125(53) ack 1101856321 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25569, len 105) 10:17:14.382776 192.168.221.20.993 > 192.168.220.106.49194: P 1101856321:1101856390(69) ack 2634574125 win 65535 <nop,nop,timestamp 3164056005 1476581199> (ttl 63, id 9556, len 121) 10:17:14.383024 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634574125:2634574125(0) ack 1101856390 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25572, len 52) 10:17:14.386221 192.168.220.106.49194 > 192.168.221.20.993: P 2634574125:2634574178(53) ack 1101856390 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25575, len 105) 10:17:14.387784 192.168.221.20.993 > 192.168.220.106.49194: P 1101856390:1101857451(1061) ack 2634574178 win 65535 <nop,nop,timestamp 3164056005 1476581199> (ttl 63, id 59757, len 1113) 10:17:14.388129 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634574178:2634574178(0) ack 1101857451 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25576, len 52) 10:17:14.388445 192.168.221.20.993 > 192.168.220.106.49194: P 1101857451:1101857520(69) ack 2634574178 win 65535 <nop,nop,timestamp 3164056005 1476581199> (ttl 63, id 44147, len 121) 10:17:14.388648 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634574178:2634574178(0) ack 1101857520 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25577, len 52) 10:17:14.435877 192.168.220.106.49194 > 192.168.221.20.993: P 2634574178:2634574215(37) ack 1101857520 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25612, len 89) 10:17:14.439550 192.168.221.20.993 > 192.168.220.106.49194: P 1101857520:1101857573(53) ack 2634574215 win 65535 <nop,nop,timestamp 3164056005 1476581199> (ttl 63, id 52077, len 105) 10:17:14.439826 192.168.220.106.49194 > 192.168.221.20.993: . [tcp sum ok] 2634574215:2634574215(0) ack 1101857573 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25613, len 52) 10:17:14.441250 192.168.220.106.49194 > 192.168.221.20.993: P 2634574215:2634574252(37) ack 1101857573 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25616, len 89) 10:17:14.443966 192.168.221.20.993 > 192.168.220.106.49194: P 1101857573:1101857674(101) ack 2634574252 win 65535 <nop,nop,timestamp 3164056005 1476581199> (ttl 63, id 63781, len 153) 10:17:14.444212 192.168.220.106.49194 > 192.168.221.20.993: FP 2634574252:2634574289(37) ack 1101857573 win 65535 <nop,nop,timestamp 1476581199 3164056005> (DF) (ttl 64, id 25617, len 89) 10:17:14.444286 192.168.220.106.49194 > 192.168.221.20.993: R [tcp sum ok] 2634574252:2634574252(0) win 0 (ttl 64, id 25618, len 40) 10:17:14.445655 192.168.221.20.993 > 192.168.220.106.49194: P 1101857674:1101857711(37) ack 2634574290 win 65535 <nop,nop,timestamp 3164056005 1476581199> (ttl 63, id 63094, len 89) 10:17:14.445680 192.168.221.20.993 > 192.168.220.106.49194: F [tcp sum ok] 1101857711:1101857711(0) ack 2634574290 win 65535 <nop,nop,timestamp 3164056005 1476581199> (ttl 63, id 34563, len 52) 10:17:14.445793 192.168.220.106.49194 > 192.168.221.20.993: R [tcp sum ok] 2634574290:2634574290(0) win 0 (ttl 64, id 25621, len 40) 10:17:14.445923 192.168.220.106.49194 > 192.168.221.20.993: R [tcp sum ok] 2634574290:2634574290(0) win 0 (ttl 64, id 25622, len 40) Axel --------------------------------------------------------------------- Axel Rau, ☀Frankfurt , Germany +49 69 9514 18 0 _______________________________________________ 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 while trying to analyze a problem with hanging Mail.app, which talks to an IMAP server through an OpenBSD firewall, I got some interesting diagnose from Daniel Hartmeier (daniel(a)benzedrine.cx) from the OpenBSD project: I quote from his posting in the OpenBSD pf list: http://marc.theaimsgroup.com/?l=openbsd-pf&m=117176062511692&w=2 and sends a RST. But the sequence number (th_seq) used in the RST is not valid. It should be 2634574290 (past the last segment the client sent), not 2634574252 (past the second-to-last segment, not including the payload in the FIN+PSH). This looks like a bug in the client's TCP/IP stack, and how to fix it depends on the client's OS. IMO, the RST is invalid, and pf is right in blocking it. Complete trace attached.

1 0

Re: Read-Timeout with Blocking Socket
by Colin Hirsch 19 Feb '07

19 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.9i On Sun, Feb 18, 2007 at 04:51:38PM -0600, Marc Epard wrote: > Call select with a timeout, then, depending on what select returns, > call read. Select() is infinitely better than alarm or setitimer, but I would recommund poll() rather than select(), if possible -- on most systems it's faster, and I believe that it's also easier to use. Regards, Colin _______________________________________________ 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: Regarding running service.
by sharad saxena 19 Feb '07

19 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com 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:references; b=I0Is++GUGA9jkvXoCE0T2lj0m2QY+HcbZ3/MlGcPPms4aUc6QKN1ESegxkVu8jrBACYpDQGOGCDxWYZnY5M8QYVU2qBIctWmII9/ZzHwWNFshsVJ+x683lc3XwBQq+yMHWiv0LyBtKpOmFXwGbo7sc8f3sM0ytHrWzmKNTY9ZoE= _______________________________________________ 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

-mmacosx-version-min and MACOSX_DEPLOYMENT_TARGET
by Conrad G T Yoder 19 Feb '07

19 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcdT14eExeNyar/KEduMwQARJHiCXA== Thread-topic: -mmacosx-version-min and MACOSX_DEPLOYMENT_TARGET User-agent: Microsoft-Entourage/11.3.3.061214 Are the gcc switch "-mmacosx-version-min" and the env var "MACOSX_DEPLOYMENT_TARGET" equivalent in functionality? E.g. is this: gcc-4.0 -mmacosx-version-min=10.3 -isysroot /Developer/SDKs/MacOSX10.3.9.sdk -Wl,-syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk -o test test.c equivalent to MACOSX_DEPLOYMENT_TARGET=10.3 gcc-4.0 -isysroot /Developer/SDKs/MacOSX10.3.9 .sdk -Wl,-syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk -o test test.c ? (assuming that last command is in a makefile) -Conrad -- Beware before - Beware after. _______________________________________________ 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 smime.p7s

1 0

Re: Read-Timeout with Blocking Socket
by Marc Epard 18 Feb '07

18 Feb '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -Marc _______________________________________________ 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… Call select with a timeout, then, depending on what select returns, call read. This email sent to site_archiver(a)lists.apple.com

1 0