Arch Linux

Using iproute is more complicated than ifconfig, as far as I remember, routes aren't set automatically. iproute is more powerful though, so let's do this :)

I'm up for it.

Here's is a diff for initscripts for switch from ifconfig/route to iproute.
It worked for me with static ip and dhcp. But i couldn't test bonding and brigding,

Should we think about to switch to dhclient, too?

Isn't dhclient much more heavy weight that dhcpcd? I have always used dhcpcd.

Do you have any documentation that points to one as deprecated in place of the other?

>>> Using iproute is more complicated than ifconfig
...
Considering that you can use /24 masks in "ip addr add" compared to have to use full bitmask in ifconfig .. it's also easier :)
It's also easier to set up several ip addresses to interfaces.

Sascha's patch looks alright to me.

This is the way forward. Last net-tools release was April 01. More than 7 years ago.

I know they work great now, I know we're all familiar with them, but they won't work forever. Changing to iproute doesnt mean that we'll remove them. I'm sure we could push the old rc.d/network to [community] or [extra] or something as a separate package.

Given this is a breaking change, if there's anything else anyone wants to mix up in rc.d/network, now's a good chance.

James

Updated patch for current git.

- ip is presently located in /usr/sbin. This may be an issue.
- ip appears to not need any special arguments for ipv6, so ipv6 checks have been removed. Anyone using ipv6 that can confirm?
- As with original patch, bonding and bridging not tested.

netcfg has iproute2 support in git too.

The major problem here is that this will break rc.conf compatibility! IF we are to break rc.conf compatibility, we should move to a configuration scheme that does not depend on the implementation. First we used ifconfig syntax, in the new approach we use ip syntax, and next time something changes we use another one.

Another note: IMO, we should only support very basic things in rc.conf, anything advanced should be supported in netcfg. We should remove wireless support completely from rc.conf (it only supports WEP and Open anyway, which is worthless) and once bridging and bonding get more complex, netcfg should be the place to handle these as well.

Out of curiosity, is there anything that network supports and netcfg doesn't (and couldn't)?

@thomas: Open wireless access IS "basic support". I do not want to remove basic wireless functionality from rc.conf, as it's useful to some people (myself) who run open APs.

This is just confusing to users. It seems we do support wireless, but only the insecure part of it - I don't want to have partial support for a feature that may make users think that the complete support is unavailable. My suggestion is simply that everyone who wants wireless should use netcfg for it.

Wireless can be tracked in a separate bug. Eventually the wireless support there will become dated too as WEXT/iwconfig is deprecated. The partial support has confused people, sometimes they try and configure WPA with it, other times they mix it with netcfg. I think just make it "undocumented" or even mark it as "deprecated".

Thomas: That is a major problem, but we've broken bigger things on Arch before (initrd/initramfs). I always liked the rc.d/network scripts because they _do_ depend on the implementation. There is the thinnest layer, what you enter practically gets passed through to the commands below. If you do try to put some sort of layer.... you end up with something more like netcfg.

We already have an abstraction in place when we use eth0="dhcp".

Breaking virtually anyone's network during update is not what I want to do (not again) - and that is exactly the problem: If we had a real configuration in place from the beginning, we could simply change the implementation without breaking things. We need to ask ourselves the following questions:

- Do we really need iproute for the very basic network configuration? Isn't it enough to have it in the advanced configuration (=netcfg)?
- If we switch, do we really want to break everyone's rc.conf? This will annoy many users (including me) while having virtually no benefit.
- If we switch and do not want to break things, do we offer a compatibility layer (complicating the scripts) or a conversion script or do we force the user to do it themselves?

Why ifconfig deprecated?

I just see shady sentense without prooflink in wikipedia about it.

man 8 ip says nothing about ifconfig deprecation as well as man 8 ifconfig...

I see http://www.linux-foundation.org/en/Net:Iproute2 says it, but is there any bug report where ifconfig 'behave inadequately'?

sergej: net-tools hasn't had a release for almost 8 years. Does that sound like it's unmaintained to you?

but Thomas is right, it's probably not worth the trouble moving rc.d/network over.

I see, but how many bugs it have?

In arch bugtracker I found 2: this and 13334.

So, ifconfig works, ip can be used without problems. I think there is no reason to replace it...