Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754012Ab2HPMIu (ORCPT ); Thu, 16 Aug 2012 08:08:50 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:62123 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752574Ab2HPMIt (ORCPT ); Thu, 16 Aug 2012 08:08:49 -0400 Message-ID: <502CDD8C.3000006@landley.net> Date: Thu, 16 Aug 2012 06:46:20 -0500 From: Rob Landley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dirk Gouders CC: Milton Miller , Borislav Petkov , Cong Wang , Jesse Barnes , Jan Engelhardt , Linux Kernel Subject: Re: [RFC] netconsole.txt: "nc" needs "-p" to specify the listening port References:

<501937F7.2070600@landley.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5975 Lines: 154 On 08/02/2012 03:39 PM, Dirk Gouders wrote: > Dirk Gouders writes: > >> Rob Landley writes: >> >>> On 07/29/2012 03:40 AM, Milton Miller wrote: >>>> [adding Rob as Doc maintanier] >>>> >>>> On Sat, 28 Jul 2012 about 11:08:16 -0000, Dirk Gouders wrote: >>>>> Borislav Petkov writes: >>>>> >>>>>> On Fri, Jul 27, 2012 at 11:24:53AM +0200, Dirk Gouders wrote: >>>>>>> Cong Wang writes: >>>>>>> >>>>>>>> On Fri, Jul 27, 2012 at 2:35 PM, Dirk Gouders >>>>>>>> wrote: >>>>>>>>> Hi Jesse, >>>>>>>>> >>>>>>>>> I would like to ask you to check if the documentation of "nc" in >>>>>>>>> netconsole.txt is still correct. I tried two different netcat packages >>>>>>>>> and both require "-p" to specify the listening port. I am wondering if >>>>>>>>> that changed after the use of "nc" has been documented. >>>>>>>> >>>>>>>> On Fedora 16, `nc -u -l ` works fine. >>>>>>> >>>>>>> Thanks for checking that. >>>>>>> >>>>>>> If the information I found is correct, Fedora uses OpenBSD's nc >>>>>>> codebase. The two netcat packages I tested on a Gentoo system differ in >>>>>>> requiring the -p switch for the port specification. >>>>>> >>>>>> So say exactly that in the doc: that the *BSD's version of nc doesn't >>>>>> need the port number specified with '-p' and you're covered. >>>>> OK, I tried that in the attached patch. >>>>> I'm not sure if every exeption needs to/should be documented, though. >>>>> >>>>> >From 3cdeac3e814471053129145c5fa8391acb365fd8 Mon Sep 17 00:00:00 2001 >>>>> From: Dirk Gouders >>>>> Date: Sat, 28 Jul 2012 12:32:49 +0200 >>>>> Subject: [PATCH] netconsole.txt: non-BSD versions of nc(1) require '-p' >>>>> switch >>>>> >>>>> Gentoo for example uses non-BSD versions of nc(1) which require >>>>> the '-p' switch to specify the listening port. >>>>> >>>>> --- >>>>> Documentation/networking/netconsole.txt | 3 ++- >>>>> 1 files changed, 2 insertions(+), 1 deletions(-) >>> >>> Did this ever resolve to a specific recommended patch? The one at the >>> start of the thread: >>> >>> http://lkml.indiana.edu/hypermail/linux/kernel/1207.3/01995.html >>> >>> Apparently isn't it...? >> >> Sorry for the delay. >> I tested the situation on a few distributions and am still thinking >> about a proper way to write it in a way without netconsole.txt becoming >> a kind of "netcat.txt". >> >> I would be glad about comments to what I currently have -- also, because >> I am not a native English speaker: >> >> ------------------------------------------------------------------------ >> The remote host can run syslogd or netcat to receive the kernel >> messages. On distributions using a BSD-based netcat version >> (e.g. Fedora, openSUSE and Ubuntu) the listening port must be >> specified without the -p switch: >> >> 'nc -u -l -p ' / 'nc -u -l ' or >> 'netcat -u -l -p ' / 'netcat -u -l ' >> ------------------------------------------------------------------------ >> >> At the end, I also attach what I have noted during the tests with the >> different distributions. >> >> Dirk >> >> ------------------------------------------------------------------------ >> Problem on systems where the gnu-netcat package provides a symbolic >> link /usr/bin/nc -> /usr/bin/netcat: >> >> gnu-netcat requires -p to specify the local port but does not complain >> if invoked as `nc -l -u '; you need to use -v to see that it >> does not do what you might expect: >> >> # nc -l -u 4444 -v >> Warning: Inverse name lookup failed for `0.0.17.92' >> ------------------------------------------------------------------------ >> >> Distro Package needs -p >> Command invocation >> ======================================================================== >> Arch gnu-netcat yes >> (Website nc | netcat >> documentation) >> openbsd-netcat no >> nc.openbsd >> ------------------------------------------------------------------------ >> Debian-6.0.5 netcat-openbsd no >> nc | netcat | nc.openbsd >> >> netcat / netcat-traditional (preinstalled) yes >> nc | netcat >> >> netcat6 yes >> nc | netcat | nc6 >> ------------------------------------------------------------------------ >> Fedora-17 nc (preinstalled) no >> nc >> >> nc6 >> nc6 yes >> ------------------------------------------------------------------------ >> Gentoo gnu-netcat yes >> netcat >> >> netcat yes >> nc >> >> netcat6 yes >> nc | nc6 >> ------------------------------------------------------------------------ >> OpenSUSE-12.1 netcat-openbsd no >> nc | netcat >> ------------------------------------------------------------------------ >> Ubuntu-12.04 netcat-openbsd (preinstalled) no >> Desktop nc | netcat | nc.openbsd >> >> netcat / netcat-traditional yes >> nc | netcat >> >> netcat6 yes >> nc | netcat | nc6 >> ------------------------------------------------------------------------ > > Here is a patch that also includes Jan's suggestion for socat(1). Or you could use the bash built-in functionality of /dev/udp/host/port with redirection. Or you can write a program to do it using the C API. This seems about as silly as trying to document /proc/sys/vm/drop-caches by listing the various ways you can write to a file. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/