SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am running Slackware 13.1 on my laptop. It's taken me a while to build knowledge of the various networking scripts and config files in order to connect to and switch between the various networks, home/work routers etc I have to deal with. While I am going places, I am still nowhere near mastery.
Due to all the silliness of Wifi-tracking dustbins (http://arstechnica.com/security/2013...d-from-london/), Streetview wifi snarfing and general bad behaviour by Brothers, Big and Little, I am looking to start minimizing the wifi broadcasting that my system performs - in other words, I want to be able to totally disable my wifi system, at as low a level as reasonably possible, whenever I'm not using it, and bring it up on demand with a console command or two. To guarantee it is off during boot would be nice (so i can turn on the laptop at a cafe for example, and be sure not to do the default broadcast for routers and dhcp requests)
I'm reasonably familiar with /etc/rc.d/rc.inet1.conf, the various ppp files, start and stop scripts etc.
I must note that the hardware button for the wifi system is something I'd prefer not to mess with, as I'm afraid it will get stuck or broken too quickly, and it caused trouble with cross-os conflicts when I dual-booted. Software controls only please.
Hi and thanks to Whitewolf and kikinovak for your replies.
In terms of placing the ifconfig commands in rc.local:
Surely this is too late, because when booting up, the system already tries to connect to wifi networks before rc.local runs.
Maybe to guarantee no wifi on boot I need to edit something in /etc/rc.d/rc.inet1.conf or rc.wireless.conf before I shut down?
In terms of upgrading and networkmanager - hehe - I don't call doing a full upgrade and installing extra packages 'keeping it simple', but I get your drift
In terms of upgrading and networkmanager - hehe - I don't call doing a full upgrade and installing extra packages 'keeping it simple', but I get your drift
Thanks again.
That's only because NetworkManager has been officially introduced in Slackware 14.0. Of course you can build it yourself (I did it at the time), but it's not a trivial operation.
Will these commands keep the interface down on the next boot?
Basically I want to be able to 'shut down wireless' before I pack up the laptop to travel, to make sure that when I boot it again (in an untrusted location) that it stays off, until I want to manually start it.
That's only because NetworkManager has been officially introduced in Slackware 14.0. Of course you can build it yourself (I did it at the time), but it's not a trivial operation.
Which again shows you have a different idea of simple than some others do. If the config files, ifconfig and wpa supplicant are too complicated I'd suggest the place to simplify is there not in introducing a third program to the mix (with dependencies on things like dbus and consolekit, whatever that is). Depends on what you mean by simple, I guess, particularly on whether you consider the source code to be part of the user interface you're trying to simplify -- to me with free software the source code is part of the user interface.
Will these commands keep the interface down on the next boot?
No, at next boot the wireless interface will be started automatically again. I guess rfkill will be more appropriate when you want to permanently disable the wireless device.
BTW, slackbuilds.org has a script to build NetworkManager for 13.1. I think 13.1 had wicd in /extra. Either of these will work and I think If you do a lot of roaming then it is much easier than creating a bunch of scripts for different locations.
(...) to me with free software the source code is part of the user interface.
I'm not quite sure to understand this puzzling statement. Probably because I tend to draw a sharp line between administrating a system and actually using it. When I work, I ususally have half a dozen of terminals open, or a bunch of TTY's in init 3. On the other hand, my users (students, teachers, town hall and library employees) sometimes don't even know that the system they're using is called Linux, they just click on the icons and use the apps. And they don't want to know. Which I perfectly understand. And it's this "simplicity" I'm referring to. It's much work for me until it's simple for them.
If the config files, ifconfig and wpa supplicant are too complicated I'd suggest the place to simplify is there not in introducing a third program to the mix
Of course, different ways lead to Saint-Bauzille-de-Putois, but if you want a no-nonsense approach, you'll use rc.inet1.conf on servers and workstations, and NetworkManager on laptops.
I'm not quite sure to understand this puzzling statement. Probably because I tend to draw a sharp line between administrating a system and actually using it. When I work, I ususally have half a dozen of terminals open, or a bunch of TTY's in init 3. On the other hand, my users (students, teachers, town hall and library employees) sometimes don't even know that the system they're using is called Linux, they just click on the icons and use the apps. And they don't want to know. Which I perfectly understand. And it's this "simplicity" I'm referring to. It's much work for me until it's simple for them.
I'm not saying your view is wrong, but it's different from my view since I'm a different kind of user than yours. I want to know how a program works so that when it doesn't work the way I want I can change it (and to some extent just to know how it works). I like it to be internally simple (few lines of code, few levels of abstraction, clean and elegant design, no redundant pieces or other flab) so that when the outer user interface and configuration fails me I don't need to spend hours and hours to understand how the program works so I can adjust it. That's what I mean by the source code being a part of the user interface. The interface to the software is 1. the graphical or command line UI, 2. the configuration files, 3. the source code. Pasting over complexity in an inner, hidden "expert only" program or library with another program whose outer interface is easier to deal with is antithetical to this view.
The trouble is that supporting these two views leads to different design decisions, which is why I've tended to avoid GNU/Linux in general and particularly all the Windows/Mac desktop knock-offs (I think the people making these like your kind of user better than my kind). Slackware seems to strike a fairly good balance for a Linux distro from what I've seen so far (only been using it a couple months). The wireless configuration does look like a slight pain point though, based on thread count and my own initial experience with it. In the threads I saw, having NetworkManager in the system complicated matters, IMO, because posters would flail around from thing to thing and that added a 2nd way to work that distracted them from understanding the startup scripts and the programs involved at that level.
I'm not saying your view is wrong, but it's different from my view since I'm a different kind of user than yours.
I remember you now as the CWM user from another thread (my Slackware DE). Well, indeed, we are two different kinds of users, and I understand better what you meant above.
In my everyday work, I install Linux desktops mainly to a Joe-Sixpack-type of user, so even if it's Slackware and scripts and CLI under the hood, above the surface things look more like Mac OS X or Windows Seven (http://www.microlinux.fr/desktop_linux.php).
This thread interests me because I'm new to laptops and especially wireless.
Please correct me if I'm wrong, but I was thinking a simple approach (for mobile laptops and not fixed workstations) is to 1) disable rc.networkmanager, 2) use an empty rc.inet1.conf, 3) modify rc.inet1 so only the lo interface starts, and 4) start eth0 and networkmanager after logging in.
For me I'd have three basic NetworkManager options. Two would be for my home network: wired and wireless. I use static addresses in my home LAN and those two options already work nicely for me. I'm happily located in the remote rural boonies to avoid needing wireless encryption on my home router (keeps things a tad speedier ).
I need a third option for DHCP for when I'm on the road, which should also be configured to use encryption. NetworkManager is supposed to be "intelligent" to always first look for and prefer wired availability and then wireless. In my case that seems to work well for the home network but I haven't yet tested the DHCP option away from the home.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.