[Buildroot] [PATCH v2] arp-scan: new package

[Buildroot] [PATCH v2] arp-scan: new package

[Arnout Vandecappelle]

On the br-arm-cortex-m4-full toolchain, the build fails with a
segmentation fault in elf2flt, so add an exception for ARM FLAT
toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
I tried to debug the elf2flt segfault but elf2flt isn't exactly the
most low-entry-bar source code...

v2: ad myself to DEVELOPERS
---
 DEVELOPERS                                         |  1 +
 package/Config.in                                  |  1 +
 ...ry-linking-to-detect-stack-protector-supp.patch | 39 ++++++++++++++++++++++
 package/arp-scan/Config.in                         | 11 ++++++
 package/arp-scan/arp-scan.hash                     |  2 ++
 package/arp-scan/arp-scan.mk                       | 18 ++++++++++
 6 files changed, 72 insertions(+)
 create mode 100644 package/arp-scan/0001-configure-try-linking-to-detect-stack-protector-supp.patch
 create mode 100644 package/arp-scan/Config.in
 create mode 100644 package/arp-scan/arp-scan.hash
 create mode 100644 package/arp-scan/arp-scan.mk

diff --git a/DEVELOPERS b/DEVELOPERS
index c89468b075..76da20b2c6 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -104,6 +104,7 @@ N:	Arnaud Aujon <arnaud@intelibre.fr>
 F:	package/espeak/
 
 N:	Arnout Vandecappelle <arnout@mind.be>
+F:	package/arp-scan/
 F:	package/freescale-imx/firmware-imx/
 F:	package/freescale-imx/imx-lib/
 F:	package/gstreamer/gst-fsl-plugins/
diff --git a/package/Config.in b/package/Config.in
index d6d134d0ca..aa304eb0ff 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -1494,6 +1494,7 @@ menu "Networking applications"
 	source "package/aircrack-ng/Config.in"
 	source "package/apache/Config.in"
 	source "package/argus/Config.in"
+	source "package/arp-scan/Config.in"
 	source "package/arptables/Config.in"
 	source "package/atftp/Config.in"
 	source "package/autossh/Config.in"
diff --git a/package/arp-scan/0001-configure-try-linking-to-detect-stack-protector-supp.patch b/package/arp-scan/0001-configure-try-linking-to-detect-stack-protector-supp.patch
new file mode 100644
index 0000000000..8eb9d6eff4
--- /dev/null
+++ b/package/arp-scan/0001-configure-try-linking-to-detect-stack-protector-supp.patch
@@ -0,0 +1,39 @@
+From f406041b58eadc716d6227408d3af553d566ffeb Mon Sep 17 00:00:00 2001
+From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
+Date: Tue, 4 Apr 2017 17:31:29 +0200
+Subject: [PATCH] configure: try linking to detect stack-protector support
+
+Even if gcc accepts the -fstack-protector argument, it is possible that
+the libssp support library is missing. Detect this by linking instead
+of just compiling.
+
+Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
+---
+ acinclude.m4 | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/acinclude.m4 b/acinclude.m4
+index 3c84118..4725154 100644
+--- a/acinclude.m4
++++ b/acinclude.m4
+@@ -243,7 +243,7 @@ AC_DEFUN([GCC_STACK_PROTECT_CC],[
+     AC_MSG_CHECKING([whether ${CC} accepts -fstack-protector])
+     ssp_old_cflags="$CFLAGS"
+     CFLAGS="$CFLAGS -fstack-protector"
+-    AC_TRY_COMPILE(,,, ssp_cc=no)
++    AC_TRY_LINK(,,, ssp_cc=no)
+     echo $ssp_cc
+     if test "X$ssp_cc" = "Xno"; then
+       CFLAGS="$ssp_old_cflags"
+@@ -259,7 +259,7 @@ AC_DEFUN([GCC_STACK_PROTECT_CXX],[
+     AC_MSG_CHECKING([whether ${CXX} accepts -fstack-protector])
+     ssp_old_cxxflags="$CXXFLAGS"
+     CXXFLAGS="$CXXFLAGS -fstack-protector"
+-    AC_TRY_COMPILE(,,, ssp_cxx=no)
++    AC_TRY_LINK(,,, ssp_cxx=no)
+     echo $ssp_cxx
+     if test "X$ssp_cxx" = "Xno"; then
+         CXXFLAGS="$ssp_old_cxxflags"
+-- 
+2.11.0
+
diff --git a/package/arp-scan/Config.in b/package/arp-scan/Config.in
new file mode 100644
index 0000000000..8fa3235434
--- /dev/null
+++ b/package/arp-scan/Config.in
@@ -0,0 +1,11 @@
+config BR2_PACKAGE_ARP_SCAN
+	bool "arp-scan"
+	depends on !(BR2_arm && BR2_BINFMT_FLAT) # SEGV in elf2flt
+	select BR2_PACKAGE_LIBPCAP
+	help
+	  The ARP scanner
+
+	  arp-scan is a command-line tool that uses the ARP protocol to
+	  discover and fingerprint IP hosts on the local network.
+
+	  http://www.nta-monitor.com/wiki/index.php/Arp-scan_Documentation
diff --git a/package/arp-scan/arp-scan.hash b/package/arp-scan/arp-scan.hash
new file mode 100644
index 0000000000..4b2ddf1816
--- /dev/null
+++ b/package/arp-scan/arp-scan.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256	ce908ac71c48e85dddf6dd4fe5151d13c7528b1f49717a98b2a2535bd797d892	arp-scan-1.9.tar.gz
diff --git a/package/arp-scan/arp-scan.mk b/package/arp-scan/arp-scan.mk
new file mode 100644
index 0000000000..fc3740bf57
--- /dev/null
+++ b/package/arp-scan/arp-scan.mk
@@ -0,0 +1,18 @@
+################################################################################
+#
+# arp-scan
+#
+################################################################################
+
+ARP_SCAN_VERSION = 1.9
+ARP_SCAN_SITE = https://github.com/royhills/arp-scan/releases/download/$(ARP_SCAN_VERSION)
+ARP_SCAN_LICENSE = GPL-3.0+
+ARP_SCAN_LICENSE_FILES = COPYING
+ARP_SCAN_DEPENDENCIES = libpcap
+
+# 0001-configure-try-linking-to-detect-stack-protector-supp.patch touches acinclude.m4
+ARP_SCAN_AUTORECONF = YES
+
+ARP_SCAN_CONF_ENV = pgac_cv_snprintf_long_long_int_format='%lld'
+
+$(eval $(autotools-package))
-- 
2.11.0

[Buildroot] [PATCH v2] arp-scan: new package

[Thomas Petazzoni]

Hello,

On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle
(Essensium/Mind) wrote:
> On the br-arm-cortex-m4-full toolchain, the build fails with a
> segmentation fault in elf2flt, so add an exception for ARM FLAT
> toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> I tried to debug the elf2flt segfault but elf2flt isn't exactly the
> most low-entry-bar source code...

I think we have a regression here, which I would point to the bump of
binutils from 2.26 to 2.27. Indeed, several packages are now causing
segfaults in elf2flt on ARM:

Busybox:

  http://autobuild.buildroot.net/results/475/4758354f0e2f7f127c1a99ef7846eb62f5ce41b5/build-end.log

pcre:

  http://autobuild.buildroot.net/results/68c/68cf951594b0e67b45f8711745c17b93e2fbc03e/build-end.log

and I'm sure the list will grow. So I believe that binutils 2.27
produces binaries that are a bit different, and confuse elf2flt.

Looking at https://github.com/uclinux-dev/elf2flt/commits/master, I
don't see anything that particular stands out.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2] arp-scan: new package

[Thomas Petazzoni]

Hello,

On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle
(Essensium/Mind) wrote:
> On the br-arm-cortex-m4-full toolchain, the build fails with a
> segmentation fault in elf2flt, so add an exception for ARM FLAT
> toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> I tried to debug the elf2flt segfault but elf2flt isn't exactly the
> most low-entry-bar source code...

Applied to master, thanks. However, I've dropped the elf2flt
related exception, since it really isn't a bug with this package, but a
bug with binutils/elf2flt, which we encounter with other packages as
well.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2] arp-scan: new package

[Arnout Vandecappelle]

On 05-04-17 18:34, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle
> (Essensium/Mind) wrote:
>> On the br-arm-cortex-m4-full toolchain, the build fails with a
>> segmentation fault in elf2flt, so add an exception for ARM FLAT
>> toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine.
>>
>> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>> ---
>> I tried to debug the elf2flt segfault but elf2flt isn't exactly the
>> most low-entry-bar source code...
> 
> I think we have a regression here, which I would point to the bump of
> binutils from 2.26 to 2.27. Indeed, several packages are now causing
> segfaults in elf2flt on ARM:
> 
> Busybox:
> 
>   http://autobuild.buildroot.net/results/475/4758354f0e2f7f127c1a99ef7846eb62f5ce41b5/build-end.log
> 
> pcre:
> 
>   http://autobuild.buildroot.net/results/68c/68cf951594b0e67b45f8711745c17b93e2fbc03e/build-end.log
> 
> and I'm sure the list will grow. So I believe that binutils 2.27
> produces binaries that are a bit different, and confuse elf2flt.
> 
> Looking at https://github.com/uclinux-dev/elf2flt/commits/master, I
> don't see anything that particular stands out.

 Since it was caused by the bump of binutils, you should probably look at the
binutils repo, not the elf2flt repo...

 Probably needs bisecting to find the culprit. Or we could try bumping to
current 2_27_branch head and see if it solves the issue.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v2] arp-scan: new package

[Thomas Petazzoni]

Hello,

On Thu, 6 Apr 2017 10:26:58 +0200, Arnout Vandecappelle wrote:

>  Since it was caused by the bump of binutils, you should probably look at the
> binutils repo, not the elf2flt repo...

That was not my reasoning. My reasoning was that the new binutils
version does not have a bug, but generates a binary that is slightly
different than previous binutils version, and elf2flt does not handle
that correctly.

Of course, that's complete guess, but binutils is IMO a much better
maintained set of tools than elf2flt, so I would first and foremost
suspect a bug in elf2flt.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2] arp-scan: new package

[Arnout Vandecappelle]

On 06-04-17 10:33, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 6 Apr 2017 10:26:58 +0200, Arnout Vandecappelle wrote:
> 
>>  Since it was caused by the bump of binutils, you should probably look at the
>> binutils repo, not the elf2flt repo...
> 
> That was not my reasoning. My reasoning was that the new binutils
> version does not have a bug, but generates a binary that is slightly
> different than previous binutils version, and elf2flt does not handle
> that correctly.
> 
> Of course, that's complete guess, but binutils is IMO a much better
> maintained set of tools than elf2flt, so I would first and foremost
> suspect a bug in elf2flt.

 Of course, but it would be a bug that is triggered by a change in binutils.
Looking at the commits in elf2flt is not going to help. And reading elf2flt.c is
a challenge, I would say...

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v2] arp-scan: new package

[Thomas Petazzoni]

Hello,

On Thu, 6 Apr 2017 10:42:38 +0200, Arnout Vandecappelle wrote:

>  Of course, but it would be a bug that is triggered by a change in binutils.
> Looking at the commits in elf2flt is not going to help.

Except if someone has already noticed and fixed the binutils 2.27
compatibility bug.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2] arp-scan: new package

[Waldemar Brodkorb]

Hi Thomas,
Thomas Petazzoni wrote,

> Hello,
> 
> On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle
> (Essensium/Mind) wrote:
> > On the br-arm-cortex-m4-full toolchain, the build fails with a
> > segmentation fault in elf2flt, so add an exception for ARM FLAT
> > toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine.
> > 
> > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> > ---
> > I tried to debug the elf2flt segfault but elf2flt isn't exactly the
> > most low-entry-bar source code...
> 
> I think we have a regression here, which I would point to the bump of
> binutils from 2.26 to 2.27. Indeed, several packages are now causing
> segfaults in elf2flt on ARM:
> 
> Busybox:
> 
>   http://autobuild.buildroot.net/results/475/4758354f0e2f7f127c1a99ef7846eb62f5ce41b5/build-end.log
> 
> pcre:
> 
>   http://autobuild.buildroot.net/results/68c/68cf951594b0e67b45f8711745c17b93e2fbc03e/build-end.log
> 
> and I'm sure the list will grow. So I believe that binutils 2.27
> produces binaries that are a bit different, and confuse elf2flt.
> 
> Looking at https://github.com/uclinux-dev/elf2flt/commits/master, I
> don't see anything that particular stands out.

It seems this is somehow fixed with binutils 2.28. But I have no
idea in which commit(s). Should we blacklist binutils 2.27 for ARM
noMMU?

best regards
 Waldemar

[Buildroot] [PATCH v2] arp-scan: new package

[Arnout Vandecappelle]

On 08-04-17 20:03, Waldemar Brodkorb wrote:
> Hi Thomas,
> Thomas Petazzoni wrote,
> 
>> Hello,
>>
>> On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle
>> (Essensium/Mind) wrote:
>>> On the br-arm-cortex-m4-full toolchain, the build fails with a
>>> segmentation fault in elf2flt, so add an exception for ARM FLAT
>>> toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine.
>>>
>>> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>>> ---
>>> I tried to debug the elf2flt segfault but elf2flt isn't exactly the
>>> most low-entry-bar source code...
>>
>> I think we have a regression here, which I would point to the bump of
>> binutils from 2.26 to 2.27. Indeed, several packages are now causing
>> segfaults in elf2flt on ARM:
>>
>> Busybox:
>>
>>   http://autobuild.buildroot.net/results/475/4758354f0e2f7f127c1a99ef7846eb62f5ce41b5/build-end.log
>>
>> pcre:
>>
>>   http://autobuild.buildroot.net/results/68c/68cf951594b0e67b45f8711745c17b93e2fbc03e/build-end.log
>>
>> and I'm sure the list will grow. So I believe that binutils 2.27
>> produces binaries that are a bit different, and confuse elf2flt.
>>
>> Looking at https://github.com/uclinux-dev/elf2flt/commits/master, I
>> don't see anything that particular stands out.
> 
> It seems this is somehow fixed with binutils 2.28. But I have no
> idea in which commit(s).

 Thanks for the hint! I bisected it to commit 4ba2ef8fbe7. Its parent
024425668d1 fails, but 4ba2ef8fbe7 doesn't.

 Unfortunately, binutils is such a heap of [fill in something unsavoury] that I
have a hard time understanding what that patch could do. I'll see if I can
backport it.

 Regards,
 Arnout

> Should we blacklist binutils 2.27 for ARM
> noMMU?
> 
> best regards
>  Waldemar
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF