From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 18 15:19:12 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8864416A4CE; Tue, 18 Jan 2005 15:19:12 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E8E743D49; Tue, 18 Jan 2005 15:19:11 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000885940.msg; Tue, 18 Jan 2005 15:09:14 +0000 Message-ID: <00be01c4fd71$046adae0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , Date: Tue, 18 Jan 2005 15:18:42 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B9_01C4FD70.FEABE860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Tue, 18 Jan 2005 15:09:14 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Tue, 18 Jan 2005 15:09:17 +0000 Subject: Patch for linux ABI for MSG_NOSIGNAL and out of order tcp packet issue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2005 15:19:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01C4FD70.FEABE860 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit After digging around and getting some information from Alfred at Valve ( the makers of HalfLife ) I've found the reason for HalfLife 2 server ( CounterStrike Source ) crashing when using rcon under FreeBSD. The problem is that although their code was setting MSG_NOSIGNAL on the send() call this was being ignored by the linux ABI. The attached patch checks for MSG_NOSIGNAL and if set enables SO_NOSIGPIPE for the duration of send call. Im not 100% sure this is the way to do it but have confirmed that the patch works on 5.2.1 so if someone could check and commit it that would be great. I'm also investigating an issue where tcp packets from a linux app end up being sent out of order. I don't really know where to start on this one. send() from the linux domain seems to be a clean pass off to the native send so unless the native send also has issues I'm at a loss. I'm still waiting on confirmation of the calls being used by Valve which is causing this behaviour and will post more when I know it. Has anyone else seen this behaviour else where? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_00B9_01C4FD70.FEABE860 Content-Type: application/octet-stream; name="linux_socket.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="linux_socket.c.patch" --- linux_socket.c.orig Tue Jan 18 10:41:32 2005=0A= +++ linux_socket.c Tue Jan 18 11:02:37 2005=0A= @@ -869,5 +869,48 @@=0A= bsd_args.len =3D linux_args.len;=0A= bsd_args.flags =3D linux_args.flags;=0A= - return (osend(td, &bsd_args));=0A= + if ( linux_args.flags & LINUX_MSG_NOSIGNAL )=0A= + {=0A= + /* requested to ignore pipe so set SO_NOSIGPIPE temporarily */=0A= + int ret_send, ret_opt;=0A= + struct setsockopt_args /* {=0A= + int s;=0A= + int level;=0A= + int name;=0A= + caddr_t val;=0A= + int valsize; =0A= + } */ bsd_setsockopt_args;=0A= + caddr_t sg;=0A= + int *nosigpipe;=0A= +=0A= + sg =3D stackgap_init();=0A= + nosigpipe =3D (int *)stackgap_alloc(&sg, sizeof(*nosigpipe));=0A= + *nosigpipe =3D 1;=0A= + bsd_setsockopt_args.s =3D linux_args.s;=0A= + bsd_setsockopt_args.level =3D SOL_SOCKET;=0A= + bsd_setsockopt_args.name =3D SO_NOSIGPIPE;=0A= + bsd_setsockopt_args.val =3D (caddr_t)nosigpipe;=0A= + bsd_setsockopt_args.valsize =3D sizeof(*nosigpipe);=0A= + ret_opt =3D setsockopt(td, &bsd_setsockopt_args);=0A= + if ( -1 =3D=3D ret_opt )=0A= + {=0A= + return ret_opt;=0A= + }=0A= +=0A= + ret_send =3D (osend(td, &bsd_args));=0A= + /* must clear the option */=0A= + *nosigpipe =3D 1;=0A= + bsd_setsockopt_args.val =3D (caddr_t)nosigpipe;=0A= + ret_opt =3D setsockopt(td, &bsd_setsockopt_args);=0A= + if ( -1 =3D=3D ret_send || -1 =3D=3D ret_opt )=0A= + {=0A= + return -1;=0A= + }=0A= +=0A= + return ret_send;=0A= + }=0A= + else=0A= + {=0A= + return (osend(td, &bsd_args));=0A= + }=0A= }=0A= =0A= ------=_NextPart_000_00B9_01C4FD70.FEABE860--