Bug#820212: iproute2: Colons in ethernet names under /sbin/ifconfig and /sbin/ip are not being recognized in Stretch

Wed Apr 6 23:02:37 UTC 2016

Hello Bob,
Now we're on the same page, that was an excellent read.

If I could change the script, I would. But it's maintained by the company who makes the firewall agent and application, so a simple awk or cut will break the whole operation of the agent if it's not made upstream. Their source code is viewable but when I edited it, it failed miserably.

I took a guess at the package, I knew it would be either iproute2 or net-tools. I'm glad you understood which direction to take.

So yes, ultimately, the goal is to have that unnecessary colon removed from the end of the interface name. That in turn should likely fix this agent and I won't have to downgrade some servers to deb8 to make it compatible for one thing. I actually intended to make the server debian 8, but I mistakenly didn't create an apt preferences file in my image to only use the sid repo for apache and another program. So it ended up upgrading all packages to make it a debian 9 installation. In any case, this is the only thing I am having a bottleneck at.

On Wed, Apr 06, 2016 at 5:49 PM, Bob Proulx <bob at proulx.com<mailto:bob at proulx.com>> wrote:

reassign 820212 net-tools
found 820212 1.60+git20150829.73cef8a-2
retitle 820212 ifconfig output format change breaks downstream programs
thanks

Hi Justin,

Justin McZeal wrote:
> Starting from the beginning, ...

:-)

> there is this firewall agent we have

Reading your latest I think I understand better.  Let me rephrase what
you are saying.

In Jessie 8 from net-tools version 1.60-26+b1:

  # ifconfig --version
  net-tools 1.60
  ifconfig 1.42 (2001-04-13)

In Stretch Testing today net-tools version 1.60+git20150829.73cef8a-2:

  # ifconfig --version
  net-tools 2.10-alpha

The 'ifconfig' output format has changed to add a colon after the
device name.

In net-tools 1.60 ifconfig 1.42 (2001-04-13):

  # ifconfig eth0 | grep ^eth0
  eth0      Link encap:Ethernet  HWaddr 00:50:56:b5:00:23

In net-tools 2.10-alpha:

  # ifconfig eth0 | grep ^eth0
  eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

The problem you have is that new ":" in the first field is causing
problems for a tool that is processing the output of ifconfig and
never having had to deal with the colon before and doesn't strip it
off and therefore hands the resulting string "eth0:" off to further
processing which fails because the colon isn't part of the device
name.

  eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
      ^ colon is causing you problems

I hope that sums up the basic facts.  Please correct any
misunderstanding in the above if so.

I think you got distracted in the cascade of problems downstream of
that because then the tool causing you problems is apparently trying
to use "eth0:" without stripping the colon off of it in order to get a
handle on the device name.  But "eth0:" isn't the device name.  That
colon is just there as an indicator.

Note that the problem you are having is with an output format change
of 'ifconfig' which is part of the 'net-tools' package but you filed
this bug against the 'iproute2' package.  I am a long time complainer
when long time tools change without significant reason.  But that is
the best reason to be running Sid Unstable so as to be able to detect
these problems and file a bug before they hit Testing and become a
potential release candidate.  Better to catch it in Sid than Testing.

I think this bug should be reassigned to the net-tools package with a
request to revert the output format change of ifconfig.  Sure parsing
the output of this legacy command arguably isn't a good idea.  But
changing the output format is going to catch a lot of programs that
have been parsing it for decades.  [[However if the goal is to
deprecate ifconfig then forcing changes is one way to force people to
move.  Because they will have to update their parsing in order to work
at all.]]

> This agent is proprietary, so I can only share the basic cases it
> uses to get the interfaces.

Worse I am sure it is only approved on other platforms but you are
running it on Debian because you prefer Debian and it works there.
And so you are working at a support disadvantage because you want to
upgrade to Testing for some reason and are trying to make things work.
At least that has been my case many times with proprietary software.
Hopefully I am close on this analysis.

Questions: Can you make any modifications to the software locally?  Is
it a script?  It must be because you seem to have deep knowledge of
it.  Or did you find this by running 'strings' on the binary?  I have
some possible suggestions for working around this depending upon what
additional information you provide.

> Now, back to the first case, if that "ifconfig |grep flags=...."
> worked, which it only did on Debian 9 Stretch, it would use the
> below command to grab the interface information. But note, it's
> running based on the output of eth0: and not just eth0.

If you can modify the parsing code then why not simply remove the
trailing colon from the field name?  At the same time convert from
using 'ifconfig' to 'ip'.  If an old dog like me can learn the new
tricks then that should show that it isn't impossible for others.

'ifconfig' only knows about the legacy networking and can't manage or
report on the newer networking features that have been added to the
kernel in recent years.  If making any changes at all then it is
better to migrate from 'ifconfig' to 'ip' at that time.

> /sbin/ip -o link show eth0: |grep ether - This will NOT run on my
> Debian 9 Stretch because from the output it got from ifconfig with
> the eth0:, eth0: becomes invalid as a device name. The whole point
> of the bug report is to point out that extra colon that throws
> everything off. The only way for this to work on Stretch is without
> the colon at the end.

I now understand your complaint and I see the issue but I see the
issue differently than you described it.  Your description makes it
appear that you think the colon must be part of the device name
because it appears in the first field and then are trying to use it
with the 'ip' command as the device name.  But that colon isn't part
of the first field and isn't part of the device name.  That colon is
there as a hint to the human reading the human readable output that it
is a label before the colon tagging the object that follows.  If a
human were reading that they would know that "eth0" is the device name
and ignore the ":" lable indicator.  And therefore it is arguable that
the problem is that the program parsing the output must react to the
format change of ifconfig and now know about the ":" and remove it.
(Better if the output format of a very long lived tool like ifconfig
didn't change.)  The problem isn't that ip can't recognize a device
with a spurious colon on the end.  That colon isn't part of the device
name.

Note that the 'ip' output also uses a colon to designate to the human
reading it that the string before it is a label tagging the thing
appearing next to the right.  This is exactly the same as in your
message here:

> Debian 9 Stretch:

The version is "Stretch" not "Stretch:" because the colon indicates
the thing to the left is a label tagging the thing that follows.
(Just like my use of "here:" to introduce it.)  It was just a perfect
illustration of the use of the colon and I couldn't pass it up. :-)

> # /sbin/ip -o link show eth0: |grep ether
> RTNETLINK answers: No such device
> Cannot send link get request: No such device

Trying to put forward that the above doesn't work is not the right
direction to take this since the colon is not part of the device
name.  This is simply a cascade failure that happens later down the
pipeline of processing because parsing the new ifconfig output saw it
in that field.  But with the new output it would need to be removed
before using it further.

> can that particular issue be corrected? Where it goes back to the
> Debian 8 and below format of just outputting eth0 and not eth0:

I would say the place to find out is with the net-tools maintainers.
I definitely vote that the output format of 'ifconfig' not change
gratuitously.  Your breakage due to it is likely to just be the tip of
an iceberg of others that will have similar problems due to it.

I am reassigning this bug to the net-tools and request that the
ifconfig output format not be changed after all of these years.  The
net-tools maintainers will read this and I look forward to hearing
their input on this.

Bob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-net-tools-maintainers/attachments/20160406/bd45670d/attachment.html>