From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 00:12:58 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7590C1065670; Mon, 28 Mar 2011 00:12:58 +0000 (UTC) Date: Mon, 28 Mar 2011 00:12:58 +0000 From: Alexander Best To: freebsd-bluetooth@freebsd.org Message-ID: <20110328001258.GA70156@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline Subject: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 00:12:58 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, i've just noticed the -f switch to l2ping(8) doesn't require super-user privileges. wouldn't this allow a regular user to flood any bluetooth device with massive ping requests? thus i believe making the -f switch only accessable to super-users (in accordance with ping(8)/ping6(8)) would increase security. i've attached a patch which implements this functionality in addition to some other minor corrections to the l2ping(8) C source and man page. cheers. alex -- a13x --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="l2ping.diff" diff --git a/usr.sbin/bluetooth/l2ping/l2ping.8 b/usr.sbin/bluetooth/l2ping/l2ping.8 index 477f4ec..1b1d30b 100644 --- a/usr.sbin/bluetooth/l2ping/l2ping.8 +++ b/usr.sbin/bluetooth/l2ping/l2ping.8 @@ -25,7 +25,7 @@ .\" $Id: l2ping.8,v 1.3 2003/05/21 01:00:19 max Exp $ .\" $FreeBSD$ .\" -.Dd June 14, 2002 +.Dd March 28, 2011 .Dt L2PING 8 .Os .Sh NAME @@ -36,7 +36,7 @@ .Op Fl fhn .Fl a Ar remote .Op Fl c Ar count -.Op Fl i Ar delay +.Op Fl i Ar wait .Op Fl S Ar source .Op Fl s Ar size .Sh DESCRIPTION @@ -65,6 +65,7 @@ will operate until interrupted. .It Fl f .Dq Flood ping, i.e., no delay between packets. +Only the super-user may use this option. .It Fl h Display usage message and exit. .It Fl i Ar wait @@ -109,7 +110,7 @@ Some implementations may not like large sizes and may hang or even crash. .Xr ng_l2cap 4 , .Xr l2control 8 .Sh AUTHORS -.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com +.An Maksim Yevmenkin Aq emax@FreeBSD.org .Sh BUGS Could collect more statistic. Could check for duplicated, corrupted and lost packets. diff --git a/usr.sbin/bluetooth/l2ping/l2ping.c b/usr.sbin/bluetooth/l2ping/l2ping.c index d7e1b1e..2978afd 100644 --- a/usr.sbin/bluetooth/l2ping/l2ping.c +++ b/usr.sbin/bluetooth/l2ping/l2ping.c @@ -31,6 +31,7 @@ #include #include +#include #include #include #include @@ -106,6 +107,8 @@ main(int argc, char *argv[]) break; case 'f': + if (getuid()) + errx(1, "Must be superuser to flood ping"); flood = 1; break; @@ -272,8 +275,8 @@ tv2msec(struct timeval const *tvp) static void usage(void) { - fprintf(stderr, "Usage: l2ping -a bd_addr " \ - "[-S bd_addr -c count -i wait -n -s size -h]\n"); + fprintf(stderr, "Usage: l2ping [-fhn] -a remote " \ + "[-c count] [-i wait] [-S source] [-s size]\n"); fprintf(stderr, "Where:\n"); fprintf(stderr, " -a remote Specify remote device to ping\n"); fprintf(stderr, " -c count Number of packets to send\n"); --Qxx1br4bt0+wmkIi-- From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 06:58:15 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8449E106564A for ; Mon, 28 Mar 2011 06:58:15 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (mail.ukfsn.org [77.75.108.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0C58FC08 for ; Mon, 28 Mar 2011 06:58:15 +0000 (UTC) Received: from localhost (smtp-filter.ukfsn.org [192.168.54.205]) by mail.ukfsn.org (Postfix) with ESMTP id 7D0B9DEC1E; Mon, 28 Mar 2011 07:58:13 +0100 (BST) Received: from mail.ukfsn.org ([192.168.54.25]) by localhost (smtp-filter.ukfsn.org [192.168.54.205]) (amavisd-new, port 10024) with ESMTP id D6r8KZDr1KHj; Mon, 28 Mar 2011 07:58:13 +0100 (BST) Received: from galant.ukfsn.org (unknown [89.195.130.65]) by mail.ukfsn.org (Postfix) with ESMTP id 0BEA0DEC19; Mon, 28 Mar 2011 07:58:12 +0100 (BST) Received: by galant.ukfsn.org (Postfix, from userid 1000) id 12E5E26015B; Mon, 28 Mar 2011 07:57:59 +0100 (BST) Date: Mon, 28 Mar 2011 07:57:58 +0100 (BST) From: Iain Hibbert To: Alexander Best In-Reply-To: <20110328001258.GA70156@freebsd.org> Message-ID: References: <20110328001258.GA70156@freebsd.org> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 06:58:15 -0000 On Mon, 28 Mar 2011, Alexander Best wrote: > thus i believe making the -f switch only accessable to super-users (in > accordance with ping(8)/ping6(8)) would increase security. what stops the user from recompiling l2ping without this restriction? iain From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 10:18:04 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id EA51E1065670; Mon, 28 Mar 2011 10:18:04 +0000 (UTC) Date: Mon, 28 Mar 2011 10:18:04 +0000 From: Alexander Best To: Iain Hibbert Message-ID: <20110328101804.GA39095@freebsd.org> References: <20110328001258.GA70156@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:18:05 -0000 On Mon Mar 28 11, Iain Hibbert wrote: > On Mon, 28 Mar 2011, Alexander Best wrote: > > > thus i believe making the -f switch only accessable to super-users (in > > accordance with ping(8)/ping6(8)) would increase security. > > what stops the user from recompiling l2ping without this restriction? nothing. but what stops him from recompiling ping(8) or ping6(8) without the restriction? still it's there. if an admin is concerned that users may be bringing in foreign code or change existing code, he should not give them access to compilers/assembler on the system imo. > > iain -- a13x From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 14:04:54 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF18106564A; Mon, 28 Mar 2011 14:04:54 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (mail.ukfsn.org [77.75.108.10]) by mx1.freebsd.org (Postfix) with ESMTP id D3B308FC1B; Mon, 28 Mar 2011 14:04:53 +0000 (UTC) Received: from localhost (smtp-filter.ukfsn.org [192.168.54.205]) by mail.ukfsn.org (Postfix) with ESMTP id 3CFA7DEBFA; Mon, 28 Mar 2011 15:04:52 +0100 (BST) Received: from mail.ukfsn.org ([192.168.54.25]) by localhost (smtp-filter.ukfsn.org [192.168.54.205]) (amavisd-new, port 10024) with ESMTP id L3m1ouofPb9L; Mon, 28 Mar 2011 15:04:52 +0100 (BST) Received: from galant.ukfsn.org (unknown [89.195.130.65]) by mail.ukfsn.org (Postfix) with ESMTP id 95493DEBD8; Mon, 28 Mar 2011 15:04:51 +0100 (BST) Received: by galant.ukfsn.org (Postfix, from userid 1000) id 45F9226015B; Mon, 28 Mar 2011 15:04:29 +0100 (BST) Date: Mon, 28 Mar 2011 15:04:29 +0100 (BST) From: Iain Hibbert To: Alexander Best In-Reply-To: <20110328101804.GA39095@freebsd.org> Message-ID: References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:04:54 -0000 On Mon, 28 Mar 2011, Alexander Best wrote: > On Mon Mar 28 11, Iain Hibbert wrote: > > On Mon, 28 Mar 2011, Alexander Best wrote: > > > > > thus i believe making the -f switch only accessable to super-users (in > > > accordance with ping(8)/ping6(8)) would increase security. > > > > what stops the user from recompiling l2ping without this restriction? > > nothing. but what stops him from recompiling ping(8) or ping6(8) without the > restriction? still it's there. AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats why ping is traditionally a suid program and making a new binary won't help normal users.. I'm guessing that l2ping doesn't have the same restrictions? iain From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 18:40:43 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8453F1065678 for ; Mon, 28 Mar 2011 18:40:43 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B38B8FC22 for ; Mon, 28 Mar 2011 18:40:42 +0000 (UTC) Received: by iyj12 with SMTP id 12so4889537iyj.13 for ; Mon, 28 Mar 2011 11:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CjZEoZXxSMFkHjkglUsJc0XhSf68b1k3DM1RfTYlN4w=; b=gkKWeO7LXYYd6nJGZ9onLpxtiMEiTHlQ2oX0nnnz5OSc0j+4nBfATBW0MfkOUKmLva UkPXveVA/UcOIheV39PVylqooDhBtJEEybmvLVN9zVXINBBICbFH3WJuYfjsCodlPS5q KEHmk9Wm9J05fhiInyrkJyAluE5oX3LHTG3N4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eYhOsqhrI+MxiPOPj8NbIVnxQMZeDuOgiFzV3xhhpJl/qqNEWhi4Xou782Qh+mxlDE 5w4lxltApYj4+G+osBSgREN0+cHz8WDuLvGlQYZr0p38jIrdu+Bv7ZnelA8IoO+ijLg+ PrMhgv4QFOo7vlYCaARIWHkP/sNDwTMhgMWXg= MIME-Version: 1.0 Received: by 10.43.55.131 with SMTP id vy3mr6518964icb.521.1301337642629; Mon, 28 Mar 2011 11:40:42 -0700 (PDT) Received: by 10.42.166.71 with HTTP; Mon, 28 Mar 2011 11:40:42 -0700 (PDT) In-Reply-To: References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> Date: Mon, 28 Mar 2011 11:40:42 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert , Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 18:40:43 -0000 On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: > On Mon, 28 Mar 2011, Alexander Best wrote: > >> On Mon Mar 28 11, Iain Hibbert wrote: >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> > >> > > thus i believe making the -f switch only accessable to super-users (in >> > > accordance with ping(8)/ping6(8)) would increase security. >> > >> > what stops the user from recompiling l2ping without this restriction? >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the >> restriction? still it's there. > > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats > why ping is traditionally a suid program and making a new binary won't > help normal users.. I'm guessing that l2ping doesn't have the same > restrictions? Guys, first of all thanks for the patch. i think one really needs to understand what "flood" really means in l2ping(8). "flood" ping(8) basically floods the link with icmp echo requests without waiting for remote system to reply. yes, this is potentially dangerous and thus its reasonable to require super-user privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is "flood" mode 1) sends l2cap echo request 2) waits for l2cap echo response (or timeout) 3) repeats in other words, there is no delay between each l2cap echo request-response transaction. its not really "flood". i'm not sure if it really worth to go all the way to restricting this. however, if people think that it should be restricted, i will not object. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 19:59:52 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1F8101065672; Mon, 28 Mar 2011 19:59:52 +0000 (UTC) Date: Mon, 28 Mar 2011 19:59:52 +0000 From: Alexander Best To: Maksim Yevmenkin Message-ID: <20110328195952.GA26987@freebsd.org> References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 19:59:52 -0000 On Mon Mar 28 11, Maksim Yevmenkin wrote: > On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: > > On Mon, 28 Mar 2011, Alexander Best wrote: > > > >> On Mon Mar 28 11, Iain Hibbert wrote: > >> > On Mon, 28 Mar 2011, Alexander Best wrote: > >> > > >> > > thus i believe making the -f switch only accessable to super-users (in > >> > > accordance with ping(8)/ping6(8)) would increase security. > >> > > >> > what stops the user from recompiling l2ping without this restriction? > >> > >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the > >> restriction? still it's there. > > > > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats > > why ping is traditionally a suid program and making a new binary won't > > help normal users.. I'm guessing that l2ping doesn't have the same > > restrictions? > > Guys, > > first of all thanks for the patch. > > i think one really needs to understand what "flood" really means in > l2ping(8). "flood" ping(8) basically floods the link with icmp echo > requests without waiting for remote system to reply. yes, this is > potentially dangerous and thus its reasonable to require super-user > privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is > "flood" mode > > 1) sends l2cap echo request > 2) waits for l2cap echo response (or timeout) > 3) repeats > > in other words, there is no delay between each l2cap echo > request-response transaction. its not really "flood". i'm not sure if > it really worth to go all the way to restricting this. however, if > people think that it should be restricted, i will not object. how about removing the term "flood" from the l2ping(2) man page, if the -f semantics can't actually be called that way? > > thanks, > max -- a13x From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 20:04:32 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24FB4106564A; Mon, 28 Mar 2011 20:04:32 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D28468FC17; Mon, 28 Mar 2011 20:04:31 +0000 (UTC) Received: by iwn33 with SMTP id 33so4924860iwn.13 for ; Mon, 28 Mar 2011 13:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CjVO2tRbFHrReu/MWj0xlK4GQ6qD+ZBdOJi6xCcZYoA=; b=OFWxI1udhqObKVlsbK7D7Th+w7Mhb7qx8Lcwk1LUN5yPPTCN3vRx4rX8bZiyrJ5oNx lsKjIX0vLwp1Q601tirkDlnokemp0gUkjY/1t3sHc9rhugw/ZNTXZfdGT22FbE85Fsox TUp/mA6CjwCgcTmtYLMPpsqI7pF5OoH3VHc3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ofVOa6G1EJZa5w4nXWc31HLpsqGYZmJidN9Mal5KmTSkbFw7Xr89JYA380WKhxEvT0 SiOx6sAKHIAqO+9QEUfeSMx3hyziTqafYElukc5YPHxMzhaL+y1O8zY4Kj3iXDDXZxdh OFH0fjDXCeGzf0n//gHpaEl2asWRdiMBF+tQ0= MIME-Version: 1.0 Received: by 10.43.60.205 with SMTP id wt13mr7385508icb.253.1301342670992; Mon, 28 Mar 2011 13:04:30 -0700 (PDT) Received: by 10.42.166.71 with HTTP; Mon, 28 Mar 2011 13:04:30 -0700 (PDT) In-Reply-To: <20110328195952.GA26987@freebsd.org> References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> Date: Mon, 28 Mar 2011 13:04:30 -0700 Message-ID: From: Maksim Yevmenkin To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:04:32 -0000 On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> > >> >> On Mon Mar 28 11, Iain Hibbert wrote: >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> >> > >> >> > > thus i believe making the -f switch only accessable to super-users (in >> >> > > accordance with ping(8)/ping6(8)) would increase security. >> >> > >> >> > what stops the user from recompiling l2ping without this restriction? >> >> >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the >> >> restriction? still it's there. >> > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats >> > why ping is traditionally a suid program and making a new binary won't >> > help normal users.. I'm guessing that l2ping doesn't have the same >> > restrictions? >> >> Guys, >> >> first of all thanks for the patch. >> >> i think one really needs to understand what "flood" really means in >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo >> requests without waiting for remote system to reply. yes, this is >> potentially dangerous and thus its reasonable to require super-user >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is >> "flood" mode >> >> 1) sends l2cap echo request >> 2) waits for l2cap echo response (or timeout) >> 3) repeats >> >> in other words, there is no delay between each l2cap echo >> request-response transaction. its not really "flood". i'm not sure if >> it really worth to go all the way to restricting this. however, if >> people think that it should be restricted, i will not object. > > how about removing the term "flood" from the l2ping(2) man page, if the -f > semantics can't actually be called that way? that would be fine. l2ping(8) -h calls it -f No delay (sort of flood) and l2ping(8) man page calls it -f ``Flood'' ping, i.e., no delay between packets. it would be nice to make those consistent :) i'm not sure what the best name would be though. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 20:34:14 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0C32B106566C; Mon, 28 Mar 2011 20:34:14 +0000 (UTC) Date: Mon, 28 Mar 2011 20:34:14 +0000 From: Alexander Best To: Maksim Yevmenkin Message-ID: <20110328203413.GB26987@freebsd.org> References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:34:14 -0000 On Mon Mar 28 11, Maksim Yevmenkin wrote: > On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: > > On Mon Mar 28 11, Maksim Yevmenkin wrote: > >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: > >> > On Mon, 28 Mar 2011, Alexander Best wrote: > >> > > >> >> On Mon Mar 28 11, Iain Hibbert wrote: > >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: > >> >> > > >> >> > > thus i believe making the -f switch only accessable to super-users (in > >> >> > > accordance with ping(8)/ping6(8)) would increase security. > >> >> > > >> >> > what stops the user from recompiling l2ping without this restriction? > >> >> > >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the > >> >> restriction? still it's there. > >> > > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats > >> > why ping is traditionally a suid program and making a new binary won't > >> > help normal users.. I'm guessing that l2ping doesn't have the same > >> > restrictions? > >> > >> Guys, > >> > >> first of all thanks for the patch. > >> > >> i think one really needs to understand what "flood" really means in > >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo > >> requests without waiting for remote system to reply. yes, this is > >> potentially dangerous and thus its reasonable to require super-user > >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is > >> "flood" mode > >> > >> 1) sends l2cap echo request > >> 2) waits for l2cap echo response (or timeout) > >> 3) repeats > >> > >> in other words, there is no delay between each l2cap echo > >> request-response transaction. its not really "flood". i'm not sure if > >> it really worth to go all the way to restricting this. however, if > >> people think that it should be restricted, i will not object. > > > > how about removing the term "flood" from the l2ping(2) man page, if the -f > > semantics can't actually be called that way? > > that would be fine. l2ping(8) -h calls it > > -f No delay (sort of flood) > > and l2ping(8) man page calls it > > -f ``Flood'' ping, i.e., no delay between packets. > > it would be nice to make those consistent :) i'm not sure what the > best name would be though. another possibility would be to allow l2ping -i 0 and say that the -f flag is an alias for that. > > thanks, > max -- a13x From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 21:37:46 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A50691065674; Mon, 28 Mar 2011 21:37:46 +0000 (UTC) Date: Mon, 28 Mar 2011 21:37:46 +0000 From: Alexander Best To: Maksim Yevmenkin Message-ID: <20110328213746.GA42088@freebsd.org> References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> <20110328203413.GB26987@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20110328203413.GB26987@freebsd.org> Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:37:46 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon Mar 28 11, Alexander Best wrote: > On Mon Mar 28 11, Maksim Yevmenkin wrote: > > On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: > > > On Mon Mar 28 11, Maksim Yevmenkin wrote: > > >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: > > >> > On Mon, 28 Mar 2011, Alexander Best wrote: > > >> > > > >> >> On Mon Mar 28 11, Iain Hibbert wrote: > > >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: > > >> >> > > > >> >> > > thus i believe making the -f switch only accessable to super-users (in > > >> >> > > accordance with ping(8)/ping6(8)) would increase security. > > >> >> > > > >> >> > what stops the user from recompiling l2ping without this restriction? > > >> >> > > >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the > > >> >> restriction? still it's there. > > >> > > > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats > > >> > why ping is traditionally a suid program and making a new binary won't > > >> > help normal users.. I'm guessing that l2ping doesn't have the same > > >> > restrictions? > > >> > > >> Guys, > > >> > > >> first of all thanks for the patch. > > >> > > >> i think one really needs to understand what "flood" really means in > > >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo > > >> requests without waiting for remote system to reply. yes, this is > > >> potentially dangerous and thus its reasonable to require super-user > > >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is > > >> "flood" mode > > >> > > >> 1) sends l2cap echo request > > >> 2) waits for l2cap echo response (or timeout) > > >> 3) repeats > > >> > > >> in other words, there is no delay between each l2cap echo > > >> request-response transaction. its not really "flood". i'm not sure if > > >> it really worth to go all the way to restricting this. however, if > > >> people think that it should be restricted, i will not object. > > > > > > how about removing the term "flood" from the l2ping(2) man page, if the -f > > > semantics can't actually be called that way? > > > > that would be fine. l2ping(8) -h calls it > > > > -f No delay (sort of flood) > > > > and l2ping(8) man page calls it > > > > -f ``Flood'' ping, i.e., no delay between packets. > > > > it would be nice to make those consistent :) i'm not sure what the > > best name would be though. > > another possibility would be to allow l2ping -i 0 and say that the -f flag is > an alias for that. the following patch will implement this behavior. > > > > > thanks, > > max > > -- > a13x -- a13x --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="l2ping.diff" diff --git a/usr.sbin/bluetooth/l2ping/l2ping.8 b/usr.sbin/bluetooth/l2ping/l2ping.8 index 477f4ec..7ff2942 100644 --- a/usr.sbin/bluetooth/l2ping/l2ping.8 +++ b/usr.sbin/bluetooth/l2ping/l2ping.8 @@ -25,7 +25,7 @@ .\" $Id: l2ping.8,v 1.3 2003/05/21 01:00:19 max Exp $ .\" $FreeBSD$ .\" -.Dd June 14, 2002 +.Dd March 28, 2011 .Dt L2PING 8 .Os .Sh NAME @@ -36,7 +36,7 @@ .Op Fl fhn .Fl a Ar remote .Op Fl c Ar count -.Op Fl i Ar delay +.Op Fl i Ar wait .Op Fl S Ar source .Op Fl s Ar size .Sh DESCRIPTION @@ -63,8 +63,8 @@ If this option is not specified, .Nm will operate until interrupted. .It Fl f -.Dq Flood -ping, i.e., no delay between packets. +Alias for +.Fl i Ar 0 . .It Fl h Display usage message and exit. .It Fl i Ar wait @@ -109,7 +109,7 @@ Some implementations may not like large sizes and may hang or even crash. .Xr ng_l2cap 4 , .Xr l2control 8 .Sh AUTHORS -.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com +.An Maksim Yevmenkin Aq emax@FreeBSD.org .Sh BUGS Could collect more statistic. Could check for duplicated, corrupted and lost packets. diff --git a/usr.sbin/bluetooth/l2ping/l2ping.c b/usr.sbin/bluetooth/l2ping/l2ping.c index d7e1b1e..b01ac7d 100644 --- a/usr.sbin/bluetooth/l2ping/l2ping.c +++ b/usr.sbin/bluetooth/l2ping/l2ping.c @@ -111,7 +111,7 @@ main(int argc, char *argv[]) case 'i': wait = atoi(optarg); - if (wait <= 0) + if (wait < 0) usage(); break; @@ -221,7 +221,7 @@ main(int argc, char *argv[]) tv2msec(&b), r.result, ((fail == 0)? "" : strerror(errno))); - if (!flood) { + if (!flood && wait) { /* Wait */ a.tv_sec = wait; a.tv_usec = 0; @@ -272,12 +272,12 @@ tv2msec(struct timeval const *tvp) static void usage(void) { - fprintf(stderr, "Usage: l2ping -a bd_addr " \ - "[-S bd_addr -c count -i wait -n -s size -h]\n"); + fprintf(stderr, "Usage: l2ping [-fhn] -a remote " \ + "[-c count] [-i wait] [-S source] [-s size]\n"); fprintf(stderr, "Where:\n"); fprintf(stderr, " -a remote Specify remote device to ping\n"); fprintf(stderr, " -c count Number of packets to send\n"); - fprintf(stderr, " -f No delay (sort of flood)\n"); + fprintf(stderr, " -f Alias for -i 0\n"); fprintf(stderr, " -h Display this message\n"); fprintf(stderr, " -i wait Delay between packets (sec)\n"); fprintf(stderr, " -n Numeric output only\n"); --bg08WKrSYDhXBjb5-- From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 21:44:45 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 614AA106564A; Mon, 28 Mar 2011 21:44:45 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 11E968FC0A; Mon, 28 Mar 2011 21:44:44 +0000 (UTC) Received: by iyj12 with SMTP id 12so5096341iyj.13 for ; Mon, 28 Mar 2011 14:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SG8jpKvrQ8LX1s2AIhRXbdAXuqmoKqXM6LMV4fSp8qs=; b=dnVI9KLclSFZtOWpuNzI4WQUg27QaDoXFGfxSM2WvrLbFXjl8YYiNk3ayrbGSMr4rF 0WDeOlMYQ93hGTfOXgC18u5tRsuuYgkt10AvXJ3beZ9iEjK01VoB5O+WM080sfUGsyO+ zw6IN5CFenHfVQ4ijAdF5lxRRvoxCbkVtHG0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cCFrytDVEIkjS8IULkzEVOnpaDnbgJXQHHHVfjVLJhL2AnkIqMJuJCahmF5i0dbjKZ eCOudcceILwQIVfvAgexJqzCYjI9Ur5Fg/HSmhwZRzBqI1uLQyv7HPkNpqfl8V+bKUlG fpLYbAPuNCS02w+o8t1R4uKL3X/mCJgzZf1RU= MIME-Version: 1.0 Received: by 10.43.53.6 with SMTP id vo6mr1939164icb.387.1301348684452; Mon, 28 Mar 2011 14:44:44 -0700 (PDT) Received: by 10.42.166.71 with HTTP; Mon, 28 Mar 2011 14:44:44 -0700 (PDT) In-Reply-To: <20110328213746.GA42088@freebsd.org> References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> <20110328203413.GB26987@freebsd.org> <20110328213746.GA42088@freebsd.org> Date: Mon, 28 Mar 2011 14:44:44 -0700 Message-ID: From: Maksim Yevmenkin To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:44:45 -0000 On Mon, Mar 28, 2011 at 2:37 PM, Alexander Best wrote: > On Mon Mar 28 11, Alexander Best wrote: >> On Mon Mar 28 11, Maksim Yevmenkin wrote: >> > On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: >> > > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> > >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: >> > >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> > >> > >> > >> >> On Mon Mar 28 11, Iain Hibbert wrote: >> > >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> > >> >> > >> > >> >> > > thus i believe making the -f switch only accessable to super-users (in >> > >> >> > > accordance with ping(8)/ping6(8)) would increase security. >> > >> >> > >> > >> >> > what stops the user from recompiling l2ping without this restriction? >> > >> >> >> > >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the >> > >> >> restriction? still it's there. >> > >> > >> > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats >> > >> > why ping is traditionally a suid program and making a new binary won't >> > >> > help normal users.. I'm guessing that l2ping doesn't have the same >> > >> > restrictions? >> > >> >> > >> Guys, >> > >> >> > >> first of all thanks for the patch. >> > >> >> > >> i think one really needs to understand what "flood" really means in >> > >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo >> > >> requests without waiting for remote system to reply. yes, this is >> > >> potentially dangerous and thus its reasonable to require super-user >> > >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is >> > >> "flood" mode >> > >> >> > >> 1) sends l2cap echo request >> > >> 2) waits for l2cap echo response (or timeout) >> > >> 3) repeats >> > >> >> > >> in other words, there is no delay between each l2cap echo >> > >> request-response transaction. its not really "flood". i'm not sure if >> > >> it really worth to go all the way to restricting this. however, if >> > >> people think that it should be restricted, i will not object. >> > > >> > > how about removing the term "flood" from the l2ping(2) man page, if the -f >> > > semantics can't actually be called that way? >> > >> > that would be fine. l2ping(8) -h calls it >> > >> > -f No delay (sort of flood) >> > >> > and l2ping(8) man page calls it >> > >> > -f ``Flood'' ping, i.e., no delay between packets. >> > >> > it would be nice to make those consistent :) i'm not sure what the >> > best name would be though. >> >> another possibility would be to allow l2ping -i 0 and say that the -f flag is >> an alias for that. the existing code provides exactly this behavior. perhaps just a man page and usage() change? > the following patch will implement this behavior. if we are going to go this route then why not just get rid of the "flood" variable all together? just set wait to 0 (zero) if -f was specified. also, we should probably use strtol(3) instead of atoi(3). thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 21:55:03 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4B9B11065670; Mon, 28 Mar 2011 21:55:03 +0000 (UTC) Date: Mon, 28 Mar 2011 21:55:03 +0000 From: Alexander Best To: Maksim Yevmenkin Message-ID: <20110328215503.GA43845@freebsd.org> References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> <20110328203413.GB26987@freebsd.org> <20110328213746.GA42088@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:55:03 -0000 On Mon Mar 28 11, Maksim Yevmenkin wrote: > On Mon, Mar 28, 2011 at 2:37 PM, Alexander Best wrote: > > On Mon Mar 28 11, Alexander Best wrote: > >> On Mon Mar 28 11, Maksim Yevmenkin wrote: > >> > On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: > >> > > On Mon Mar 28 11, Maksim Yevmenkin wrote: > >> > >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: > >> > >> > On Mon, 28 Mar 2011, Alexander Best wrote: > >> > >> > > >> > >> >> On Mon Mar 28 11, Iain Hibbert wrote: > >> > >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: > >> > >> >> > > >> > >> >> > > thus i believe making the -f switch only accessable to super-users (in > >> > >> >> > > accordance with ping(8)/ping6(8)) would increase security. > >> > >> >> > > >> > >> >> > what stops the user from recompiling l2ping without this restriction? > >> > >> >> > >> > >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the > >> > >> >> restriction? still it's there. > >> > >> > > >> > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats > >> > >> > why ping is traditionally a suid program and making a new binary won't > >> > >> > help normal users.. I'm guessing that l2ping doesn't have the same > >> > >> > restrictions? > >> > >> > >> > >> Guys, > >> > >> > >> > >> first of all thanks for the patch. > >> > >> > >> > >> i think one really needs to understand what "flood" really means in > >> > >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo > >> > >> requests without waiting for remote system to reply. yes, this is > >> > >> potentially dangerous and thus its reasonable to require super-user > >> > >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is > >> > >> "flood" mode > >> > >> > >> > >> 1) sends l2cap echo request > >> > >> 2) waits for l2cap echo response (or timeout) > >> > >> 3) repeats > >> > >> > >> > >> in other words, there is no delay between each l2cap echo > >> > >> request-response transaction. its not really "flood". i'm not sure if > >> > >> it really worth to go all the way to restricting this. however, if > >> > >> people think that it should be restricted, i will not object. > >> > > > >> > > how about removing the term "flood" from the l2ping(2) man page, if the -f > >> > > semantics can't actually be called that way? > >> > > >> > that would be fine. l2ping(8) -h calls it > >> > > >> > -f No delay (sort of flood) > >> > > >> > and l2ping(8) man page calls it > >> > > >> > -f ``Flood'' ping, i.e., no delay between packets. > >> > > >> > it would be nice to make those consistent :) i'm not sure what the > >> > best name would be though. > >> > >> another possibility would be to allow l2ping -i 0 and say that the -f flag is > >> an alias for that. > > the existing code provides exactly this behavior. perhaps just a man > page and usage() change? hmmm...no actually. l2ping -i 0 is not a valid parameter, since -i has to be greater than 0. so it's not possible to simply say "-f is an alias for -i 0", because that implies that -i 0 should work (which it doesn't). > > > the following patch will implement this behavior. > > if we are going to go this route then why not just get rid of the > "flood" variable all together? just set wait to 0 (zero) if -f was > specified. also, we should probably use strtol(3) instead of atoi(3). i've thought of that. however that would mean l2ping -f -i 3 would set the delay to 3 seconds and usually an -f switch implies "force". so i think the current behavior of -f having a higher priority than any -i X option should be kept. > > thanks, > max -- a13x From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 22:12:35 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AFDB106564A; Mon, 28 Mar 2011 22:12:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id F01B68FC19; Mon, 28 Mar 2011 22:12:34 +0000 (UTC) Received: by iyj12 with SMTP id 12so5128072iyj.13 for ; Mon, 28 Mar 2011 15:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WKA66QZ+iLGgiHpHO5wsUfE0tj5pSaEf6av7MQKgRSE=; b=XasYglMHxxM6taY/n6lwlINn8jhcHiWm0b/2wLNCg+Aquv4LarpPSrZ2PYl99YOxMG u9e5czc/XUV0m7vrC25jvrY0sNoJuPrJtQnQLCd1W2WW1GaaEc0l09lhSd+f7J0y7sUc 65VrFwRQl9a8de3nAxKQXAM70Kt6Q6CK/n5wk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JykY1oeoFK00v6MkvpUR03AsgB/1pX6OM+HDWkTeYrX8/vs71u4Ce06tBjc+NWg9UK kqOURvBXLOvL2KKYUh10Xf4NHNzO2ZYO2UdeZrcG3SYjWNtdXeKW9BbMfiz+leUTpbaP C0plkidOwMDZJtrZ36NGBt0FCKYL0/E++x2bw= MIME-Version: 1.0 Received: by 10.43.55.81 with SMTP id vx17mr7872226icb.52.1301350354220; Mon, 28 Mar 2011 15:12:34 -0700 (PDT) Received: by 10.42.166.71 with HTTP; Mon, 28 Mar 2011 15:12:34 -0700 (PDT) In-Reply-To: <20110328215503.GA43845@freebsd.org> References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> <20110328203413.GB26987@freebsd.org> <20110328213746.GA42088@freebsd.org> <20110328215503.GA43845@freebsd.org> Date: Mon, 28 Mar 2011 15:12:34 -0700 Message-ID: From: Maksim Yevmenkin To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:12:35 -0000 On Mon, Mar 28, 2011 at 2:55 PM, Alexander Best wrote: > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> On Mon, Mar 28, 2011 at 2:37 PM, Alexander Best wrote: >> > On Mon Mar 28 11, Alexander Best wrote: >> >> On Mon Mar 28 11, Maksim Yevmenkin wrote: >> >> > On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: >> >> > > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> >> > >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: >> >> > >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> >> > >> > >> >> > >> >> On Mon Mar 28 11, Iain Hibbert wrote: >> >> > >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> >> > >> >> > >> >> > >> >> > > thus i believe making the -f switch only accessable to super-users (in >> >> > >> >> > > accordance with ping(8)/ping6(8)) would increase security. >> >> > >> >> > >> >> > >> >> > what stops the user from recompiling l2ping without this restriction? >> >> > >> >> >> >> > >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the >> >> > >> >> restriction? still it's there. >> >> > >> > >> >> > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats >> >> > >> > why ping is traditionally a suid program and making a new binary won't >> >> > >> > help normal users.. I'm guessing that l2ping doesn't have the same >> >> > >> > restrictions? >> >> > >> >> >> > >> Guys, >> >> > >> >> >> > >> first of all thanks for the patch. >> >> > >> >> >> > >> i think one really needs to understand what "flood" really means in >> >> > >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo >> >> > >> requests without waiting for remote system to reply. yes, this is >> >> > >> potentially dangerous and thus its reasonable to require super-user >> >> > >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is >> >> > >> "flood" mode >> >> > >> >> >> > >> 1) sends l2cap echo request >> >> > >> 2) waits for l2cap echo response (or timeout) >> >> > >> 3) repeats >> >> > >> >> >> > >> in other words, there is no delay between each l2cap echo >> >> > >> request-response transaction. its not really "flood". i'm not sure if >> >> > >> it really worth to go all the way to restricting this. however, if >> >> > >> people think that it should be restricted, i will not object. >> >> > > >> >> > > how about removing the term "flood" from the l2ping(2) man page, if the -f >> >> > > semantics can't actually be called that way? >> >> > >> >> > that would be fine. l2ping(8) -h calls it >> >> > >> >> > -f No delay (sort of flood) >> >> > >> >> > and l2ping(8) man page calls it >> >> > >> >> > -f ``Flood'' ping, i.e., no delay between packets. >> >> > >> >> > it would be nice to make those consistent :) i'm not sure what the >> >> > best name would be though. >> >> >> >> another possibility would be to allow l2ping -i 0 and say that the -f flag is >> >> an alias for that. >> >> the existing code provides exactly this behavior. perhaps just a man >> page and usage() change? > > hmmm...no actually. l2ping -i 0 is not a valid parameter, since -i has to be > greater than 0. so it's not possible to simply say "-f is an alias for -i 0", > because that implies that -i 0 should work (which it doesn't). well, don't call it an "alias" then :) call it "effectively -i 0", "no delay" or something like that :) >> > the following patch will implement this behavior. >> >> if we are going to go this route then why not just get rid of the >> "flood" variable all together? just set wait to 0 (zero) if -f was >> specified. also, we should probably use strtol(3) instead of atoi(3). > > i've thought of that. however that would mean l2ping -f -i 3 would set the > delay to 3 seconds and usually an -f switch implies "force". so i think the > current behavior of -f having a higher priority than any -i X option should be > kept. i think that this is not worthy of long discussion :) i agree that word 'flood' is not appropriate and/or confusing. all the patches provided were fine, imo. please make a decision and commit the best (in your opinion) fix. thank you max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 22:52:08 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2AD0E1065678; Mon, 28 Mar 2011 22:52:08 +0000 (UTC) Date: Mon, 28 Mar 2011 22:52:08 +0000 From: Alexander Best To: Maksim Yevmenkin Message-ID: <20110328225208.GA51932@freebsd.org> References: <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> <20110328203413.GB26987@freebsd.org> <20110328213746.GA42088@freebsd.org> <20110328215503.GA43845@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:52:08 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon Mar 28 11, Maksim Yevmenkin wrote: > On Mon, Mar 28, 2011 at 2:55 PM, Alexander Best wrote: > > On Mon Mar 28 11, Maksim Yevmenkin wrote: > >> On Mon, Mar 28, 2011 at 2:37 PM, Alexander Best wrote: > >> > On Mon Mar 28 11, Alexander Best wrote: > >> >> On Mon Mar 28 11, Maksim Yevmenkin wrote: > >> >> > On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: > >> >> > > On Mon Mar 28 11, Maksim Yevmenkin wrote: > >> >> > >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: > >> >> > >> > On Mon, 28 Mar 2011, Alexander Best wrote: > >> >> > >> > > >> >> > >> >> On Mon Mar 28 11, Iain Hibbert wrote: > >> >> > >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: > >> >> > >> >> > > >> >> > >> >> > > thus i believe making the -f switch only accessable to super-users (in > >> >> > >> >> > > accordance with ping(8)/ping6(8)) would increase security. > >> >> > >> >> > > >> >> > >> >> > what stops the user from recompiling l2ping without this restriction? > >> >> > >> >> > >> >> > >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the > >> >> > >> >> restriction? still it's there. > >> >> > >> > > >> >> > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats > >> >> > >> > why ping is traditionally a suid program and making a new binary won't > >> >> > >> > help normal users.. I'm guessing that l2ping doesn't have the same > >> >> > >> > restrictions? > >> >> > >> > >> >> > >> Guys, > >> >> > >> > >> >> > >> first of all thanks for the patch. > >> >> > >> > >> >> > >> i think one really needs to understand what "flood" really means in > >> >> > >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo > >> >> > >> requests without waiting for remote system to reply. yes, this is > >> >> > >> potentially dangerous and thus its reasonable to require super-user > >> >> > >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is > >> >> > >> "flood" mode > >> >> > >> > >> >> > >> 1) sends l2cap echo request > >> >> > >> 2) waits for l2cap echo response (or timeout) > >> >> > >> 3) repeats > >> >> > >> > >> >> > >> in other words, there is no delay between each l2cap echo > >> >> > >> request-response transaction. its not really "flood". i'm not sure if > >> >> > >> it really worth to go all the way to restricting this. however, if > >> >> > >> people think that it should be restricted, i will not object. > >> >> > > > >> >> > > how about removing the term "flood" from the l2ping(2) man page, if the -f > >> >> > > semantics can't actually be called that way? > >> >> > > >> >> > that would be fine. l2ping(8) -h calls it > >> >> > > >> >> > -f No delay (sort of flood) > >> >> > > >> >> > and l2ping(8) man page calls it > >> >> > > >> >> > -f ``Flood'' ping, i.e., no delay between packets. > >> >> > > >> >> > it would be nice to make those consistent :) i'm not sure what the > >> >> > best name would be though. > >> >> > >> >> another possibility would be to allow l2ping -i 0 and say that the -f flag is > >> >> an alias for that. > >> > >> the existing code provides exactly this behavior. perhaps just a man > >> page and usage() change? > > > > hmmm...no actually. l2ping -i 0 is not a valid parameter, since -i has to be > > greater than 0. so it's not possible to simply say "-f is an alias for -i 0", > > because that implies that -i 0 should work (which it doesn't). > > well, don't call it an "alias" then :) call it "effectively -i 0", "no > delay" or something like that :) > > >> > the following patch will implement this behavior. > >> > >> if we are going to go this route then why not just get rid of the > >> "flood" variable all together? just set wait to 0 (zero) if -f was > >> specified. also, we should probably use strtol(3) instead of atoi(3). > > > > i've thought of that. however that would mean l2ping -f -i 3 would set the > > delay to 3 seconds and usually an -f switch implies "force". so i think the > > current behavior of -f having a higher priority than any -i X option should be > > kept. > > i think that this is not worthy of long discussion :) i agree that > word 'flood' is not appropriate and/or confusing. all the patches > provided were fine, imo. please make a decision and commit the best > (in your opinion) fix. sorry, but i don't own a src commit bit. however i think the following patch should be fine. i've also eliminated a few var = NULL, since they're all being initialised properly and unconditionally at some point. also the defenitions didn't apply to style(9). plus i've converted all the atoi() calls to strtol() calls. cheers. alex > > thank you > > max -- a13x --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="l2ping.diff" diff --git a/usr.sbin/bluetooth/l2ping/l2ping.8 b/usr.sbin/bluetooth/l2ping/l2ping.8 index 477f4ec..703b0bd 100644 --- a/usr.sbin/bluetooth/l2ping/l2ping.8 +++ b/usr.sbin/bluetooth/l2ping/l2ping.8 @@ -25,7 +25,7 @@ .\" $Id: l2ping.8,v 1.3 2003/05/21 01:00:19 max Exp $ .\" $FreeBSD$ .\" -.Dd June 14, 2002 +.Dd March 29, 2011 .Dt L2PING 8 .Os .Sh NAME @@ -36,7 +36,7 @@ .Op Fl fhn .Fl a Ar remote .Op Fl c Ar count -.Op Fl i Ar delay +.Op Fl i Ar wait .Op Fl S Ar source .Op Fl s Ar size .Sh DESCRIPTION @@ -63,8 +63,7 @@ If this option is not specified, .Nm will operate until interrupted. .It Fl f -.Dq Flood -ping, i.e., no delay between packets. +Don't wait between sending each packet. .It Fl h Display usage message and exit. .It Fl i Ar wait @@ -109,7 +108,7 @@ Some implementations may not like large sizes and may hang or even crash. .Xr ng_l2cap 4 , .Xr l2control 8 .Sh AUTHORS -.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com +.An Maksim Yevmenkin Aq emax@FreeBSD.org .Sh BUGS Could collect more statistic. Could check for duplicated, corrupted and lost packets. diff --git a/usr.sbin/bluetooth/l2ping/l2ping.c b/usr.sbin/bluetooth/l2ping/l2ping.c index d7e1b1e..4baa354 100644 --- a/usr.sbin/bluetooth/l2ping/l2ping.c +++ b/usr.sbin/bluetooth/l2ping/l2ping.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include #include @@ -60,11 +61,11 @@ int main(int argc, char *argv[]) { bdaddr_t src, dst; - struct hostent *he = NULL; - uint8_t *echo_data = NULL; + struct hostent *he; + uint8_t *echo_data; struct sockaddr_l2cap sa; int32_t n, s, count, wait, flood, echo_size, numeric; - char *rname = NULL; + char *endp, *rname; /* Set defaults */ memcpy(&src, NG_HCI_BDADDR_ANY, sizeof(src)); @@ -100,8 +101,8 @@ main(int argc, char *argv[]) break; case 'c': - count = atoi(optarg); - if (count <= 0) + count = strtol(optarg, &endp, 10); + if (count <= 0 || *endp != '\0') usage(); break; @@ -110,8 +111,8 @@ main(int argc, char *argv[]) break; case 'i': - wait = atoi(optarg); - if (wait <= 0) + wait = strtol(optarg, &endp, 10); + if (wait <= 0 || *endp != '\0') usage(); break; @@ -129,9 +130,10 @@ main(int argc, char *argv[]) break; case 's': - echo_size = atoi(optarg); - if (echo_size < sizeof(int32_t) || - echo_size > NG_L2CAP_MAX_ECHO_SIZE) + echo_size = strtol(optarg, &endp, 10); + if (echo_size < sizeof(int32_t) || + echo_size > NG_L2CAP_MAX_ECHO_SIZE || + *endp != '\0') usage(); break; @@ -272,12 +274,12 @@ tv2msec(struct timeval const *tvp) static void usage(void) { - fprintf(stderr, "Usage: l2ping -a bd_addr " \ - "[-S bd_addr -c count -i wait -n -s size -h]\n"); + fprintf(stderr, "Usage: l2ping [-fhn] -a remote " \ + "[-c count] [-i wait] [-S source] [-s size]\n"); fprintf(stderr, "Where:\n"); fprintf(stderr, " -a remote Specify remote device to ping\n"); fprintf(stderr, " -c count Number of packets to send\n"); - fprintf(stderr, " -f No delay (sort of flood)\n"); + fprintf(stderr, " -f No delay between packets\n"); fprintf(stderr, " -h Display this message\n"); fprintf(stderr, " -i wait Delay between packets (sec)\n"); fprintf(stderr, " -n Numeric output only\n"); --UlVJffcvxoiEqYs2-- From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 23:08:45 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 992B01065672; Mon, 28 Mar 2011 23:08:45 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4BBE28FC21; Mon, 28 Mar 2011 23:08:45 +0000 (UTC) Received: by iyj12 with SMTP id 12so5186761iyj.13 for ; Mon, 28 Mar 2011 16:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jLl8j/v2jbbFl6yacgCtFWXZ+uy3h2tUFSpukm6DNoA=; b=FPn+SlbZyRGWLKM5qNHvz1S6iKFb9x/wPdOcZ241jXzk6mxZIEijz6leYcA0Irlvl/ ivTaNs6j9czu0HfmE5c2c0euqxr/5BPsL2AgMvnD+QHzJ3FsolLZV7QGVnp0NV3EVcWz oi/8pomYXuP0aFmv3KbfBWzs7xZ/1SWbAThVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QmVOTQ/SVerZiHMWOpvfQ5HRHlTZuFK7tSnWGM2LPW2HLw+JkAu68Pm0yIJWaY3/b7 xk0ID73fwQUP15FlYA+Q+u0CztD7vsE8i1aY/RoAeL8WFwVKKlzfZbCI+mE8L0WEV14G bDwtU07Kvr3SUQTxEyrNNaZxgHbi2nfXfkyBA= MIME-Version: 1.0 Received: by 10.43.60.205 with SMTP id wt13mr7657691icb.253.1301353724684; Mon, 28 Mar 2011 16:08:44 -0700 (PDT) Received: by 10.42.166.71 with HTTP; Mon, 28 Mar 2011 16:08:44 -0700 (PDT) In-Reply-To: <20110328225208.GA51932@freebsd.org> References: <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> <20110328203413.GB26987@freebsd.org> <20110328213746.GA42088@freebsd.org> <20110328215503.GA43845@freebsd.org> <20110328225208.GA51932@freebsd.org> Date: Mon, 28 Mar 2011 16:08:44 -0700 Message-ID: From: Maksim Yevmenkin To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:08:45 -0000 On Mon, Mar 28, 2011 at 3:52 PM, Alexander Best wrote: > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> On Mon, Mar 28, 2011 at 2:55 PM, Alexander Best wrote: >> > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> >> On Mon, Mar 28, 2011 at 2:37 PM, Alexander Best wrote: >> >> > On Mon Mar 28 11, Alexander Best wrote: >> >> >> On Mon Mar 28 11, Maksim Yevmenkin wrote: >> >> >> > On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: >> >> >> > > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> >> >> > >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: >> >> >> > >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> >> >> > >> > >> >> >> > >> >> On Mon Mar 28 11, Iain Hibbert wrote: >> >> >> > >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> >> >> > >> >> > >> >> >> > >> >> > > thus i believe making the -f switch only accessable to super-users (in >> >> >> > >> >> > > accordance with ping(8)/ping6(8)) would increase security. >> >> >> > >> >> > >> >> >> > >> >> > what stops the user from recompiling l2ping without this restriction? >> >> >> > >> >> >> >> >> > >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the >> >> >> > >> >> restriction? still it's there. >> >> >> > >> > >> >> >> > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats >> >> >> > >> > why ping is traditionally a suid program and making a new binary won't >> >> >> > >> > help normal users.. I'm guessing that l2ping doesn't have the same >> >> >> > >> > restrictions? >> >> >> > >> >> >> >> > >> Guys, >> >> >> > >> >> >> >> > >> first of all thanks for the patch. >> >> >> > >> >> >> >> > >> i think one really needs to understand what "flood" really means in >> >> >> > >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo >> >> >> > >> requests without waiting for remote system to reply. yes, this is >> >> >> > >> potentially dangerous and thus its reasonable to require super-user >> >> >> > >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is >> >> >> > >> "flood" mode >> >> >> > >> >> >> >> > >> 1) sends l2cap echo request >> >> >> > >> 2) waits for l2cap echo response (or timeout) >> >> >> > >> 3) repeats >> >> >> > >> >> >> >> > >> in other words, there is no delay between each l2cap echo >> >> >> > >> request-response transaction. its not really "flood". i'm not sure if >> >> >> > >> it really worth to go all the way to restricting this. however, if >> >> >> > >> people think that it should be restricted, i will not object. >> >> >> > > >> >> >> > > how about removing the term "flood" from the l2ping(2) man page, if the -f >> >> >> > > semantics can't actually be called that way? >> >> >> > >> >> >> > that would be fine. l2ping(8) -h calls it >> >> >> > >> >> >> > -f No delay (sort of flood) >> >> >> > >> >> >> > and l2ping(8) man page calls it >> >> >> > >> >> >> > -f ``Flood'' ping, i.e., no delay between packets. >> >> >> > >> >> >> > it would be nice to make those consistent :) i'm not sure what the >> >> >> > best name would be though. >> >> >> >> >> >> another possibility would be to allow l2ping -i 0 and say that the -f flag is >> >> >> an alias for that. >> >> >> >> the existing code provides exactly this behavior. perhaps just a man >> >> page and usage() change? >> > >> > hmmm...no actually. l2ping -i 0 is not a valid parameter, since -i has to be >> > greater than 0. so it's not possible to simply say "-f is an alias for -i 0", >> > because that implies that -i 0 should work (which it doesn't). >> >> well, don't call it an "alias" then :) call it "effectively -i 0", "no >> delay" or something like that :) >> >> >> > the following patch will implement this behavior. >> >> >> >> if we are going to go this route then why not just get rid of the >> >> "flood" variable all together? just set wait to 0 (zero) if -f was >> >> specified. also, we should probably use strtol(3) instead of atoi(3). >> > >> > i've thought of that. however that would mean l2ping -f -i 3 would set the >> > delay to 3 seconds and usually an -f switch implies "force". so i think the >> > current behavior of -f having a higher priority than any -i X option should be >> > kept. >> >> i think that this is not worthy of long discussion :) i agree that >> word 'flood' is not appropriate and/or confusing. all the patches >> provided were fine, imo. please make a decision and commit the best >> (in your opinion) fix. > > sorry, but i don't own a src commit bit. however i think the following patch > should be fine. i've also eliminated a few var = NULL, since they're all being > initialised properly and unconditionally at some point. also the defenitions > didn't apply to style(9). plus i've converted all the atoi() calls to strtol() > calls. committed, thanks! max