<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<p dir="ltr">Hello Bob,<br>
Now we're on the same page, that was an excellent read. </p>
<p dir="ltr">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. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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. </p>
<div class="cm_quote" style=" color: #787878">On Wed, Apr 06, 2016 at 5:49 PM, Bob Proulx <<a href="mailto:bob@proulx.com">bob@proulx.com</a>> wrote:</div>
<br>
<div id="oldcontent" style="background: rgb(255, 255, 255);">
<blockquote style="">
<p dir="ltr">reassign 820212 net-tools <br>
found 820212 1.60+git20150829.73cef8a-2 <br>
retitle 820212 ifconfig output format change breaks downstream programs <br>
thanks <br>
<br>
Hi Justin, <br>
<br>
Justin McZeal wrote: <br>
> Starting from the beginning, ... <br>
<br>
:-) <br>
<br>
> there is this firewall agent we have <br>
<br>
Reading your latest I think I understand better. Let me rephrase what <br>
you are saying. <br>
<br>
In Jessie 8 from net-tools version 1.60-26+b1: <br>
<br>
# ifconfig --version <br>
net-tools 1.60 <br>
ifconfig 1.42 (2001-04-13) <br>
<br>
In Stretch Testing today net-tools version 1.60+git20150829.73cef8a-2: <br>
<br>
# ifconfig --version <br>
net-tools 2.10-alpha <br>
<br>
The 'ifconfig' output format has changed to add a colon after the <br>
device name. <br>
<br>
In net-tools 1.60 ifconfig 1.42 (2001-04-13): <br>
<br>
# ifconfig eth0 | grep ^eth0 <br>
eth0 Link encap:Ethernet HWaddr 00:50:56:b5:00:23 <br>
<br>
In net-tools 2.10-alpha: <br>
<br>
# ifconfig eth0 | grep ^eth0 <br>
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 <br>
<br>
The problem you have is that new ":" in the first field is causing <br>
problems for a tool that is processing the output of ifconfig and <br>
never having had to deal with the colon before and doesn't strip it <br>
off and therefore hands the resulting string "eth0:" off to further <br>
processing which fails because the colon isn't part of the device <br>
name. <br>
<br>
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 <br>
^ colon is causing you problems <br>
<br>
I hope that sums up the basic facts. Please correct any <br>
misunderstanding in the above if so. <br>
<br>
I think you got distracted in the cascade of problems downstream of <br>
that because then the tool causing you problems is apparently trying <br>
to use "eth0:" without stripping the colon off of it in order to get a <br>
handle on the device name. But "eth0:" isn't the device name. That <br>
colon is just there as an indicator. <br>
<br>
Note that the problem you are having is with an output format change <br>
of 'ifconfig' which is part of the 'net-tools' package but you filed <br>
this bug against the 'iproute2' package. I am a long time complainer <br>
when long time tools change without significant reason. But that is <br>
the best reason to be running Sid Unstable so as to be able to detect <br>
these problems and file a bug before they hit Testing and become a <br>
potential release candidate. Better to catch it in Sid than Testing. <br>
<br>
I think this bug should be reassigned to the net-tools package with a <br>
request to revert the output format change of ifconfig. Sure parsing <br>
the output of this legacy command arguably isn't a good idea. But <br>
changing the output format is going to catch a lot of programs that <br>
have been parsing it for decades. [[However if the goal is to <br>
deprecate ifconfig then forcing changes is one way to force people to <br>
move. Because they will have to update their parsing in order to work <br>
at all.]] <br>
<br>
> This agent is proprietary, so I can only share the basic cases it <br>
> uses to get the interfaces. <br>
<br>
Worse I am sure it is only approved on other platforms but you are <br>
running it on Debian because you prefer Debian and it works there. <br>
And so you are working at a support disadvantage because you want to <br>
upgrade to Testing for some reason and are trying to make things work. <br>
At least that has been my case many times with proprietary software. <br>
Hopefully I am close on this analysis. <br>
<br>
Questions: Can you make any modifications to the software locally? Is <br>
it a script? It must be because you seem to have deep knowledge of <br>
it. Or did you find this by running 'strings' on the binary? I have <br>
some possible suggestions for working around this depending upon what <br>
additional information you provide. <br>
<br>
> Now, back to the first case, if that "ifconfig |grep flags=...." <br>
> worked, which it only did on Debian 9 Stretch, it would use the <br>
> below command to grab the interface information. But note, it's <br>
> running based on the output of eth0: and not just eth0. <br>
<br>
If you can modify the parsing code then why not simply remove the <br>
trailing colon from the field name? At the same time convert from <br>
using 'ifconfig' to 'ip'. If an old dog like me can learn the new <br>
tricks then that should show that it isn't impossible for others. <br>
<br>
'ifconfig' only knows about the legacy networking and can't manage or <br>
report on the newer networking features that have been added to the <br>
kernel in recent years. If making any changes at all then it is <br>
better to migrate from 'ifconfig' to 'ip' at that time. <br>
<br>
> /sbin/ip -o link show eth0: |grep ether - This will NOT run on my <br>
> Debian 9 Stretch because from the output it got from ifconfig with <br>
> the eth0:, eth0: becomes invalid as a device name. The whole point <br>
> of the bug report is to point out that extra colon that throws <br>
> everything off. The only way for this to work on Stretch is without <br>
> the colon at the end. <br>
<br>
I now understand your complaint and I see the issue but I see the <br>
issue differently than you described it. Your description makes it <br>
appear that you think the colon must be part of the device name <br>
because it appears in the first field and then are trying to use it <br>
with the 'ip' command as the device name. But that colon isn't part <br>
of the first field and isn't part of the device name. That colon is <br>
there as a hint to the human reading the human readable output that it <br>
is a label before the colon tagging the object that follows. If a <br>
human were reading that they would know that "eth0" is the device name <br>
and ignore the ":" lable indicator. And therefore it is arguable that <br>
the problem is that the program parsing the output must react to the <br>
format change of ifconfig and now know about the ":" and remove it. <br>
(Better if the output format of a very long lived tool like ifconfig <br>
didn't change.) The problem isn't that ip can't recognize a device <br>
with a spurious colon on the end. That colon isn't part of the device <br>
name. <br>
<br>
Note that the 'ip' output also uses a colon to designate to the human <br>
reading it that the string before it is a label tagging the thing <br>
appearing next to the right. This is exactly the same as in your <br>
message here: <br>
<br>
> Debian 9 Stretch: <br>
<br>
The version is "Stretch" not "Stretch:" because the colon indicates <br>
the thing to the left is a label tagging the thing that follows. <br>
(Just like my use of "here:" to introduce it.) It was just a perfect <br>
illustration of the use of the colon and I couldn't pass it up. :-) <br>
<br>
> # /sbin/ip -o link show eth0: |grep ether <br>
> RTNETLINK answers: No such device <br>
> Cannot send link get request: No such device <br>
<br>
Trying to put forward that the above doesn't work is not the right <br>
direction to take this since the colon is not part of the device <br>
name. This is simply a cascade failure that happens later down the <br>
pipeline of processing because parsing the new ifconfig output saw it <br>
in that field. But with the new output it would need to be removed <br>
before using it further. <br>
<br>
> can that particular issue be corrected? Where it goes back to the <br>
> Debian 8 and below format of just outputting eth0 and not eth0: <br>
<br>
I would say the place to find out is with the net-tools maintainers. <br>
I definitely vote that the output format of 'ifconfig' not change <br>
gratuitously. Your breakage due to it is likely to just be the tip of <br>
an iceberg of others that will have similar problems due to it. <br>
<br>
I am reassigning this bug to the net-tools and request that the <br>
ifconfig output format not be changed after all of these years. The <br>
net-tools maintainers will read this and I look forward to hearing <br>
their input on this. <br>
<br>
Bob <br>
<br>
</p>
</blockquote>
</div>
</body>
</html>