Moving on from net-tools
The package in question is net-tools, the home for many familiar network-configuration utilities. If you are accustomed to using commands like ifconfig, arp, netstat, or route to make network changes, you are a net-tools user. Many of these tools have a long pedigree, at least in spirit, having originally been written before the first Linux kernel. Anybody who has been administering Unix-like systems for any period of time will certainly have learned how to use the net-tools utilities to get things done.
The only problem is that net-tools is considered obsolete; indeed, it has been so considered since early this century. The modern replacement is iproute2, which is actively developed and, unlike net-tools, has support for all of the kernel networking stack's fancier features. In theory, we all should have transitioned over to iproute2 at least ten years ago.
In practice, many of us have not done that. Indeed, "us" in this case includes distributors who still use net-tools utilities in a number of packages. Surprisingly, the net-tools developers, who have not made a new release since 2011, have recently resumed working on those utilities; even more surprisingly, they made output changes, apparently breaking scripts that parse that output. These changes led Debian developer Marco d'Itri to call for the project to "kill" net-tools, and, in particular, to stop depending on it in other packages. He would also like to see the project stop installing net-tools by default.
The list of Debian packages depending on net-tools is not that short, but it would appear to be a manageable list if the project were to decide to fix all of those dependencies. The net-tools maintainer is not opposed to the idea of deprecating and eventually phasing out the package; indeed, he tried to do so in 2009. It seems to be generally agreed that the configuration scripts shipped with Debian packages should use iproute2 rather than net-tools to ensure that the examples seen by administrators are using the current tool set. So there would appear to be little controversy around the idea of phasing out net-tools usage and dropping the priority of the package for installations.
There is less consensus around removing the package entirely, or even just dropping it from the default install. There are, it seems, quite a few users who have ifconfig and netstat burned into their muscle memory; those tools work fine for most use cases, so users don't see a strong reason to shift to iproute2. As Ted Ts'o put it:
The fact that the iproute2 commands are seen as more verbose and, by some at least, as having less readable (and less machine-parseable) output doesn't help either. So it's not surprising that various participants expressed their preference for the net-tools utilities, but Russell Stuart suggested that it might be time to move on:
(It is worth noting that the "unnecessary" part is not universally accepted; it's not clear that net-tools could have been evolved to handle modern networking configuration without incompatible changes.)
Debian, as it happens, is having this discussion a bit late. OpenSUSE discussed removing net-tools in 2009, but has not done so. Red Hat and Fedora got serious in 2011, and the RHEL 7 release no longer installs net-tools by default. The fact that this change is not universally popular shows how reluctant users can be to let go of their long-used tools.
None of these distributors have removed the net-tools package, and none are likely to as long as supporting them is relatively easy and users depend on them. But, when they do break, or when they fail to support new networking features that users need, there is not likely to be a lot of interest in fixing them. Distributors have to choose where to expend their energy, and there will come a point where dragging along obsoleted tools that the old folks want falls off the list.
For now, users who are accustomed to typing commands like ifconfig are probably safe; at worst, they will need to install the net-tools package explicitly. But anybody who is using these commands in scripts should probably have updated those scripts some time ago. There will come a point where those scripts break; it seems that could even happen as a result of attempts to restart development on net-tools, rather than by explicit deprecation. This cheat sheet is likely to prove helpful for anybody wanting to make the transition to the new tools.
Software transitions like this are invariably an unwanted distraction for
users who are uninterested in whatever new features are available and would
prefer that their systems (and their habits) just continue to work. But
the world we live in does not stand still, so such transitions are simply
going to happen, and distributors will find themselves caught in the
middle. As those distributors strive to keep everybody happy, we should
not be surprised to see more of these transitions take a decade or more.
Posted Jan 4, 2017 19:30 UTC (Wed)
by pj (subscriber, #4506)
[Link] (12 responses)
Posted Jan 4, 2017 19:33 UTC (Wed)
by rwa (subscriber, #69887)
[Link]
Posted Jan 4, 2017 19:36 UTC (Wed)
by SEJeff (guest, #51588)
[Link] (4 responses)
More or less what you're looking for as well?
Or without nss port name resolution or hostname resolution:
lsof -nPi tcp -s tcp:listen
Posted Jan 4, 2017 20:04 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
In related advantages of old tools, man page for the "ip" tool is unhelpful in the extreme. Manual page for ifconfig is much better.
Posted Jan 4, 2017 21:01 UTC (Wed)
by JFlorian (guest, #49650)
[Link]
One thing I love about "ip" is how the output can be used as input. This actually helped me learn it faster. I could run "ip route" and prefix the line for the default GW with "ip route delete" and it just worked. That's how stuff should work.
On the other hand, I never moved off netstat, though my recent foray into ss revealed some really slick features.
Posted Jan 4, 2017 23:57 UTC (Wed)
by SEJeff (guest, #51588)
[Link]
Posted Jan 9, 2017 13:09 UTC (Mon)
by HenrikH (subscriber, #31152)
[Link]
Posted Jan 4, 2017 22:57 UTC (Wed)
by NightMonkey (subscriber, #23051)
[Link] (4 responses)
'<title>SS Utility: Quick Intro
From: https://git.kernel.org/cgit/linux/kernel/git/shemminger/i...
Posted Jan 6, 2017 3:36 UTC (Fri)
by flussence (guest, #85566)
[Link]
Reminds me of how history could have went if things like AsciiDoc, ReST and Markdown had never happened…
Posted Jan 6, 2017 16:47 UTC (Fri)
by dsommers (subscriber, #55274)
[Link] (2 responses)
While ss.c on the other hand have been gone through an enormous amount of development ...
This more proves that it is just too easy to forget about documentation maintenance while the source code evolves.
Posted Jan 9, 2017 15:44 UTC (Mon)
by sjas (subscriber, #111513)
[Link] (1 responses)
`ss` output is just horrible due to its automatic expansion to the full width of your terminal.
Posted Jan 9, 2017 16:37 UTC (Mon)
by NightMonkey (subscriber, #23051)
[Link]
I'm totally for tools becoming more machine-friendly, for scripts and configuration management. But I do shed a tear for no longer being able to easily use my human eyes to tell me what a system is doing because the tools have evolved away from direct human use.
Posted Jan 5, 2017 13:34 UTC (Thu)
by gwojcieszczuk (guest, #93675)
[Link]
Posted Jan 4, 2017 20:59 UTC (Wed)
by lyda (subscriber, #7429)
[Link] (7 responses)
It would be nice to see tools like ip and friends have options to emit even more machine readable output than the old net-tools tools did. From awk/sed/etc friendly delimited table type output to providing json or yaml output.
Posted Jan 4, 2017 21:14 UTC (Wed)
by dankamongmen (subscriber, #35141)
[Link]
Posted Jan 4, 2017 21:20 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
Posted Jul 11, 2019 17:46 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
Posted Jan 5, 2017 1:41 UTC (Thu)
by eduard.munteanu (guest, #66641)
[Link] (3 responses)
Posted Jan 5, 2017 2:39 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Jan 5, 2017 8:05 UTC (Thu)
by mm7323 (subscriber, #87386)
[Link] (1 responses)
Take for example the netlink socket libraries (libnl, libnl-*) which often amount to little much more than user-space constant and structure declarations with some helper macros and functions. The documentation says what these things *are* but not so much on practical use to achieve some goal (and indeed the surface area of the netlink sockets is so *huge* examples for everything would be immense - netlink is basically another syscall interface with a very high density of parameters and flags for each request).
Therefore the source to things like the 'ip' command along with strace and the kernel sources are the only way to directly program anything sufficiently advanced against this kernel interface (and calling system ("ip ...") is often much easier and I dare say more readable).
I've often thought that it takes a really good programmer to make a good API and libraries, and I'm afraid that over the years I've come to the conclusion that the Linux network guys are mainly really good at networking.
Posted Jan 5, 2017 19:53 UTC (Thu)
by samroberts (subscriber, #46749)
[Link]
I would agree, the docs are incomplete, incomprehensible, or straight-up missing, and using assert for argument checking is not something good C libs have done for a long time.
Posted Jan 5, 2017 0:20 UTC (Thu)
by Kayden (guest, #89093)
[Link] (9 responses)
Arch Linux hasn't installed net-tools by default for a long time, but I always find myself installing it, mostly for that reason.
Posted Jan 5, 2017 14:18 UTC (Thu)
by xav (guest, #18536)
[Link] (8 responses)
Posted Jan 5, 2017 16:18 UTC (Thu)
by Kayden (guest, #89093)
[Link]
Posted Jan 6, 2017 10:41 UTC (Fri)
by tsr2 (subscriber, #4293)
[Link] (2 responses)
Posted Jan 6, 2017 10:43 UTC (Fri)
by xav (guest, #18536)
[Link] (1 responses)
Posted Jan 7, 2017 11:14 UTC (Sat)
by ghane (guest, #1805)
[Link]
$ ip -V
Posted Jan 6, 2017 11:29 UTC (Fri)
by Yenya (subscriber, #52846)
[Link] (3 responses)
How can I adjust the colors to terminals with black background? (I.e. something similar to what echo 'set bg=dark' >> ~/.vimrc does for vim).
Posted Jan 6, 2017 11:58 UTC (Fri)
by xav (guest, #18536)
[Link]
Posted Jan 10, 2017 16:53 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Mar 6, 2017 8:49 UTC (Mon)
by pevik (subscriber, #112535)
[Link]
Posted Jan 5, 2017 3:31 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (4 responses)
And they're not Linux-specific -- they work on other Unixen. Linux may be the most dominant Unix-like OS today (well, except for MacOS, which last I checked does have ifconfig and the like but does not have iproute2, but admittedly most Mac users will not need such low-level commands.) But why gratuitously break compatibility with other systems, and why force people who admin those other systems to remember two sets of commands? Until reading this article I wasn't even aware that net-tools was deprecated! I think Ted Ts'o is correct.
Posted Jan 5, 2017 11:42 UTC (Thu)
by NAR (subscriber, #1313)
[Link] (2 responses)
Posted Jan 5, 2017 12:02 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (1 responses)
ifconfig without arguments is pretty much the same on all OSes that have it at all. Otherwise, they're false friends - netstat is different on Mac OS X, Windows, Linux and Solaris, as is route.
Posted Jan 6, 2017 11:19 UTC (Fri)
by mm7323 (subscriber, #87386)
[Link]
Posted Jan 9, 2017 21:35 UTC (Mon)
by shemminger (subscriber, #5739)
[Link]
Posted Jan 5, 2017 3:51 UTC (Thu)
by Fowl (subscriber, #65667)
[Link] (1 responses)
Posted Jan 16, 2017 22:09 UTC (Mon)
by plhk (guest, #111928)
[Link]
Posted Jan 5, 2017 3:52 UTC (Thu)
by bferrell (subscriber, #624)
[Link] (3 responses)
ip route add blackhole <address>
I found this in the fail2ban utility and it makes my systems disappear to identified bad guys.
And this illustrates how the entire approach to documentation of iproute2 seems at best to be baroque and convoluted causing useful features to effectively disappear.
If I do something new, exciting or just that I want to communicate, it's my responsibility to communicate that... Not my audience to extract from what I may or may not have said.
To date, other than this one thing, I've seen no advantage communicated for iproute2 other than "it's new and cool! net-tools is old, bad and you're dumb if you continue to use it".
Show me an advantage for me and my use cases, and I may change. Tell me I'm old, stodgy and dumb, and I'll just tune you out.
Posted Jan 5, 2017 3:56 UTC (Thu)
by bferrell (subscriber, #624)
[Link]
Posted Jan 5, 2017 3:59 UTC (Thu)
by bferrell (subscriber, #624)
[Link]
Posted Jan 13, 2017 3:03 UTC (Fri)
by simoncion (guest, #41674)
[Link]
Pardon? Once you remember what EBNF (and -frankly- I wish far more complicated tools would describe their options in this manner!) looks like, the manpage is quite helpful (and looks even nicer in the man viewer):
IP-ROUTE(8) Linux IP-ROUTE(8)
NAME
TYPE := [ unicast | local | broadcast | multicast | throw | unreachable
Route types:
blackhole - these destinations are unreachable. Packets are
Posted Jan 5, 2017 4:37 UTC (Thu)
by landley (guest, #6789)
[Link]
Posted Jan 5, 2017 6:21 UTC (Thu)
by prometheanfire (subscriber, #65683)
[Link]
app-benchmarks/volanomark
Posted Jan 5, 2017 9:35 UTC (Thu)
by jrigg (guest, #30848)
[Link] (9 responses)
Posted Jan 5, 2017 10:10 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (6 responses)
Systemd-networkd lives in the ecological niche otherwise occupied, among other things, by NetworkManager or your distribution's network setup scripts and is pretty much orthogonal to whatever low-level CLI tools you would use to poke around in your network configuration. It might conceivably use either inet-tools or iproute2 to actually set up the network (I wouldn't know, but it probably doesn't).
Did you need to relearn the low-level CLI network management commands when dhclient came out? No? Thought so.
Posted Jan 5, 2017 12:32 UTC (Thu)
by jrigg (guest, #30848)
[Link]
Ok, thanks for the clarification. I was thinking (perhaps misguidedly) of possible feature creep when I made my comment.
Posted Jan 5, 2017 13:16 UTC (Thu)
by fishface60 (subscriber, #88700)
[Link] (3 responses)
Posted Jan 5, 2017 15:04 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
Not really.
NetworkManager features backends for compatibility Debian/Redhat configurations. 'Ifcfg' should be compatible with Redhat style ifcfg files, but really are not. I am sure that this sort of thing has pissed off a great deal of people who found that their ifcfg machinations that previously worked fine with the ifcfg scripts failed in subtle ways under NetworkManager. A example of this is bridge configuration options are different between NetworkManager and the RH ifcfg scripts.
If I have a non-trivial network configuration to deal with I tend to do two things with NetworkManager, 1. disable the auto configuration of interfaces (no-auto-default=*). 2. disable compatibility with distro configurations and use the 'keyfile' config backend.
I don't know how well NetworkManager works with Debian-style network configuration, but I expect it's similar.
'Ifup' and 'ifdown' commands, similarly, should be avoided. It may work, but it's likely doing funky things. 'nmcli c up/down' is preferable.
systemd-networkd is interesting to me. One of the things I could never figure out with NetworkManager is the use of it to configure 'foreign' network devices. So, for example, if you are using VPNs it works fine if the VPN has a plugin that integrates with NetworkManager. But if you are using something like 'tinc' that has no NetworkManager plugin then you are stuck doing all the configuration in shell scripts. I am hoping that networkd would be able to work properly with 'non native' network devices that get created without having to deal with a complex set of requirements for plugin compatibility.
Posted Jan 5, 2017 17:48 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
FYI, I find tinc and networkd work very well together. I have configured tinc to do nothing to configure the interface (empty tinc-up script); then it is a simple matter to create myvpn.network with [Match] Name=mynetwork and then whatever configuration I need in the [Network] section. Tinc creates the interface, and networkd configures it.
Posted Jan 13, 2017 16:07 UTC (Fri)
by dcbw (guest, #50562)
[Link]
Since NM is aware of all network devices, you can apply NM configuration to them, even if NM doesn't auto-activate any configuration or directly control them. So for example, say you have a 'tun3' device created by tinc you can create an NM config with all your desired details, lock the connection to 'tun3', and then run tinc to set up the device and then 'nmcli con up my-tinc' to set up the IP configuration and DNS configuration.
Posted Jan 12, 2017 17:52 UTC (Thu)
by judas_iscariote (guest, #47386)
[Link]
No, systemd-networkd does not use any of these tools. it uses sd-netlink to talk kernel.
Posted Jan 5, 2017 10:36 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Jan 5, 2017 12:08 UTC (Thu)
by jrigg (guest, #30848)
[Link]
You're correct but you missed my point, which was that changing to something that's already been around for a few years may be wasted effort if something new is likely to supplant it in the near future.
Posted Jan 5, 2017 15:55 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link]
It feels wrong to call a 23-page document a "sheet".
Posted Jan 5, 2017 16:23 UTC (Thu)
by jackb (guest, #41909)
[Link] (4 responses)
The obvious solution is for iproute2 to ship thin wrappers that provide ifconfig, route, etc. so that you don't break muscle memory, existing scripts, and the huge accumulation of documentation across the ecosystem. Surely there must also be an equally-obvious reason this approach wasn't taken.
Posted Jan 5, 2017 19:42 UTC (Thu)
by Chousuke (subscriber, #54562)
[Link] (3 responses)
The problem is that so long as you have ifconfig etc. you have more code that needs to be maintained and tested, and if distributions can eliminate a dependency on the deprecated tools, that is one variable removed from the equation.
Posted Jan 5, 2017 19:46 UTC (Thu)
by sfeam (subscriber, #2841)
[Link] (2 responses)
Posted Jan 5, 2017 19:54 UTC (Thu)
by Chousuke (subscriber, #54562)
[Link] (1 responses)
My point was that writing new code to as compatibility layers for the newer tools is pointless because the old tools still work and instead of lessening the maintenance burden, the wrappers would actually do the opposite.
Posted Jan 9, 2017 11:10 UTC (Mon)
by roblucid (guest, #48964)
[Link]
Posted Jan 6, 2017 13:15 UTC (Fri)
by thyrsus (guest, #21004)
[Link] (4 responses)
arp -Ds <host> <interface> pub
...which is useful when proxying an IP address in situations like this: http://www.ncsysadmin.org/meetings/1303/NCSA_2013-03-11-5...
ifconfig <interface>:<n> <addr> netmask <netmask> up
...which adds a name to the interface, and you can manipulate most properties of the new name without changing any properties of the original interface.
I vaguely think I see my way to getting the effects of the ifconfig incantation while getting different artifacts, but I don't see how to do the former at all. Perhaps it's added in a later version than my CentOS 7:
$ ip -V
Posted Jan 6, 2017 13:33 UTC (Fri)
by thyrsus (guest, #21004)
[Link] (1 responses)
ip addr add <address>/<mask bits> broadcast + dev <interface> label <interface>:<n>
Posted Jan 10, 2017 16:56 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Jan 6, 2017 22:01 UTC (Fri)
by thyrsus (guest, #21004)
[Link] (1 responses)
ip neigh add proxy <host> dev <interface>
...except "ip neigh show" doesn't list them - I see it succeeded with "arp -a".
Posted Jan 6, 2017 22:20 UTC (Fri)
by TomH (subscriber, #56149)
[Link]
Posted Jan 6, 2017 15:58 UTC (Fri)
by jengelh (guest, #33263)
[Link]
ip output is definitely more parser-friendly than ifconfig... the latter changed output at the brink of LC_MESSAGES.
(And unrelated, I point out that Solaris's ifconfig output looks like iproute2's.)
Posted Jan 6, 2017 19:31 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (6 responses)
Posted Jan 6, 2017 23:07 UTC (Fri)
by thyrsus (guest, #21004)
[Link] (1 responses)
ip addr add 172.16.2.1/25 broadcast + dev enp3s0f2
Posted Jan 12, 2017 6:10 UTC (Thu)
by fest3er (guest, #60379)
[Link]
The broadcast address is automatic with IPv4; there's no need to specify it *unless* you want it on a non-standard address. (Yes, you can set the broadcast address for 10.10.10.55/24 to 10.10.10.56 or most any other address in that LAN; but all hosts on that LAN would have to use the same broadcast address for networking to work.) You should get used to not setting the broadcast address because IPv6 doesn't use them. works very well. You can add more addresses without requiring the archaic alias interface syntax: If you are a dinosaur, you can The first address added in a LAN is the primary address for that LAN; all other addrs in that LAN are secondary. You can, in fact, add addresses for thousands of LANs to a single interface. And they all just work. (If you delete the primary address, the first-added of the remaining address(es) in that LAN becomes the primary addr for that LAN. I think; it's been a while since I tested it.) If you want to see link status and addresses, If you just want to see link status, For routing, shows the usual routes, while I recently removed net-tools from Smoothwall Express after deprecating it a couple years ago. There were a couple uses I had missed when I changed Express to iproute2. Other than the occasional query, there've been no problems; the mod devs took it in stride and converted fairly easily; adequate examples were easy to find.
Posted Jan 7, 2017 3:28 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (3 responses)
When I first used an IP network I assumed that everything I saw had some real purpose, if I needed to write out 255.255.255.248 instead of just 29, it must be because it was, or had been possible to write 10.20.30.40 in that box instead and do something useful. But yeah, no.
Netmasks are a weirdly clumsy way to express subnetwork sizes, the modern CIDR "slash notation" is simpler to type, netmasks were deprecated about 20 years ago, but they've stuck around in older tools, used by people who never learned any newer tools. So we have a transition where maybe 15 years ago a tool would have said "Oh, or you can write a netmask if you prefer" and maybe 10 years ago the documentation would have said "This tool doesn't use netmasks, simply write out an address in slash notation" and today some of the tool authors have never used a netmask, why would they mention it in the documentation?
Life requires a certain balance between being willing to learn new things, and yet being stubborn enough not to chase every fad. It's possible to argue about exactly where the right balance is, but I think if you want netmasks in 2017 you've gone a bit too far in the "stubborn" direction.
Posted Jan 7, 2017 20:05 UTC (Sat)
by swilmet (subscriber, #98424)
[Link] (2 responses)
Posted Jan 10, 2017 14:50 UTC (Tue)
by artizirk (subscriber, #113443)
[Link] (1 responses)
Posted Jan 19, 2017 18:13 UTC (Thu)
by swilmet (subscriber, #98424)
[Link]
Posted Jan 6, 2017 20:01 UTC (Fri)
by vapier (guest, #15768)
[Link]
this makes it sound like the output change happened recently. it actually happened over 10 years ago. what has changed recently is that Debian finally included that change in their builds. any recent resumption of development is independent of that change.
it could reasonably be argued that part of the problem is lack of net-tools releases. the counter point is that Debian has been shipping snapshots for years but was sitting on this change independently the entire time.
Posted Jan 9, 2017 9:57 UTC (Mon)
by janos (guest, #94392)
[Link]
Posted Jan 9, 2017 23:19 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I have ifconfig and netstat options burned into my muscle memory and retraining will take an actual effort.
I used to have "/etc/init.d/service restart" memory encoded in my fingertips that I retrained to "systemctl" commands. There was a clear advantage - systemctl is way nicer and actually has important new features.
But I'm not seeing any real advantage here. Sure, ifconfig doesn't support all the new networking features, but basic "ifconfig blah0 up" still works just fine. And nettools are going to be supported and maintained for many years to come (tons of scripts depend on them) even if they are not installed by default.
So, meh.
Posted Jan 11, 2017 15:12 UTC (Wed)
by mirabilos (subscriber, #84359)
[Link] (2 responses)
A cheat sheet would collect often-used ifconfig/route/netstat (argh, they can’t kill netstat!) commands and their equivalents in a simple two-column (maybe three with notes) table. Short and concise.
Posted Jan 12, 2017 9:28 UTC (Thu)
by hrw (subscriber, #44826)
[Link]
Posted Feb 13, 2018 11:52 UTC (Tue)
by dmbaturin (guest, #122549)
[Link]
The short and concise approach breaks down in cases such as interfaces aliases, so I deliberately avoided it from the start and chose to organize it by network administration task instead.
Posted Jan 13, 2017 9:06 UTC (Fri)
by zoobab (guest, #9945)
[Link] (8 responses)
http://unix.stackexchange.com/questions/87468/is-there-an...
We have to resort to awk and grep.
In 2016, I would expect at least a JSON output that can be parsed properly, not expecting errors from awk or grep.
And even better, an option in the command line.
Posted Jan 13, 2017 21:44 UTC (Fri)
by zlynx (guest, #2285)
[Link] (7 responses)
A quick scan over available man-pages shows we've got "man getifaddrs" which explains an available function ported to Linux from the BSDs. And there is "man if_nameindex" with a POSIX version. There is the direct Linux ioctl interfaces as well in "man netdevice"
Posted Jan 13, 2017 22:54 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Posted Jan 13, 2017 23:17 UTC (Fri)
by zlynx (guest, #2285)
[Link] (4 responses)
And seriously, someone wanted JSON output? JSON is almost impossible to deal with in bash. The only tool I've seen that makes it possible is "jq", and I had to build that manually since Fedora didn't ship it. Although I see it is in the repos for F25 so they finally got it.
So processing the text output of ifconfig or ip is really the bash way to get it done. That's how everything gets done in bash.
Posted Jan 13, 2017 23:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
JSON is extremely easy to parse and tools to do it are now built-in into various languages. On the other hand, calling the kernel and then parsing complicated structures is often fraught with problems.
Posted Jan 13, 2017 23:59 UTC (Fri)
by zlynx (guest, #2285)
[Link] (2 responses)
And this, which is more modern:
I'm not going to look up Ruby, but I know Perl has similar modules, because I used one in the past (2005'ish)
Posted Jan 14, 2017 0:06 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
And anyway, why would you make a Linux tool that is user-hostile to scripting users? I understand that people might not have been thinking about it 10 years ago, but defending this like it's a good thing - that's just stupidity.
Posted Jan 14, 2017 21:09 UTC (Sat)
by zlynx (guest, #2285)
[Link]
Posted Jan 14, 2017 4:54 UTC (Sat)
by lsl (subscriber, #86508)
[Link]
You use ifdata(1). Moreutils are quite useful.
Posted Jan 29, 2017 13:23 UTC (Sun)
by GNUtoo (guest, #61279)
[Link] (1 responses)
Posted Jan 30, 2017 13:28 UTC (Mon)
by grawity (subscriber, #80596)
[Link]
As for slattach, I guess there's no alternative to it because of how rarely it's used? Much like iproute2 doesn't care about IPX.
I mean, if you have a need for some or other net-tools app, I don't see a problem with using it. It's when one expects to successfully troubleshoot network problems using commands which omit important information, then the problems start.
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
<author>Alexey Kuznetsov, <tt/kuznet@ms2.inr.ac.ru/
<date>some_negative_number, 20 Sep 2001
<abstract>
<tt/ss/ is one another utility to investigate sockets.
Functionally it is NOT better than <tt/netstat/ combined
with some perl/awk scripts and though it is surely faster
it is not enough to make it much better. :-)
So, stop reading this now and do not waste your time.
Well, certainly, it proposes some functionality, which current
netstat is still not able to do, but surely will soon.
</abstract>'
Moving on from net-tools
Moving on from net-tools
https://git.kernel.org/cgit/linux/kernel/git/shemminger/i...
https://git.kernel.org/cgit/linux/kernel/git/shemminger/i...
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
So "netstat -tnlp" could be replaced with "ss -tnlp".
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Option "-c" is unknown, try "ip -help".
Moving on from net-tools
ip utility, iproute2-ss161212
Moving on from net-tools
ip utility, iproute2-ss151103
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
See recently merged patch
https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=54eab4c79a6086f4d1e15ce228163514d2d2415b.
Try it:
Moving on from net-tools
COLORFGBG='15;0' ip -c a
Konsole, rxvt and rxvt-unicode set environment variable COLORFGBG out of box. For others (gnome-terminal, xterm) you have to set it manually or with a help with xtermcontrol.
Moving on from net-tools
Many of these tools have a long pedigree, at least in spirit, having originally been written before the first Linux kernel.
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
ip-route - routing table management
~snip~
| prohibit | blackhole | nat ]
~snip~
DESCRIPTION
ip route is used to manipulate entries in the kernel routing tables.
~snip~
discarded silently. The local senders get an EINVAL error.
Moving on from net-tools
Moving on from net-tools
dev-db/mysql-workbench
dev-ruby/facter
net-analyzer/bwm-ng
net-analyzer/nmbscan
net-misc/dhcp
net-misc/knemo
net-misc/openvpn
net-misc/vmnet
net-misc/wicd
net-wireless/blueman
sys-apps/coreutils
www-servers/servefile
xfce-extra/xfce4-wavelan-plugin
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
since NetworkManager quite happily coexists with networkd or ifupdown
and is more for the desktop-user-level networking configuration,
while networkd and ifupdown are for network configuration that isn't expected to change all the time, so handy for desktops, servers and containers.
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
...so there is no benefitMoving on from net-tools
On the contrary, there is a clear benefit. Existing older scripts don't break and existing older users do not have to be retrained. You can argue about cost vs benefit, but the benefit is > 0.
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
ip utility, iproute2-ss130716
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
>The fact that the iproute2 commands are seen [...] as having less readable (and less machine-parseable) output doesn't help either.
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
ip addr add 10.20.30.34/24 dev eth1
ip addr add 10.20.30.2/24 dev eth1
ip addr add 10.20.30.129/24 dev eth1
ip addr add 10.255.255.1/8 dev eth1
ip addr add 10.45.67.89/255.255.254.0
ip addr
shows the state of all the links with the L2 and IPv{4,6} addressing.
ip link
shows the state of all the links with only the L2 addressing. And both the link and addr commands take the 'dev NIC' args as well to limit display to a single NIC.
ip route
ip route list table all
shows more routing information than most ever want to see.Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
misleading statement
Moving on from net-tools
e.g. if I just want to bring up an interface, why is it done via the "ip" command? If it has to be via the "ip" command, should it be "ip" or "ip -6"?
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Moving on from net-tools
Just outout an IP address of an interface?
Just outout an IP address of an interface?
Just outout an IP address of an interface?
Just output an IP address of an interface?
Just output an IP address of an interface?
Just output an IP address of an interface?
http://stackoverflow.com/questions/166506/finding-local-i...
https://pypi.python.org/pypi/pyroute2/
https://github.com/svinota/pyroute2
Just output an IP address of an interface?
Just output an IP address of an interface?
Just outout an IP address of an interface?
Moving on from net-tools
- mii-tool: The verbose options permits to dump the Ethernet PHY registers. I don't think that ethtool can do that.
- slattach: This permits to have an Ethernet interface over a serial port.
I think the ethtool philosophy is to expose higher-level settings, not raw registers, but yes:
Moving on from net-tools
ethtool -d|--register-dump DEVNAME Do a register dump
[ raw on|off ]
[ file FILENAME ]
ethtool -e|--eeprom-dump DEVNAME Do a EEPROM dump
[ raw on|off ]
[ offset N ]
[ length N ]
ethtool -E|--change-eeprom DEVNAME Change bytes in device EEPROM
[ magic N ]
[ offset N ]
[ length N ]
[ value N ]