The first thing I do on any Linux machine is set up an `ifconfig` alias in my shell. That's a command that I've been using for a lot longer than some of these distributions have been around.
From the man page documentation for ifconfig:
> This program is obsolete! For replacement check ip addr and ip link. For statistics use ip -s link.
and
> Ifconfig uses obsolete kernel interface. It uses the ioctl access method to get the full address information, which limits hardware addresses to 8 bytes. Since an Infiniband address is 20 bytes, only the first 8 bytes of Infiniband address are displayed.
I don't understand why ifconfig couldn't be upgraded to use whatever the new IOCTL that is compatible with 20b+ addresses instead of being deprecated for favor of a new command entirely.
Fortunately, my FreeBSD servers all take ifconfig out-of-the-box... and even my Linux shell under Windows does, too.
1. net-tools is a completely separate project while iproute is closely related to the kernel. On FreeBSD, userland is kept in sync with kernel.
2. ifconfig output was parsed by programs and difficult to extend without breaking everything. iproute output is extensible and less likely to break programs.
You might want to look into the history of net-tools and iproute2. `net-tools` was a big UNIX thing. That is the reason FreeBSD still uses it.
Since 2001 (!) `net-tools` hasn't been developed (!= supported) in linux. That's a heck of long time.
It isn't just about the about correcting the ioctl call, it is about re-engineering the complete suite of networking commands in net-tools. The iproute2 suite doesn't get stuff from /proc and ioctl calls, but rather does through netlink (because ioctl calls were being (ab)used a lot). So it is more performant.
It might seem absurd to optimize for performance, but its really not because its usage in scripts warrants it (especially because `iproute2` does a lot, lot more than what `net-tools` does)
It's clearly too late for this battle, but I think this is a clear picture of 'Linux philosophy' vs 'BSD philosophy':
Ifconfig could have been augmented to support the new, performant ways to do the things, and the new, cool things; but instead, a new tool was developed and the old one deprecated. In FreeBSD, you still use ifconfig to configure interfaces, including wireless interface parameters, instead of another thing for that (iwconfig).
Churn and reinventing the wheel accomplishes nothing but creating busywork for many hundreds of thousands of users, creates an unnecessary learning curve and wastes time. They should've just fixed/rewrite net-tools for new interfaces and added flags for parsable output.
I know what you mean, and agree to some extent. But I doubt that statement holds up in this case.
>Ifconfig could have been augmented to support the new, performant ways to do the things, and the new, cool things;
I don't think that could've happened. You are thinking very narrowly, just about ifconfig command. Linux has a lot more networking things that aren't there in UNIX (or even in the BSDs for that matter). There have been many networking concepts introduced in linux that would warrant creating a completely different set of tools.
Ofcourse, shoehorning all the new features behind current net-tools binaries is an option. But if you see the elegance in the current with which `ip` can be used, I think you would reconsider your stance.
I've always struggled with the fact that only root can use ifconfig on Suse. I only recently became aware of this, but I do see that non-root users can run 'ip a'.
This[1] page covers a lot more commands. I didn't even know it was possible to do some of those in linux without installing more packages. It is very long so I would just bookmark it.
The post is from 2011 and it's been awhile since I started using 'ip' instead of 'ifconfig', but everybody, myself included, seem to continue using 'netstat' and not 'ss'.
Old habits die hard. Also, I don't particularly like having to learn _yet another_ command to get what I want. It's bad enough having to learn differences between operating systems. Learning differences between operating system _versions_ is really quite annoying. Add in a healthy dose of bias (I seem to recall seeing one of these commands was just a python script instead of a compiled program), skepticism (about it being 'better'? it's different, for sure, I don't know about 'better'; it doesn't appear to use the normal command line switch methods, so that's definitely not better! and, one command which has to parse subcommands? that flows against the old adage of "have one purpose, do it well"...), and paranoia (why change it? why? the old one was just fine and did exactly what I wanted!); you end up with an old guy like me stuck in his ways.
Edit:
Also, I wasn't aware that the old commands were deprecated and definitely didn't have a handy one-to-one conversion reference like this link. So +1 for that
I like most if the new tools, but the 'ss' command produces output that's hard to skim. When outputting to a terminal it tries to justify the columns, hiding some information on the next line. When you pipe it through cat (so it can't detect a tty), the columns don't even line up.
Honestly, why people don't use tabs in terminals is beyond me. It's easier to parse in nearly every case that doesn't involve a text editor of some sort.
The ss program also seems to be missing the feature to show you the username or uid or that the process is running as. It is a useful feature of netstat.
interestingly enough, `ss` (usually w/`-ltun`) was the first thing i successfully reprogrammed my muscle memory to (after 12y+ of using netstat). `ip r` instead of `route` being a close second.
i have come to very much appreciate the consistency and discoverability of the iproute2 cli.
iw is not quite a complete replacement for iwconfig and iwlist. Former don't support some network card drivers, such as [1]. So if you happen to have one of those, you have to use latter two, deprecated or not.
My fingers still type ifconfig, netstat, and route, and then I correct myself usually before hitting enter (though that took at least a couple of years). The new commands are more consistent, and more logically laid out so I can't argue against switching...but, my muscle memory doesn't know them yet (despite having started switching years ago).
It seems pretty clear unlearning the old and learning the new is more work than learning it for the first time, which may be why so many old-timers are so disagreeable to changes like this, even if the new is clearly superior (and for the average user, these may not be clearly superior enough to justify extra effort). Hell, I caught myself typing an ipchains command a week or so ago (while I'm busy learning about nftables which replaces iptables/ip6tables!), and I haven't had a system that had ipchains in more than a decade.
You're fine sticking with iptables for now, if you don't experience any pain from it. ipchains has been compltely dead for well over a decade (which is why it's so ridiculous that I'd start typing an ipchains command); iptables arrived in 2001 and was on everything by the mid-2000s. The difference with that transition was that you couldn't keep using ipchains, because it was replaced by iptables. nftables co-exists with iptables.
nftables works well and has been available in mainline Linux for a few years, but there's little support for it at the distribution and tools and documentation level. AFAIK, things like firewalld and other firewall management tools don't support it yet (though firewalld will support it transparently when it does arrive, so if you use firewalld to manage your iptables firewalls, it'll probably Just Work when switching to nftables). We don't yet support it in our products (while we do support firewalld, iptables, and some third party firewall management tools like CSF have modules for Webmin).
iptables continues to be supported at all levels, so there is no urgency to switching, though nftables is clearly superior in nearly every way. It's an awesome tool, but adoption has been very, very slow. I think that's unfortunate, as it's an area where I'd be willing to learn new things. nft has really clean syntax with super powerful abstractions and hooks into the kernel.
So, if you manage a lot of Linux firewalls, or a few very complex ones, maybe you want to switch already...I would, if I were in that situation. But, I just use firewalld, because my firewall needs are minimal these days.
What do you think of ufw? It's native to Ubuntu, but it's also in Debian and Fedora (just checked the latter with Docker). I chose it over firewalld for my simple firewall needs because I run Debian and Ubuntu rather than Fedora and CentOS, and there's no daemon in ufw, so IMO it's simpler.
I think Linux is just such a big ecosystem now, with such a huge variety of dependent parties, that nothing can change fast anymore, and nothing can ever die. So many products are built around iptables, so many docs assume iptables, etc. It's just cheaper for people to keep using iptables. Doing an ipchains->iptables style conversion where the next version of Linux just completely removed the old thing, wouldn't be feasible today. Linux is orders of magnitude bigger than it was from the transition 2.2 to 2.4 (I think that was when the iptables switch happened).
It's "only" been four years since nftables made it to mainline kernel, so we're not quite into Python 3 territory, but I wouldn't be surprised if we're still having this conversation in five more years. There's just no movement toward nftables, at all, that I perceive. I think it's partly because firewalls matter less today than they once did. So much is in the cloud now, where the firewall is somebody else's problem. It might even end up being a Perl 5->6 situation, but we won't know for a few more years.
ifconfig is far superior to ip, depending on the use case.
Mostly I want to see the current IP, MAC, amount of traffic transfered. Sometimes MTU.
Can't do that with one command in ip.
`ip` is actually really cool once you get to know all the features. I missed seeing ifconfig's familiar output but got over it rather (suprisingly) quickly.
Your comment doesn't make sense. Why is it good to know that a command that you haven't even heard about is phased out?
Fwiw you don't need to be a sysadmin to have known of ifconfig. Hell how is it possible to have set up networking on Linux distributions without knowing this command?
End user here: I found out about all this when I installed Debian 9 with the lxde desktop.
Lxde brought in WiCD for wifi, which is fine, except when attempting to connect in a location with a very large number of Wifi connections available (anything over 70 different ones) it would not connect. Further investigation revealed a 'too much output' error from the iwlist scan command (this is from memory).
Worked fine at home and in most of my usual 'third space' locations of course because way less than 70ish connections.
Booting into a live USB with network-manager on it and googling lead to my discovery of the depreciation.
From a casual net commands user POV, I like that 'ip' plus a sub-command has taken over a good part of this. It's nice to look in one man page, and discover other things ip does, without having to be aware (or ignorant!) of other commands.
ip is a great tool, the only thing I am still not used to is that, ip's output is more like for machines instead of human to digest, at least for me. I feel a sugar wrapper is needed for more enjoyable reading on the terminal.
this post is very useful, hope the author can make a github page for it...
No, it means the author didn't find it in their research time. Which seems crazy, one of them is "iptunnel -v" and version is the first flag covered in the ip man page
From the man page documentation for ifconfig:
> This program is obsolete! For replacement check ip addr and ip link. For statistics use ip -s link.
and
> Ifconfig uses obsolete kernel interface. It uses the ioctl access method to get the full address information, which limits hardware addresses to 8 bytes. Since an Infiniband address is 20 bytes, only the first 8 bytes of Infiniband address are displayed.
I don't understand why ifconfig couldn't be upgraded to use whatever the new IOCTL that is compatible with 20b+ addresses instead of being deprecated for favor of a new command entirely.
Fortunately, my FreeBSD servers all take ifconfig out-of-the-box... and even my Linux shell under Windows does, too.