The pre-up hook could qualify as one of the missing features.

I'm one of the people who said that network manager can't be usable for me
unless it supports some kind of external scripts. Not that I'd want to replace
my homegrown ball of shellscripts with automatic detection of networks, but I
should say why network manager is too weak for me.

 • Sometimes, I need to start/stop services depending on which network I use.
   There are networks where I want ssh running, some where I really don't. Not
   all such services I use have init scripts, some are launched manually in a
   screen or something.
 • Sometime networks are shared for others. With a shell script, I can start a
   GPRS connection, bring up eth0, set up NAT, complicated firewall, launch
   proxy, etc.
 • I didn't look at network manager lately, but does it really support full
   power of iptables? Friend of mine said he has 3 pages of iptables rules in
   his home setup, to bring up two connections and set up routing through it
   (backup connection used for some services like SIP when both connections
   work).
 • I have a habit of removing kernel modules of unused interfaces from kernel.
 • On some networks, I use my own local DNS server, because I don't trust the
   provided one. This requires to add additional parameters to dhcp client and
   edit the /etc/resolv.conf file.

(In reply to comment #2)
> I'm one of the people who said that network manager can't be usable for me
> unless it supports some kind of external scripts. Not that I'd want to replace
> my homegrown ball of shellscripts with automatic detection of networks, but I
> should say why network manager is too weak for me.

Thanks for finding some time, Michal.

>  • Sometimes, I need to start/stop services depending on which network I use.
>    There are networks where I want ssh running, some where I really don't. Not
>    all such services I use have init scripts, some are launched manually in a
>    screen or something.

You won't probably like it but...

Connects/disconnects, zones and other stuff are currently handled by D-Bus, which is the primary interface for communication with NetworkManager. If you
accept D-Bus as IPC mechanism, there are three ways to do this:

1) Modify NetworkManager so that you have all hooks you need and hooks get all
information you need on their command lines or stdin. The classic way.

2) Use some sort of tool that listens to D-Bus and calls your script with
information from D-Bus.

3) Use your shell-script as a long-running daemon calling a D-Bus tool that
would block until it recieves a specific D-Bus message.

I guess you would probably still favor (1).

>  • Sometime networks are shared for others. With a shell script, I can start a
>    GPRS connection, bring up eth0, set up NAT, complicated firewall, launch
>    proxy, etc.

In event-based IPC world this should be doable with multiple deamons communicating
with each other. FirewallD is at its beginning. But yes, shell scripts are convenient
for the beginning so it would be nice if we can do enough for them.

In the ifcfg world, I was just using what is now dispatcher.d scripts in NM.

>  • I didn't look at network manager lately, but does it really support full
>    power of iptables?

Not at all. If you need full power of iptables, you should usually use... iptables. Scripting
is crucial, here.

> Friend of mine said he has 3 pages of iptables rules in
>    his home setup, to bring up two connections and set up routing through it
>    (backup connection used for some services like SIP when both connections
>    work).

You will never have 100% flexibility with an external tool. Setting up the kernel
structures makes you fully use the kernel features. But, there are things that cannot
be done properly without some sort of network daemon, like IPv6 autoconf.

Most problems with autoconfiguration are surprisingly in kernel. It's just sort of useless
for the task it is trying to fulfill. I would prefer if:

1) The kernel implemented the autoconfiguration properly and expose the relevant APIs to userspace.

2) The kernel didn't care about autoconf at all and left the whole thing to userspace as it used to be with
IPv4.

Currently, (1) seems better to me but I know many people will disagree.

>  • I have a habit of removing kernel modules of unused interfaces from kernel.

This doesn't seem to be so important and it can break things in OpenVZ and elsewhere.

>  • On some networks, I use my own local DNS server, because I don't trust the
>    provided one. This requires to add additional parameters to dhcp client and
>    edit the /etc/resolv.conf file.

NetworkManager uses dhclient (or dhcpcd if you wish). Many things are configurable there. And you
can of course edit /etc/resolv.conf and prevent it from being rewritten.

Looking forward to more feedback if you have some :).

Hello

(In reply to comment #3)
> Connects/disconnects, zones and other stuff are currently handled by D-Bus,
> which is the primary interface for communication with NetworkManager. If you
> accept D-Bus as IPC mechanism, there are three ways to do this:

I'm not really against D-Bus itself. I actually use it in my code from time to
time. But sometimes it is not the easiest way to do things O:-).

> 2) Use some sort of tool that listens to D-Bus and calls your script with
> information from D-Bus.

So, except network manager that keeps watch than nobody changes the IP address
of interface manually, there'll be yet another tool loaded into the memory
that'll keep watch on network manager if it changes something. That sounds like
a waste to me, considering there are still many systems with limited amount of
memory (most of today's cheaper netbooks have 1GB RAM, some cheaper virtual
server solutions comes with half, not talking about the plastic boxes called
„home routers“ running linux at all).

> 3) Use your shell-script as a long-running daemon calling a D-Bus tool that
> would block until it recieves a specific D-Bus message.

It is indeed possible. But I'd like to point out that writing own set of
scripts that do keep running all the time and have hooks and stuff took me less
work than it would be to learn how to make network manager do what I want and
learn how to write the scripts that do the extra.

> >  • I have a habit of removing kernel modules of unused interfaces from kernel.
> 
> This doesn't seem to be so important and it can break things in OpenVZ and
> elsewhere.

I never said this is a need for anyone but me. I just don't like the code in
kernel that is not being used and I hope that the card would get deinitialized
(so it would save a bit of energy too) if the module is removed. I was just
pointing out that there are always strange individual needs that a tool like
network manager will never support.

Network manager may be good enough for 90% of people (provided it has a GUI and
they don't have any strange network setup). But to be generally accepted, it
needs not to get into the way of the 10% and provide them the means of solving
their unusual problems. The hooks could be enough for many of such problems.

> NetworkManager uses dhclient (or dhcpcd if you wish). Many things are
> configurable there. And you
> can of course edit /etc/resolv.conf and prevent it from being rewritten.

Actually, I modify the /etc/resolv.conf from the script that runs. So each
network I connect to have different /etc/resolv.conf (sometimes generated on
the fly by some means).

This tracker is not really being used.