Possible regression from rc3 (check fails when packaging) about aircrack-ng-archive

[ZeroChaos-]

If I were you, I'd check what cflags the debian build system forces that you don't use when you just do a normal make.

Here is what debian uses:

-g -O2 -fdebug-prefix-map=/home/airklast/aircrack-ng-1.2-rc4=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -msse2 -pthread -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -DHAVE_SQLITE -DHAVE_PCRE -DCONFIG_LIBNL30 -DCONFIG_LIBNL -I/usr/include/libnl3 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-array-bounds -msse2 -pthread -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -DHAVE_SQLITE -DHAVE_PCRE -DCONFIG_LIBNL30 -DCONFIG_LIBNL -I/usr/include/libnl3 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-array-bounds -Iinclude -DSIMD_CORE -DUSE_GCRYPT -fPIE -pie -Wl,-z,relro -Wl,-z,now

Here is what I use in gentoo (personally since every gentoo user sets their own):

-Os -mtune=nocona -pipe -frecord-gcc-switches -march=native -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -DHAVE_SQLITE -DHAVE_PCRE -DCONFIG_LIBNL30 -DCONFIG_LIBNL -I/usr/include/libnl3 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-array-bounds -mavx2 -DJOHN_AVX2 -pthread -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -DHAVE_SQLITE -DHAVE_PCRE -DCONFIG_LIBNL30 -DCONFIG_LIBNL -I/usr/include/libnl3 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-array-bounds -Iinclude -DSIMD_CORE -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu

I seem to have the same issues here on gentoo, so possibly -fstack-protector-strong?

[ZeroChaos-]

@samueloph to save myself time troubleshooting, what version of gcc are you using? I'm on 4.93

[samueloph]

@ZeroChaos- I'm using gcc 6.1.1, it's the default for debian unstable and should be too for the next stable.

[ZeroChaos-]

test failure from svn/git (aircrack-ng) is at a much lower rate, but it still seems to happen...

[samueloph]

@ZeroChaos- Yeah! I've found some combination that caused less failures, i don't remeber what it was, this is looking very strange.

[ZeroChaos-]

CI has been intermittently failing since this commit, a very long time ago:

aircrack-ng/aircrack-ng@37af2df

[samueloph]

@ZeroChaos- I've just built a .deb based on aircrack-ng/aircrack-ng@6687414 (the last commit before the one you pointed aircrack-ng/aircrack-ng@37af2df) and i get no failures at all.

Now the problem is finding exactly what is causing this and how to fix it, it looks like it's not gonna be easy.

PS.: Regarding aircrack-ng/aircrack-ng@37af2df, wouldn't be better to just use --march=native instead of introducing bigger changes to detect cpu features? I know this shouldn't be discussed here and now, but it would give better performance and less code to worry (both to upstream and to packagers, as it would be a simply case of dropping the --march flag).

[samueloph]

I have contacted Sophie Brun, the maintainer of aircrack-ng on Kali, and she sent me this ticket that she had opened related to this:
https://trac.aircrack-ng.org/ticket/1680

@ZeroChaos- Should we focus the discussion here or on the ticket? I believe the ticket's priority should be bumped up, it's currently "minor" and Sophie describes that this (the common.cfg described by her) segfaults aircrack-ng.

[ZeroChaos-]

This is all up to @Mister-X-, I'm just trying to help debug what is going on. Honestly, I'm not in love with aircrack-ng/aircrack-ng@37af2df

[aircrack-ng]

I don't think --march=native is a good idea. When creating packages, they have to work on different architectures, CPUs.

@samueloph, could you paste a lscpu? I'm unable to reproduce the issue on any of my machines.

[ZeroChaos-]

travis seems to pretty reliably reproduce the issue... add whatever you want to travis...

[samueloph]

@aircrack-ng Here it goes:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Model name:            Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
Stepping:              9
CPU MHz:               2099.121
CPU max MHz:           3100.0000
CPU min MHz:           1200.0000
BogoMIPS:              4988.83
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072K
NUMA node0 CPU(s):     0-3
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts

But as @ZeroChaos- said, you can try on the Travis build too.

@aircrack-ng @ZeroChaos- Any advices on NOT releasing rc4 on Debian? I'm seriously considering removing the check routine and releasing it, as we still have beta3. I believe there's no fix in the foreseeable future since we're not really sure what's wrong.

I don't think --march=native is a good idea. When creating packages, they have to work on different architectures, CPUs.

I think i don't understand, the current building process generates binaries that doesn't work on on different architectures either. So the best approach wouldn't be to (i'm not criticizing, that's a true question) :

1. Doesn't check any cpu spec at compile time, thus creating a generic binary that works on all cpus.
2. Check cpu spec and compile a cpu-specific binary (march=all), giving the best performance possible.
   From what i see, the current method is between 1 and 2, it creates a somewhat cpu-specific binary but there's some cpu variations allowed, the problem is that it looks like there's a lot of work involved in the nuances of which flags to enable in this case.

[aircrack-ng]

Committed #57: https://trac.aircrack-ng.org/changeset/2868