FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 11-24-2010, 06:21 AM
Camaleón
 
Default Bonded NIC's did not come up at boot?

On Tue, 23 Nov 2010 15:28:10 -0600, Stan Hoeppner wrote:

> Camaleón put forth on 11/23/2010 2:38 AM:

>>> It's not a bug. It's feature incomplete. It seems clear that the
>>> author(s) never intended it to be used on virtual NICs.
>>
>> Then better than providing wrong information to the user is displaying
>> nothing or a simple warning ("feature not -yet- implemented").
>
> Or, maybe the authors assume people will use the tool as intended:

There is a slight difference in the output of "mii-tool" and "ethtool"
when specifying a bonded interface. While the first shows unrealistic
data, the latter just says "No data available" which I find it a better
approach (trustworthy, at least).

> This utility checks or sets the status of a network interface's
> Media Independent Interface (MII) unit. Most fast ether-
> net adapters use an MII to autonegotiate link speed and duplex
> setting.
>
> Virtual adapters don't have an MII. MII is hardware in silicon. Virtual
> adapters don't have silicon.

Then better don't say (not "you", but mii-tool) virtual link is at 10
Mbit/s. That's misleading.

> It should be clear to anyone reading the mii-tool man page, and
> possessing some common sense, that the tool will not work properly on a
> virtual adapter. If you don't understand this, talk to the authors:

(...)

No need to be "picky", everything can be improved. Error management and
user interaction are also an important part of programming design and
development.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2010.11.24.07.21.43@gmail.com">http://lists.debian.org/pan.2010.11.24.07.21.43@gmail.com
 
Old 11-24-2010, 09:09 AM
Stan Hoeppner
 
Default Bonded NIC's did not come up at boot?

Camaleón put forth on 11/24/2010 1:21 AM:
> On Tue, 23 Nov 2010 15:28:10 -0600, Stan Hoeppner wrote:

>> It should be clear to anyone reading the mii-tool man page, and
>> possessing some common sense, that the tool will not work properly on a
>> virtual adapter. If you don't understand this, talk to the authors:
>
> (...)
>
> No need to be "picky", everything can be improved. Error management and
> user interaction are also an important part of programming design and
> development.

I think you're assuming that since mii-tool doesn't bomb out when
specifying a virtual NIC, but actually shows some data on link speed and
duplex, that it _should_ give an error for those instead. If it bombed
out instead, what would you be saying? You'd be saying what I have:
It's not designed to work with virtual NICs.

Write the developers and ask them to make the next version bomb with
virtual NICs, which is what it should do.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CECE471.7090509@hardwarefreak.com">http://lists.debian.org/4CECE471.7090509@hardwarefreak.com
 
Old 11-24-2010, 09:58 AM
Camaleón
 
Default Bonded NIC's did not come up at boot?

On Wed, 24 Nov 2010 04:09:53 -0600, Stan Hoeppner wrote:

> Camaleón put forth on 11/24/2010 1:21 AM:

(...)

>> No need to be "picky", everything can be improved. Error management and
>> user interaction are also an important part of programming design and
>> development.
>
> I think you're assuming that since mii-tool doesn't bomb out when
> specifying a virtual NIC, but actually shows some data on link speed and
> duplex, that it _should_ give an error for those instead. If it bombed
> out instead, what would you be saying? You'd be saying what I have:
> It's not designed to work with virtual NICs.
>
> Write the developers and ask them to make the next version bomb with
> virtual NICs, which is what it should do.

Why bombing?

A warning message is far more elegant and useful since makes the user to
question himself if he is using the right tool for the job.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2010.11.24.10.58.30@gmail.com">http://lists.debian.org/pan.2010.11.24.10.58.30@gmail.com
 
Old 11-24-2010, 12:04 PM
Stan Hoeppner
 
Default Bonded NIC's did not come up at boot?

Camaleón put forth on 11/24/2010 4:58 AM:
> On Wed, 24 Nov 2010 04:09:53 -0600, Stan Hoeppner wrote:
>
>> Camaleón put forth on 11/24/2010 1:21 AM:
>
> (...)
>
>>> No need to be "picky", everything can be improved. Error management and
>>> user interaction are also an important part of programming design and
>>> development.
>>
>> I think you're assuming that since mii-tool doesn't bomb out when
>> specifying a virtual NIC, but actually shows some data on link speed and
>> duplex, that it _should_ give an error for those instead. If it bombed
>> out instead, what would you be saying? You'd be saying what I have:
>> It's not designed to work with virtual NICs.
>>
>> Write the developers and ask them to make the next version bomb with
>> virtual NICs, which is what it should do.
>
> Why bombing?
>
> A warning message is far more elegant and useful since makes the user to
> question himself if he is using the right tool for the job.

Oh, so you want a product safety warning, like that found on a can of
spray paint saying "POISON: Do not inhale contents"?

~# ethtool lo
Settings for lo:
Link detected: yes

~# mii-tool lo
SIOCGMIIPHY on 'lo' failed: Operation not supported

There is no link for ethtool to detect, so it's output is BS. mii-tool
at least gave a reasonably clear error in this case. However...

Pointing mii-tool or ethtool at a virtual NIC is just as stupid as
pointing it at the loopback device as both are, once again, VIRTUAL
devices, and have no physical parameters such as link speed or duplex,
because they don't have a PHY. These tools are designed to query a PHY
for link speed and duplex.

Do you understand my point now? Only ignorant people would point
mii-tool or ethtool at a _virtual_ NIC, just as only ignorant people
would point these tools at the loopback device. Do you understand my
point? Did I really need to be this blunt?

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CED0D6F.3040809@hardwarefreak.com">http://lists.debian.org/4CED0D6F.3040809@hardwarefreak.com
 
Old 11-24-2010, 01:29 PM
Camaleón
 
Default Bonded NIC's did not come up at boot?

On Wed, 24 Nov 2010 07:04:47 -0600, Stan Hoeppner wrote:

> Camaleón put forth on 11/24/2010 4:58 AM:

>>> Write the developers and ask them to make the next version bomb with
>>> virtual NICs, which is what it should do.
>>
>> Why bombing?
>>
>> A warning message is far more elegant and useful since makes the user
>> to question himself if he is using the right tool for the job.
>
> Oh, so you want a product safety warning, like that found on a can of
> spray paint saying "POISON: Do not inhale contents"?

No, I prefer a tool that does not give incorrect information to the user.

> ~# ethtool lo
> Settings for lo:
> Link detected: yes
>
> ~# mii-tool lo
> SIOCGMIIPHY on 'lo' failed: Operation not supported
>
> There is no link for ethtool to detect, so it's output is BS. mii-tool
> at least gave a reasonably clear error in this case.

Why BS?

As long as your "lo" interface is up and present (it is, isn't it?)
ethtool is giving you its current status. No more no less. Nothing about
speed nor other settings that cannot be measured for that kind of
interface.

Look, your above example demonstrates my points:

1/ Unsupported interfaces (like "lo") are properly identified and that
information is presented to the user.

2/ If virtual (bond0, br0, tap0...) are "supported" at least for getting
information about their mii values, then it has to provide accurate
information, at least the one is displayed with "cat /proc/net/bonding/
bond0". Period.

> However...
>
> Pointing mii-tool or ethtool at a virtual NIC is just as stupid as
> pointing it at the loopback device as both are, once again, VIRTUAL
> devices, and have no physical parameters such as link speed or duplex,
> because they don't have a PHY. These tools are designed to query a PHY
> for link speed and duplex.

And so acts "ethtool" when the user specifies a virtual interface,
basically it says: "hey, you dumb... this is not the tool you need to
check the status of your bonded interfaces. Go away".

> Do you understand my point now? Only ignorant people would point
> mii-tool or ethtool at a _virtual_ NIC, just as only ignorant people
> would point these tools at the loopback device. Do you understand my
> point? Did I really need to be this blunt?

And what makes you think people is here to listen _your_ points? People
is here to _learn_ :-)

OP was asking about the (wrong) output he got when using "mii-tool" and
asked. You replied to him (sic) that "mii-tool was flawed" but didn't
point to another tool to get the job done (verifiying the status of the
bonded interfaces). I corroborated the information he was getting, in
fact, mii-tool showed an unrealistic value.

If you know a better tool for this then just tell and take our "poor
minds" from our big ignorance but let me to complain about something I
consider it should be warned or better yet, corrected.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2010.11.24.14.29.40@gmail.com">http://lists.debian.org/pan.2010.11.24.14.29.40@gmail.com
 
Old 11-25-2010, 01:13 AM
Stan Hoeppner
 
Default Bonded NIC's did not come up at boot?

Camaleón put forth on 11/24/2010 8:29 AM:

> If you know a better tool for this then just tell and take our "poor
> minds" from our big ignorance but let me to complain about something I
> consider it should be warned or better yet, corrected.

There is no "better" tool. There is no tool, period. You are
attempting to query a virtual device for an MII interface. Again, the
MII interface is a piece of SILICON HARDWARE on a NIC. You simply
cannot query a virtual NIC for hardware parameters.

Now, what I would recommend is that you file a feature request against
mii-tool and ethtool asking that for any query to a bonded virtual NIC
that the physical parameters of each physical NIC be output, along with
the bonding status. However, given how long bonding has been available,
if the devs were going to do this they'd probably have done it by now.

Maybe someone else wrote a tool with said functionality that superseded
mii-tool and ethtool. If so I am unaware of it. Time for you and the
OP to Google.

--
Stan



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CEDC63E.6090406@hardwarefreak.com">http://lists.debian.org/4CEDC63E.6090406@hardwarefreak.com
 
Old 11-25-2010, 05:49 PM
vr
 
Default Bonded NIC's did not come up at boot?

On Wed, 24 Nov 2010 20:13:18 -0600, Stan Hoeppner wrote:
> Camaleón put forth on 11/24/2010 8:29 AM:
>
>> If you know a better tool for this then just tell and take our "poor
>> minds" from our big ignorance but let me to complain about something I
>> consider it should be warned or better yet, corrected.
>
> There is no "better" tool. There is no tool, period. You are
> attempting to query a virtual device for an MII interface. Again, the
> MII interface is a piece of SILICON HARDWARE on a NIC. You simply
> cannot query a virtual NIC for hardware parameters.
>
> Now, what I would recommend is that you file a feature request against
> mii-tool and ethtool asking that for any query to a bonded virtual NIC
> that the physical parameters of each physical NIC be output, along with
> the bonding status. However, given how long bonding has been available,
> if the devs were going to do this they'd probably have done it by now.
>
> Maybe someone else wrote a tool with said functionality that superseded
> mii-tool and ethtool. If so I am unaware of it. Time for you and the
> OP to Google.
>
> --
> Stan

When I did Google, I see others expressing the same ignorance based on
the output of this tool. I appreciate the enlightenment and education
you have provided that this tool is not for virtual interfaces. I did
not realize that distinction based on the many blogs and other postings
peppered across the Internet that include mii-tool as part of setting
and troubleshooting interface functions, including bridges and
aggregates.

Having said that, my opinion is that a software tool, any software
tool, would properly renounce incorrect usage at run-time rather than
produce misleading output. I rely on how a tool responds, whether it be
to my ignorance or proficiency, in order to make as intelligent
decisions I am capable of, for what to do next. If that makes me
ignorant, well then there's nothing further I can say since this is my
opinion; for I am a dumb end-user and developers smarter than me
anticipate end-user stupidity and code for these discrepancies.

Going forward, I like your suggestion to contact the developers and/or
submit feature requests to resolve the situation. But I think the
reality is, as you pointed out, doing so is not likely to result in the
software changing. It appears to me that the tool has been static for
quite some time. I've also read at least one post stating ethtool has
replaced mii-tool but I don't know if that claim has validity.

Thanks to all who replied, this thread was helpful to me.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 93e43fd36994fae43b6852f27321c57c@192.168.0.66">htt p://lists.debian.org/93e43fd36994fae43b6852f27321c57c@192.168.0.66
 

Thread Tools




All times are GMT. The time now is 08:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org