[arch-dev-public] Consensus on network scripts

[James]

On 4/20/07, Tobias Kieslich <tobias at justdreams.de> wrote:
> On Thu, 19 Apr 2007, Jürgen Hötzel wrote:
>
> > On Wed, Apr 18, 2007 at 10:18:07PM +1000, James wrote:
> > > Hey,
> > > http://wiki.archlinux.org/index.php/Network_Scripts
> > >
> > > I've been pushing these repeatedly, with only meager interest shown by
> > > others. Given a little bit of documentation, I think they're almost
> > > ready for me to unleash and publicise for further testing.
> >
> > laptops are often moved between wireless networks and thus require user
> > interaction. "Static" configuration on system startup are improper for
> > these requirements. Most other distribution even don't have wpa support in
> > initscripts. It's complex and error prone. RedHats NetworkManager is a nice
> > application for this job.

Yes, and no.

Yes, laptops are moved between wireless networks, but this does not
mean that static configuration is inappropriate. My laptop for
example, has long moved between home, and school/uni and a coffee shop
I frequent. Three, unchanging networks. Most users of wireless have
networks they frequent often like this.

Look at my scripts, they're not as complex and error prone as you'd
think. Most distros *do* have wep support in their scripts, and I see
no reason why wpa shouldn't be afforded that same level of support.
Arch is a different distro to "most other distributions".

NetworkManager is not a solution. It's gui dependent. To use it, means
loading up either KDE or Gnome. This is a ridiculous dependency for
network connectivity. Developing a command line based client would
be... nice. But, I don't have the experience to develop it, and arch
needs better network scripts two years ago. Nor is anyone else
stepping up to develop it. Ideas/Ideals are only good if people exist
to implement them.

These scripts, detect and connect to each of these networks, with no
user interaction, automatically. Unlike NetworkManger, which for
gnome, stores passwords in gnome-keyring, requiring me to enter my
password in each session. *urgh* (except with hacks like pam-keyring).

Sure these scripts are different, but there's definitely room for
them, and they work well in the real world.

> actually we have most of the stuff we need for Laptops. I didn't have
> the time to look at James work yet (sorry) and maybe he incorporated the
> idea already. Can we create a list of wifi networks at startup with
> `iwlistscanning`, parse it and grep for the ESSID and lookup in the
> network profiles if an ESSID matches. It's not perfect, but it might be
> a nice default for laptops. Oh, and yes I know, who suggest sucha thing
> should actually go ahead and implement it.

Already implemented, though differently. Using iwlist and checking
that for essid's doesnt work for networks that use hidden essid, as
iwlist just spits "<hidden>". Some network drivers have terrible
scanning support, and as a result, can also be set to follow the same
method as hidden networks.

(when I last used NetworkManager, it did not 'detect' hidden networks,
i had to manually connect to my school network... this may have
changed since.)

Detection works like this:
- you create a profile for each wireless network you use.
- add profiles to the NET_PROFILES line in rc.conf.
- on /etc/rc.d/net-profiles start, it goes through each profile
defined in NET_PROFILES, and attempts to start them. Nearly all people
would do a start/restart, when resuming or starting their laptop in a
different location.
- In the starting procedure, for a wireless profile, it checks if the
network is available via scanning, for hidden networks it uses an
association attempt.
- If a network is available, then, it connects.
- Any further profiles on that interface, fail, as the network
interface is already configured, so the successful connection is not
clobbered.

It's trial and error, yes, but works cleanly, quickly and effectively.
The above 'detection' method has negligible time cost over a straight
iwlist scan like you suggest, allows detection of all current types of
wireless networks and allows for a much cleaner and more generic
network profiles setup.

Excuse me for being verbose... I've spent a lot of time on these, and
want to make sure they're understood correctly and accepted.

Thanks if you managed to read this far!

James

-- 
iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com