Minimal network config [ wifi ]
 

Hi All

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.

Any ideas?

Shouldn't be too difficult to do what you are wanting, if you don't mind doing it as root.

add to your /etc/rc.d/rc.local
and when you want to bring up your card, just type this in the console
If these aren't good enough, there is always the rfkill command as well. That will put a soft block on your device.

1. Upgrade to Slackware 14.0.
2. Use the graphical NetworkManager.
3. Click on "Connect" whenever you want to connect to a wireless network.
4. Click on "Disconnect" whenever you want to disconnect from a wireless network.

Keep It Simple Stupid. :)

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 ;)

Thanks again.

I would just run to bring down the wireless interface and to make the wireless association and get an IP address again.

That does not disable the radio on the wireless card but the card should not be scanning when the interface is down.

Eric

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.

Hi Alien_Bob

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.

Many thanks again to all

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.

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.

Eric

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.

Brian

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.

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 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 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).

Cheers,

Niki

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.

Would this strategy succeed?

In order to have complete manual control, just make /etc/rc.d/rc.inet1 and rc.inet2 non-executable. Then, create two small scripts which run the commands you need to start and stop the network services.

If rc.inet1 is chmod -x, then the lo interface never initializes during boot, which might affect other apps. I would think most people want lo to start automatically, most if not all the time?

Check the docs for your laptop.

Some have a Fn key or switch that can turn the wireless on and off. On my Dell 1545n, it's an Fn key; on my Asus, there's a switch on the front of the box just beneath the latch.

The OP voiced a preference to use software rather than hardware, although an Fn-Fx combination would qualify as software. On my Thinkpad T400, Fn-F5 is suppose to support that kind of option, but only directly for that proprietary system. I haven't fiddled with making that work. I probably need to write Yet Another Script and then map that script to the key combination. Supposed to control bluetooth too.

Hi All

Thanks for all the tips and possibilities.

My preference is to stick with the stock slackware scripts and configs and work with that. If I have to edit rc.inet1.conf before I shut down (in order to guarantee no wifi on next boot) that is fine. I would appreciate however some tips on the least intrusive way to do this (ie. what key lines should I comment out/change/delete) and what might the greater consequences of this be.

I'm mostly running on eth0, wired lan (and run local apache servers', so I need localhost), but occasionally travel and need to use public wifi or the home routers of friends (via wifi).

Many Thanks!

Just make rc.net1 non-executable to disable it on next boot.
"most people want lo to start automatically" I never had this behavior at all until recently when I started using a wireless router. I run a lot of the time as root, so I prefer to have networking setup as a completely manual operation, to avoid security risks.

Thanks guys and girls, I'll be going gnashley's route and see how it goes.

Mark solved.