Description of problem: [joshua@barton joshua]$ netstat -in Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg n: error fetching interface information: Device not found Version-Release number of selected component (if applicable): RHEL3 with all updates (and Fedora with all updates) How reproducible: run "netstat -in" as a user or as root
Thats because the latest net-tools contains a fixed version of netstat which works much more according to the manpage: --interface=iface , -i Display a table of all network interfaces, or the specified iface). which means that the parameter coming after -i is the interface on which netstat now listens. So you either have to do netstat -ni or netstat -i -n now for it to work correctly again as netstat otherwise tries to read interface "n", which obviously doesn't exsist on your machine. Read ya, Phil
Having looked at Solaris and FreeBSD netstat man pages I tend to agree that there should be a separate option for specifying a particular interface, especially since passing an interface name as an argument to -i has never worked in the past. However, now that we've "broken" it once by making the behavior match the man page, can we do so again to "fix" it? As an aside, the fact that 'netstat -an -i eth0' fails with usage message while 'netstat -an -ieth0' works is broken IMHO.
So what is the best way to fix this? "netstat -an -i eth0" should work
Well if you can find an example of a short option that takes an optional argument we may be able to work with that, but I can't think of any ATM. I see a way out if we maintain the historical behavior of -i, which is to add -I<iface> to handle the specifying a particular interface. OTOH, if we insist on bending the software to match the docs after all this time, I'm not sure what can be done. Any ideas?
The netstat package is now already out and used by a customer with that change for the -i option, so changing that back is not recommendable. Could you please check back with the other customer if he can't change his scripts to use netstat -ni instead of netstat -in? Thanks, Read ya, Phil
I will ask. j
So I believe the complaint here is that our netstat is out-of-step with all others. I like Dave's idea from comment #7. Is that a possibility? J
For comment one: Nothing in the man pages says that the item after the '-i' is the specified interface. The man pages should then read: --interface=iface , -i=iface Display a table of all network interfaces, or the specified iface). OR --interface=iface , -iiface Display a table of all network interfaces, or the specified iface). This interpretation goes against the action of the command in the previous release, other RedHat variants and every Unix variant I could attempt. To change the command functionality to match a bogus man page is an insane action. Fix the man page, not the code action. We have automated scripts that work just fine in Pensacola (as well as AIX, HP/UX, and Solaris) and fail in Taroon.
This should be addressed in the next update. The beta RHEL3 U5 packages on RHN should have the change you are seeking. J
I know I'm joining the party late, but why doesn't "netstat -ni" list the IP information in other Unix's (AIX and Sun I know for sure do). Is it possible to update the code to display the IP? AIX (I edited out my ip): netstat -ni Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll lo0 16896 link#1 6416072 0 6428625 0 0 lo0 16896 127 127.0.0.1 6416072 0 6428625 0 0 Solaris: netstat -ni Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 127.0.0.0 127.0.0.1 86225441 0 86225441 0 0 0 Thanks for any info you can provide.
Fix confirmed with: net-tools-1.60-20E.7 (RHEL3-U5) net-tools-1.60-37.EL4.6 (RHEL4-U1) So moving to PROD_READY. As for the issue in comment 32, please open a separate IssueTracker so that we can track that issue.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-445.html