Re: PIE and static libraries
On Sun, May 22, 2016 at 08:48:19AM +0200, Andreas Metzler wrote: > https://lintian.debian.org/tags/hardening-no-pie.html says "It is > unlikely to work when compiling static libraries or executables (gcc > -static)." > > However e.g. https://wiki.debian.org/Hardening does not mention this > problem. Is the former incorrect or the latter incomplete? dpkg-buildflags(1) mentions it. https://wiki.debian.org/Hardening doesn't seem like a good place to repeat all things discussed in that manpage. Also, this is a third thread on d-devel@ about PIE and shared libraries for the past week. -- WBR, wRAR signature.asc Description: PGP signature
Re: PIE and static libraries
On Sun, May 22, 2016 at 12:23:59PM +0500, Andrey Rahmatullin wrote: > On Sun, May 22, 2016 at 08:48:19AM +0200, Andreas Metzler wrote: > > https://lintian.debian.org/tags/hardening-no-pie.html says "It is > > unlikely to work when compiling static libraries or executables (gcc > > -static)." > > > > However e.g. https://wiki.debian.org/Hardening does not mention this > > problem. Is the former incorrect or the latter incomplete? > dpkg-buildflags(1) mentions it. https://wiki.debian.org/Hardening doesn't > seem like a good place to repeat all things discussed in that manpage. > > Also, this is a third thread on d-devel@ about PIE and shared libraries > for the past week. Sorry, I was assuming that the problem mentioned is about not being able to compile such static libraries into both shared objects and executables. The part about static executables may be worth mentioning in dpkg-buildflags(1) too (though static executables are not a common thing in the archive). -- WBR, wRAR signature.asc Description: PGP signature
Re: PIE and static libraries
On 05/22/2016 08:48 AM, Andreas Metzler wrote: > https://lintian.debian.org/tags/hardening-no-pie.html says "It is > unlikely to work when compiling static libraries or executables (gcc > -static)." For static libraries, it really depends on what you want to do with them. A static library is just an archive of .o files (similar to tar), nothing more, and linking against a static library is roughly the same as just adding more .o files to the linker line. You can also link a static library into a shared library - the code in the static library is then just copied into the shared library (but the code then must be compiled with -fPIC, as with all other code that is used in shared libraries). It's therefore in possible to generate a static library with code that was compiled with either -fPIC or -fPIE. The question is what you want to use the code for: - code compiled without -fPIC and without -fPIE can be used only in non-PIE executables => a static library containing such code may not be linked into a PIE executable and may not be linked into a shared library - code compiled with -fPIE can be used in any executable but not in shared libraries => if you link -fPIE code into a non-PIE executable, it will work. Note, however, that PIE code is slightly larger and slower than non-PIE code. (The difference is tiny on modern platforms, though, and IMHO worth it w.r.t. hardening.) - code compiled with -fPIC can be used in anything, from shared libraries to executables (PIE or not) => however, -fPIC code is again slightly slower and larger than -fPIE code. On the other hand, if you look at how much functionality of modern systems is in shared libs anyway, IMHO this doesn't matter as much. Also, gcc starting with version 5 has optimized performance of -fPIC even on older x86_32 quite a bit, see [1]. So starting with Stretch, I don't think the performance argument against using PIC code holds much water anymore, even on older platforms. Note, however, that you cannot currently create PIE executables (-pie LDFLAGS) that are fully statically linked (-static linker flag). But you _can_ create executables that use PIE, are dynamically linked binaries (i.e. uses libc.so), but which do link against some static libraries - as long as the code in those static libraries was compiled with either -fPIE or -fPIC. So in the end in boils down to the following: A. From a hardening perspective, any code that is added to static libraries should be compiled with -fPIE if the static library will only ever be used in executables, and with -fPIC if it also might be used in shared libraries. (Although, to be honest, that use case is a bit rarer.) B. From a performance perspective, using non-PIC/PIE code is faster, though not necessarily by much anymore. Personally, I think the benefits gained from using PIE/PIC in hardening trump these performance considerations in a general-purpose distribution such as Debian anytime - but you should be aware of them. Therefore, I would recommend to use at least -fPIE for static libraries, and possibly -fPIC if you think they might be used in other dynamic libraries. Hope that helps. Regards, Christian [1] https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode signature.asc Description: OpenPGP digital signature
Re: PIE and static libraries
On Sun, May 22, 2016 at 10:41:56AM +0200, Christian Seiler wrote: >=> however, -fPIC code is again slightly slower and > larger than -fPIE code. Really? I thought the idea is the same in both modes. > So in the end in boils down to the following: > > A. From a hardening perspective, any code that is added to >static libraries should be compiled with -fPIE if the static >library will only ever be used in executables, and with >-fPIC if it also might be used in shared libraries. >(Although, to be honest, that use case is a bit rarer.) This, of course, assumes all executables using that library will be compiled with -fPIE. > B. From a performance perspective, using non-PIC/PIE code is >faster, though not necessarily by much anymore. It was worth mentioning only for i386 anyway. -- WBR, wRAR signature.asc Description: PGP signature
Re: Bug#824884: netbase: should not recommend ifupdown
On Sat, May 21, 2016 at 10:01:05PM +0200, Guus Sliepen wrote: > About the description of the netbase package though: it currently only > contains for text files in /etc that are seldomly used. For fun I just > purged netbase, and it doesn't really break anything. I wouldn't call it > "necessary infrastucture for basic TCP/IP networking" anymore. Well, getservbyname(3) is used by 945 packages according to codesearch.debian.net, and getprotobyname(3) by 551 packages. Those use /etc/services and /etc/protocols by default AFAIK. Doesn't seem that seldom to me? -- Niko Tyni nt...@debian.org
Re: PIE and static libraries
On 05/22/2016 10:50 AM, Andrey Rahmatullin wrote:
> On Sun, May 22, 2016 at 10:41:56AM +0200, Christian Seiler wrote:
>>=> however, -fPIC code is again slightly slower and
>> larger than -fPIE code.
> Really? I thought the idea is the same in both modes.
Ok, thinking about it again, if you use relro + bindnow, there will
probably be no difference anymore. (But PIC uses PLT when bindnow
is not used, whereas PIE never uses PLT.)
>> So in the end in boils down to the following:
>>
>> A. From a hardening perspective, any code that is added to
>>static libraries should be compiled with -fPIE if the static
>>library will only ever be used in executables, and with
>>-fPIC if it also might be used in shared libraries.
>>(Although, to be honest, that use case is a bit rarer.)
> This, of course, assumes all executables using that library will be
> compiled with -fPIE.
No. You can combine -fPIE code with non-PIE code into a non-PIE
executable:
a.c:
const char *hello = "Hello World";
const char **p_a() { return &hello; }
b.c:
const char **p_a();
const char *p_b() { return *p_a(); }
m.c:
#include
const char *p_b();
int main() { puts(p_b()); return 0; }
gcc -Wall -fno-PIE -c -o a.o a.c
gcc -Wall -fPIE -c -o b.o b.c
gcc -Wall -fno-PIE -c -o m.o m.c
gcc -o m m.o a.o b.o
./m
Hello World
>> B. From a performance perspective, using non-PIC/PIE code is
>>faster, though not necessarily by much anymore.
> It was worth mentioning only for i386 anyway.
Well, there's not only amd64 and i386 - and some other platforms
also show some differences here. But as I said: I would recommend
to use PIE/PIC anyway.
Regards,
Christian
signature.asc
Description: OpenPGP digital signature
Re: Bug#824884: netbase: should not recommend ifupdown
On Sun, May 22, 2016 at 12:00:37PM +0300, Niko Tyni wrote:
> > About the description of the netbase package though: it currently only
> > contains for text files in /etc that are seldomly used. For fun I just
> > purged netbase, and it doesn't really break anything. I wouldn't call it
> > "necessary infrastucture for basic TCP/IP networking" anymore.
>
> Well, getservbyname(3) is used by 945 packages according to
> codesearch.debian.net, and getprotobyname(3) by 551 packages.
> Those use /etc/services and /etc/protocols by default AFAIK.
> Doesn't seem that seldom to me?
Hm, I did not expect that, but according to codesearch.debian.net you
are right. I'm actually stunned by the amount of programs that do
something like:
struct protoent *pe = getprotobyname("TCP");
int s = socket(AF_INET, SOCK_STREAM, pe->p_proto);
...when there is the perfectly fine IPPROTO_TCP. Every time
getprotobyname() or getservbyname() is called, glibc opens
/etc/protocols or /etc/services and parses the whole file. What a waste:
it takes more effort to program it like this, it wastes CPU cycles and
disk IO, and it has more potential to fail.
I would only have expected tools like tcpdump and nmap to actually use
those files.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Re: Bug#824884: netbase: should not recommend ifupdown
On Sun, May 22, 2016 at 11:38:27AM +0200, Guus Sliepen wrote:
> Hm, I did not expect that, but according to codesearch.debian.net you
> are right. I'm actually stunned by the amount of programs that do
> something like:
>
> struct protoent *pe = getprotobyname("TCP");
> int s = socket(AF_INET, SOCK_STREAM, pe->p_proto);
Or that do it completely wrong but accidentily get away with it, like
here:
https://sources.debian.net/src/rfdump/1.6-4/src/tcpconnect.c/?hl=48#L48
Which only works because "IP" maps to 0, which has a special meaning for
socket(), namely to use whatever protocol best matches the domain and
type parameters. I wonder what other horrors lurk in our code.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Re: Bug#824884: netbase: should not recommend ifupdown
Hi, On 22/05/16 10:00, Niko Tyni wrote: > Well, getservbyname(3) is used by 945 packages according to > codesearch.debian.net, and getprotobyname(3) by 551 packages. > Those use /etc/services and /etc/protocols by default AFAIK. > Doesn't seem that seldom to me? I'm probably doing it wrong, but I grep /etc/services at least once a month in figuring out which port numbers I'm looking for a particular service. It's a really handy reference for doing firewall ACLs, etc. What is the upstream source for the /etc/services file? Do we just maintain that in Debian or are updates incorporated from IANA and unofficial port numbers? I think those files would lose a lot of value in the case that they are not up to date. Thanks, Iain.
Re: PIE and static libraries
On 2016-05-22 Christian Seiler wrote: [extensive explanation] > Therefore, I would recommend to use at least -fPIE for static > libraries, and possibly -fPIC if you think they might be used > in other dynamic libraries. > Hope that helps. Yes it does. Thanks for taking the time to explain this. cu Andreas
Re: Debian Installer Stretch Alpha 6 release
Hi, One thing that would be nice to add in the next version of the
debian-installer is brief descriptions of what tasks do for example in
the alpha 6 screen select and install software lots of selections exists
and as some are very good by their names like DebianMultimedia other
ones are not so well explained by their names like Debian Astro. The
descriptions should take up probably no more then one or two lines at
the most. Nick Gawronski
On 5/21/2016 4:13 PM, Cyril Brulebois wrote:
The Debian Installer team[1] is pleased to announce the sixth alpha
release of the installer for Debian 9 "Stretch".
Important changes in this release of the installer
==
* This release fixes the package installation issue which appeared
lately with the previous alpha release (#814343).
* Debian Pure Blends can now be enabled directly from the Software
selection screen. This might change in a later release though
(#758116).
Improvements in this release
* brltty:
- Install MATE desktop by default when brltty is used in d-i.
- Disable auto-detection of Cebra, Albatross, and BrailleMemo
devices in d-i, since they are rare and conflict with other
devices (#782732).
- prebaseconfig: Enable screen reader in KDE.
- prebaseconfig: Support 4th bootline parameter.
- brltty-udeb.udev.rules: Add new USB IDs.
* cdebconf:
- gtk: Auto-scroll when switching between entries.
- text: Print one screen worth of choices, and use +/- to switch
between choices screens (#809739).
* debian-installer:
- Bump linux kernel version from 4.3.0-1 to 4.5.0-2.
* espeakup:
- Add support for multiboard systems: request the user to press
enter at the right time to select a given board.
- Improve language/voice lookup.
- Install MATE desktop by default when espeakup is used in d-i.
* flash-kernel:
- Avoid waiting for Ctrl-c when debconf is running (#791794).
* net-retriever:
- Concentrate on SHA256 now, following archive-side changes.
* netcfg:
- Improve behaviour when user-submitted input contains spaces
(#818611).
- Improve error checking in various places.
* network-console:
- Improve support for multiple addresses (#816600).
* parted:
- Fix problems with LVM and DASD devices (#814076).
* partman-auto:
- Bump space requirements for a lot of recipes (#725642).
* partman-basicfilesystems:
- Call mkfs.ext2 with -F to avoid hangs (#817174).
* partman-ext3:
- Call mkfs.ext[34] with -F to avoid hangs (#767682).
* preseed:
- Invert env-preseed and initrd-preseed so that the former
overrides the latter (#805291).
- url: correctly handle IPv6 addresses (#815166).
* rootskel:
- Add GNU/screen support, when it's available.
* s390-zfcp:
- New component to activate and configure FCP devices (#808041).
* wget:
- Add udeb support, for later user.
* win32-loader:
- Switch signature checking from MD5 to SHA256.
- Improve support for new versions of Windows (#775055).
Hardware support changes
* debian-installer:
- Provide u-boot images for OpenRD.
- Use marvell flavour for orion5x and kirkwood.
- Include mtd-modules in various images.
- Generate image for Seagate Personal Cloud and Seagate NAS.
- Improve armel/orion5x and armel/kirkwood for many different
Buffalo Linkstation devices.
- Add support for Firefly-RK3288.
- Add support for BeagleBoard-X15.
- ARM: sunxi: Add support for the Olimex A20-SOM-EVB.
- Add sata-modules for arm64.
* grub-installer:
- Install grub-xen when installing in a Xen PV guest.
* hw-detect:
- Improve and split harddrive detection into DASD and SCSI
dependency on s390x (#818586).
* libdebian-installer:
- armel: Add various orion5x/kirkwood based Buffalo Linkstation
devices supported by device-tree.
* linux:
- [armhf] usb-modules: Add modules required for BeagleBoard-X15
(#815848).
- [mips*/octeon] udeb: Add ahci_octeon and ahci_platform modules
to sata-modules.
- [arm64] udeb: Add leds-modules package containing leds-gpio
driver.
- [arm64] udeb: Add regulators and SoC modules to core-modules.
- [x86] udeb: Move scsi_transport_fc to scsi-core-modules, since
hv_storvsc now depends on it.
- [armhf] core-modules: Include regulator drivers by default.
- mmc-modules: Include MMC controller drivers by default.
- mmc-modules: Depends on usb-modules.
- usb-modules: Include USB PHY drivers by default.
- udeb: Combine scsi-{common,extra}-modules with scsi-modules.
- udeb: Use wildcards to include entire classes of drivers.
- udeb: Remove some obsolete drivers from nic-modules: Remove FDDI
and HIPPI drivers, and inet_lro module.
- ud
Re: Bug#824884: netbase: should not recommend ifupdown
On May 22, "Iain R. Learmonth" wrote: > What is the upstream source for the /etc/services file? Do we just I am... > maintain that in Debian or are updates incorporated from IANA and > unofficial port numbers? I do not use the official IANA list because it is huge and full of entries of questionable utility. TBH, I think that the main value of /etc/services is for number to name conversion. -- ciao, Marco signature.asc Description: PGP signature
Bug#825025: ITP: libtins3 -- packet crafting and sniffing library
Package: wnpp Severity: wishlist Owner: Federico Ceratto * Package name: libtins3 Version : 3.4 Upstream Author : Matias Fontanini * URL : https://libtins.github.io/ * License : BSD-2 Programming Lang: C++ Description : packet crafting and sniffing library libtins is a high-level, multiplatform C++ network packet sniffing and crafting library. Its main purpose is to provide the C++ developer an easy, efficient, platform and endianess-independent way to create tools which need to send, receive and manipulate network packets. The package is a dependency of dublin-traceroute #818284 It will be maintaned in collab-maint
Re: Debian Installer Stretch Alpha 6 release
Unless some compeling reason exists not to do it, could wireless-tools
and iw get added to the isos? I don't know why iwconfig continues to be
on this type of debian when iw was supposed to have replaced it and is
supposedly more harmonious with modern kernels. I tried configuring my
wifi connection to xfinity with iwconfig and wpa_supplicant and couldn't
get it done post-install and suspect I need a few more tools and I'm
doing this with command line. If espeakup by default gets mate
installed is orca also installed?
On Sat, 21 May 2016, Cyril Brulebois wrote:
Date: Sat, 21 May 2016 17:13:17
From: Cyril Brulebois
Reply-To: debian-b...@lists.debian.org
To: debian-devel-annou...@lists.debian.org
Cc: debian-b...@lists.debian.org
Subject: Debian Installer Stretch Alpha 6 release
The Debian Installer team[1] is pleased to announce the sixth alpha
release of the installer for Debian 9 "Stretch".
Important changes in this release of the installer
==
* This release fixes the package installation issue which appeared
lately with the previous alpha release (#814343).
* Debian Pure Blends can now be enabled directly from the Software
selection screen. This might change in a later release though
(#758116).
Improvements in this release
* brltty:
- Install MATE desktop by default when brltty is used in d-i.
- Disable auto-detection of Cebra, Albatross, and BrailleMemo
devices in d-i, since they are rare and conflict with other
devices (#782732).
- prebaseconfig: Enable screen reader in KDE.
- prebaseconfig: Support 4th bootline parameter.
- brltty-udeb.udev.rules: Add new USB IDs.
* cdebconf:
- gtk: Auto-scroll when switching between entries.
- text: Print one screen worth of choices, and use +/- to switch
between choices screens (#809739).
* debian-installer:
- Bump linux kernel version from 4.3.0-1 to 4.5.0-2.
* espeakup:
- Add support for multiboard systems: request the user to press
enter at the right time to select a given board.
- Improve language/voice lookup.
- Install MATE desktop by default when espeakup is used in d-i.
* flash-kernel:
- Avoid waiting for Ctrl-c when debconf is running (#791794).
* net-retriever:
- Concentrate on SHA256 now, following archive-side changes.
* netcfg:
- Improve behaviour when user-submitted input contains spaces
(#818611).
- Improve error checking in various places.
* network-console:
- Improve support for multiple addresses (#816600).
* parted:
- Fix problems with LVM and DASD devices (#814076).
* partman-auto:
- Bump space requirements for a lot of recipes (#725642).
* partman-basicfilesystems:
- Call mkfs.ext2 with -F to avoid hangs (#817174).
* partman-ext3:
- Call mkfs.ext[34] with -F to avoid hangs (#767682).
* preseed:
- Invert env-preseed and initrd-preseed so that the former
overrides the latter (#805291).
- url: correctly handle IPv6 addresses (#815166).
* rootskel:
- Add GNU/screen support, when it's available.
* s390-zfcp:
- New component to activate and configure FCP devices (#808041).
* wget:
- Add udeb support, for later user.
* win32-loader:
- Switch signature checking from MD5 to SHA256.
- Improve support for new versions of Windows (#775055).
Hardware support changes
* debian-installer:
- Provide u-boot images for OpenRD.
- Use marvell flavour for orion5x and kirkwood.
- Include mtd-modules in various images.
- Generate image for Seagate Personal Cloud and Seagate NAS.
- Improve armel/orion5x and armel/kirkwood for many different
Buffalo Linkstation devices.
- Add support for Firefly-RK3288.
- Add support for BeagleBoard-X15.
- ARM: sunxi: Add support for the Olimex A20-SOM-EVB.
- Add sata-modules for arm64.
* grub-installer:
- Install grub-xen when installing in a Xen PV guest.
* hw-detect:
- Improve and split harddrive detection into DASD and SCSI
dependency on s390x (#818586).
* libdebian-installer:
- armel: Add various orion5x/kirkwood based Buffalo Linkstation
devices supported by device-tree.
* linux:
- [armhf] usb-modules: Add modules required for BeagleBoard-X15
(#815848).
- [mips*/octeon] udeb: Add ahci_octeon and ahci_platform modules
to sata-modules.
- [arm64] udeb: Add leds-modules package containing leds-gpio
driver.
- [arm64] udeb: Add regulators and SoC modules to core-modules.
- [x86] udeb: Move scsi_transport_fc to scsi-core-modules, since
hv_storvsc now depends on it.
- [armhf] core-modules: Include regulator drivers by default.
- mmc-modules: Include MMC controller drivers by default.
- mmc-modules: Depends on usb-modules.
- usb-modules: Include USB PHY drivers by default.
- udeb: Combine scsi-{common,extra}-modules with scsi-modules.
- udeb: Use wildcards to include entire classes of drivers.
- u
Re: PIE and static libraries
Hi! On Sun, 2016-05-22 at 10:41:56 +0200, Christian Seiler wrote: [… useful overview …] I've tried to condense this and the other message on the other thread to extend the dpkg-buildflags(1) man page. Attached the patch I'm intending to apply. Let me know if you have other suggestions, improvements, wording tweaks, etc. Thanks, Guillem From d3a6f97736bade62a8945f91c22593f22f3e2ae4 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Sun, 22 May 2016 19:20:04 +0200 Subject: [PATCH] man: Document interaction between PIE and libraries Prompted-by: Christian Seiler --- man/dpkg-buildflags.1 | 30 ++ 1 file changed, 30 insertions(+) diff --git a/man/dpkg-buildflags.1 b/man/dpkg-buildflags.1 index ac2489e..47b77d8 100644 --- a/man/dpkg-buildflags.1 +++ b/man/dpkg-buildflags.1 @@ -362,6 +362,36 @@ locations to bounce off of during a memory corruption attack. This is not compatible with \fB\-fPIC\fP so care must be taken when building shared objects. +Static libraries can be used by programs or other shared libraries. +Depending on the flags used to compile all the objects within a static +library, these libraries will be usable by different sets of objects: + +.RS +.TP +none +Cannot be linked into a PIE program, nor a shared library. +.TP +.B \-fPIE +Can be linked into any program, but not a shared library. +.TP +.B \-fPIC +Can be linked into any program and shared library. +The resulting program might be slightly slower and bigger in case +\fBbindnow\fP is not in use. +.RE + +.IP +Unconditionally passing \fB\-fPIE\fP, \fB\-fpie\fP or \fB\-pie\fP to a +build-system using libtool is safe as these flags will get stripped when +building shared libraries. +Otherwise on projects that build both programs and shared libraries you +might need to make sure that when building the shared libraries \fB\-fPIC\fP +is always passed last (so that it overrides any previous \fB\-PIE\fP) to +compilation flags such as \fBCFLAGS\fP, and \fB\-shared\fP is passed last +(so that it overrides any previous \fB\-pie\fP) to linking flags such as +\fBLDFLAGS\fP. + +.IP Additionally, since PIE is implemented via a general register, some register starved architectures (but not including i386 anymore since optimizations implemented in gcc >= 5) can see performance losses of up to -- 2.8.1
Re: PIE and static libraries
On 05/22/2016 07:31 PM, Guillem Jover wrote: > I've tried to condense this and the other message on the other thread > to extend the dpkg-buildflags(1) man page. Great, thanks! > Attached the patch I'm intending to apply. Let me know if you have > other suggestions, improvements, wording tweaks, etc. > +.B \-fPIC > +Can be linked into any program and shared library. > +The resulting program might be slightly slower and bigger in case > +\fBbindnow\fP is not in use. Well, that is only for the difference between -fPIC and -fPIE, and TBH, that's not really that relevant. dpkg-buildflags does discuss the impact of PIE later on (your patch quotes part of it), so I don't think you need to mention that here, also because the description is already condensed. So I would simply remove the sentence "The resulting... not in use.", otherwise I think your patch looks good. Regards, Christian signature.asc Description: OpenPGP digital signature
Re: Bug#824884: netbase: should not recommend ifupdown
Guus Sliepen writes:
> Hm, I did not expect that, but according to codesearch.debian.net you
> are right. I'm actually stunned by the amount of programs that do
> something like:
> struct protoent *pe = getprotobyname("TCP");
> int s = socket(AF_INET, SOCK_STREAM, pe->p_proto);
> ...when there is the perfectly fine IPPROTO_TCP. Every time
> getprotobyname() or getservbyname() is called, glibc opens
> /etc/protocols or /etc/services and parses the whole file. What a waste:
> it takes more effort to program it like this, it wastes CPU cycles and
> disk IO, and it has more potential to fail.
While I agree with you that getprotobyname is probably pointless, I don't
really agree for getservbyname (or getaddrinfo, which is the more modern
way to do this). Those don't have well-defined constants, and while the
ability to change that file and thus change software behavior is of very
limited use, I do think it makes for more readable code to use symbolic
service names. A minor point, and it doesn't make a huge difference in
the long run, but it's what I do in my software and I think it has some
clear merits.
I don't really buy the performance argument for nearly all software.
Reading a file from disk isn't very slow, and for *most* software this
isn't a hugely frequent operation. (There are certainly cases where it
would be an issue, but in most of those cases it's already a better idea
to cache the results of getaddrinfo for some time.)
--
Russ Allbery (r...@debian.org)
trying to use wireless not from gnome... what's the incantation?
Got a new laptop after 10 years of excellent stable ancient debian, and my wireless works from gnome, and only from gnome. Unfortunately I find that gnome3 is not for me. I've been trying dwm. No combination of nmcli ifconfig iw ip rfkill unblock wpa_supplicant /etc/network/interfaces etc. that I've tried makes wireless work outside of gnome, and I've googled much and tried many of them. It seems like a waste of time, since clearly nm-applet and/or NetworkManager knows the magic spell. I'm posting here both in hope of a solution, and because this seems like a bug. How come this only works from gnome? nmcli in particular looks like it's trying to be a general-purpose solution, but somehow it too only works from gnome. Here's what NetworkManager puts in syslog when bringing wireless up: May 22 20:26:11 debian NetworkManager[1959]: enable requested (sleeping: no enabled: no) May 22 20:26:11 debian NetworkManager[1959]: re-enabling... May 22 20:26:11 debian NetworkManager[1959]: (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] May 22 20:26:11 debian NetworkManager[1959]: (eth0): preparing device May 22 20:26:11 debian NetworkManager[1959]: (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] May 22 20:26:11 debian NetworkManager[1959]: (wlan0): preparing device May 22 20:26:11 debian NetworkManager[1959]: NetworkManager state is now DISCONNECTED May 22 20:26:11 debian NetworkManager[1959]: (wlan0) supports 5 scan SSIDs May 22 20:26:11 debian NetworkManager[1959]: (wlan0): supplicant interface state: starting -> ready May 22 20:26:11 debian NetworkManager[1959]: (wlan0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] May 22 20:26:11 debian NetworkManager[1959]: (wlan0): supplicant interface state: ready -> disconnected May 22 20:26:11 debian NetworkManager[1959]: (wlan0) supports 5 scan SSIDs May 22 20:26:15 debian NetworkManager[1959]: Auto-activating connection 'dlink_223_dome_rd'. May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) starting connection 'dlink_223_dome_rd' May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started... May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0] May 22 20:26:15 debian NetworkManager[1959]: NetworkManager state is now CONNECTING May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting... May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0/wireless): access point 'dlink_223_dome_rd' has security, but secrets are required. May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0] May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) complete. May 22 20:26:15 debian NetworkManager[1959]: (wlan0): supplicant interface state: disconnected -> inactive May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started... May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0] May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting... May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0/wireless): connection 'dlink_223_dome_rd' has security, and secrets exist. No new secrets needed. May 22 20:26:15 debian NetworkManager[1959]: Config: added 'ssid' value 'dlink_223_dome_rd' May 22 20:26:15 debian NetworkManager[1959]: Config: added 'scan_ssid' value '1' May 22 20:26:15 debian NetworkManager[1959]: Config: added 'key_mgmt' value 'WPA-PSK' May 22 20:26:15 debian NetworkManager[1959]: Config: added 'psk' value '' May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) complete. May 22 20:26:15 debian NetworkManager[1959]: Config: set interface ap_scan to 1 May 22 20:26:15 debian wp
Re: trying to use wireless not from gnome... what's the incantation?
On Mon, May 23, 2016 at 12:42 PM, Britton Kerin wrote: > Got a new laptop after 10 years of excellent stable ancient debian, > and my wireless works from gnome, and only from gnome. Please ask about this on a Debian user support channel: https://www.debian.org/support -- bye, pabs https://wiki.debian.org/PaulWise
Re: trying to use wireless not from gnome... what's the incantation?
On Sun, May 22, 2016 at 08:42:12PM -0800, Britton Kerin wrote: > Got a new laptop after 10 years of excellent stable ancient debian, > and my wireless works from gnome, and only from gnome. Unfortunately > I find that gnome3 is not for me. I've been trying dwm. > > No combination of nmcli ifconfig iw ip rfkill unblock wpa_supplicant > /etc/network/interfaces etc. that I've tried makes wireless work > outside of gnome, and I've googled much and tried many of them. It > seems like a waste of time, since clearly nm-applet and/or > NetworkManager knows the magic spell. If for whatever reason NetworkManager doesn't work for you, and you want an easy to use alternative, I'd recommend wicd. Using low-level tools can indeed be tricky, so while they're more powerful than anything NM or wicd can do, they're an overkill and a waste of learning time if what you want is regular use of a single interface. > I'm posting here both in hope of a solution, and because this seems > like a bug. How come this only works from gnome? nmcli in particular > looks like it's trying to be a general-purpose solution, but somehow > it too only works from gnome. NM is closely tied to Gnome so regressions in non-Gnome use aren't surprising. -- An imaginary friend squared is a real enemy.
