ifconfig v2

[David Young]

I was just reminded what improvements can be made to ifconfig output
when I read this ifconfig output that appeared on current-users today:

wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
capabilities=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
capabilities=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
enabled=0
ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
ec_enabled=0
address: 00:26:2d:f3:c8:c7
media: Ethernet none (none)
inet 169.254.162.222 netmask 0xffff0000 broadcast 169.254.255.255
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

The ALL-CAPITALS text is really hard to read. Let's change that to
lower:

wm0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500
capabilities=7ff80<tso4,ip4csum_rx,ip4csum_tx,tcp4csum_rx>
capabilities=7ff80<tcp4csum_tx,udp4csum_rx,udp4csum_tx,tcp6csum_rx>
capabilities=7ff80<tcp6csum_tx,udp6csum_rx,udp6csum_tx,tso6>
enabled=0
ec_capabilities=7<vlan_mtu,vlan_hwtagging,jumbo_mtu>
ec_enabled=0
address: 00:26:2d:f3:c8:c7
media: Ethernet none (none)
inet 169.254.162.222 netmask 0xffff0000 broadcast 169.254.255.255
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

Hmm. Better, but not by much.

The capability keywords really should be printed in the same form as the
input is typed---i.e., with dashes instead of underscores---and dashes
are easier to type, besides. So I change the underscores to dashes. (A
nice property of ifconfig that I miss in other command-line environments
is that a lot of its output is directly reusable in ifconfig command
sentences.) The hex isn't of much use, so I omit it. I alphabetize the
capabilities so that if I know which capability I'm looking for, I can
find it without an exhaustive search. We can afford to use some more
whitespace, and it provides some texture that helps to find and identify
the keywords, so I add some:

wm0: flags < up, broadcast, running, simplex, multicast > mtu 1500
capabilities: ip4csum-rx, ip4csum-tx, tcp4csum-rx, tcp4csum-tx,
tcp6csum-rx tcp6csum-tx, tso4, tso6,
udp4csum-rx, udp4csum-tx, udp6csum-rx, udp6csum-tx
enabled: <none>
ether capabilities: vlan-mtu, vlan-hwtagging, jumbo-mtu
ether enabled: <none>
address: 00:26:2d:f3:c8:c7
media: Ethernet none (none)
inet 169.254.162.222 netmask 0xffff0000 broadcast 169.254.255.255
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

Most of the time, that is much more information than I need, so I'm
going to delete the capabilities and many of the flags from the default
display. I also delete the mtu, which isn't important to me unless it's
different from the default:

wm0: flags < up, running >
address: 00:26:2d:f3:c8:c7
media: Ethernet none (none)
inet 169.254.162.222 netmask 0xffff0000 broadcast 169.254.255.255
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

Finally, I get more use out of mask lengths than netmasks, and rarely is
the broadcast address useful to me:

wm0: flags < up, running >
address: 00:26:2d:f3:c8:c7
media: Ethernet none (none)
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

Finally, for the sake of consistency, let's put all of the addresses,
even the link-layer address, into <family> <address> form:

wm0: flags < up, running >
media: Ethernet none (none)
link 00:26:2d:f3:c8:c7
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

That is an efficient and consistent display. I estimate that it will
meet my information needs more than 95% of the time when I run 'ifconfig
wm0', and it will meet my needs more quickly than the status quo because
it is less cluttered and more compact.

If I need more information, I will ask for it with ifconfig -v wm0:

wm0: flags < up, broadcast, running, simplex, multicast > mtu 1500
capabilities: ip4csum-rx, ip4csum-tx, tcp4csum-rx, tcp4csum-tx,
tcp6csum-rx tcp6csum-tx, tso4, tso6,
udp4csum-rx, udp4csum-tx, udp6csum-rx, udp6csum-tx
enabled: <none>
ether capabilities: vlan-mtu, vlan-hwtagging, jumbo-mtu
ether enabled: <none>
media: Ethernet none (none)
link 00:26:2d:f3:c8:c7
inet 169.254.162.222 prefixlen 16 broadcast 169.254.255.255
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

Dave

[Mouse]

Post by David Young
I was just reminded what improvements can be made to ifconfig output
when I read this ifconfig output that appeared on current-users
today: [...]

There's one thing I notice about these purported improvements: they are
improvements aimed strictly at human interaction. If these are
adopted, I expect a lot of scripts to explode very badly - I know some
of mine would.

I would also expect a lot of sysadmins getting surprised and annoyed
upon discovering that their reflexes are broken by an "upgrade" -
basically, the human-layer version of the same thing - but that's a
risk for almost any change.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Hawkinson]

I'm not really a fan of these improvements ("Why does NetBSD have
to change an interface that I use on other platforms? It's just
going to be annoyingly different, even if it is somehow objectively

Post by David Young
Finally, I get more use out of mask lengths than netmasks, and rarely is
wm0: flags < up, running >
address: 00:26:2d:f3:c8:c7
media: Ethernet none (none)
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

If you want to do that, please use

inet 169.253.162.222/16

which is more standard notation (so-called "CIDR" notation) for IPv4.

Also, my recent experience is that while rarely is the broadcast
address useful, when it's wrong, you are not likely to query specifically
for it, and removing it means you're less likely to notice the
problem. So I would leave it in.

--***@mit.edu
John Hawkinson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by John Hawkinson

Why? What harm are [noncontiguous netmasks] doing that outweighs
(to you) breaking an occasionally useful (if little-used) facility
that's been there pretty much since day one?

No one can agree what they are supposed to mean.

Hm? I thought they meant what contiguous netmasks do:
"on-net" = "dst address & mask == local address & mask" (mutatis
mutandis for "local address" for things like routes). Who thinks they
mean anything else?

Post by John Hawkinson
No one knows how to use them.

There's no particular "how" to it; you pass them to ifconfig like any
other mask. "ifconfig le0 100.101.102.103 netmask 255.255.255.216".
Or whatever.

Post by John Hawkinson
They are undocumented.

Only in the sense that the documentation (mostly) does not explicitly
mention the possibility that the netmask be noncontiguous; you might as
well say that non-octet-boundary netmasks are undocumented. What
descriptions I can find offhand of the semantics of netmasks apply
equally well to contiguous and noncontiguous masks.

Post by John Hawkinson
They complicate things like the present case: showing a prefix length
instead of a netmask.

True.

Given that the code already exists, I'm not convinced removing it is
worth breaking the existing facility.

Not that NetBSD necessarily cares what I think, of course.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Hi,

Post by Mouse

Post by John Hawkinson

Why? What harm are [noncontiguous netmasks] doing that outweighs
(to you) breaking an occasionally useful (if little-used) facility
that's been there pretty much since day one?

No one can agree what they are supposed to mean.

"on-net" = "dst address & mask == local address & mask" (mutatis
mutandis for "local address" for things like routes). Who thinks they
mean anything else?

Uhm...

the interesting case is, what happens when you have two interfaces with
addresses/netmasks


1.2.0.1/255.255.0.255 (0xffff00ff)
1.2.1.0/255.255.15.240 (0xffff0ff0)

and you send a packet to 1.2.0.16 ?

What about

1.2.0.1/255.255.8.255 (0xffff08ff)
1.2.1.0/255.255.15.241 (0xffff0ff1) ?

(Yes, I must admit that I've seen one use of them where only one
interface was involved, and the situation on the router wasn't
ambiguous.)

Regards,
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Ignatios Souvatzis
the interesting case is, what happens when you have two interfaces
with addresses/netmasks
1.2.0.1/255.255.0.255 (0xffff00ff)
1.2.1.0/255.255.15.240 (0xffff0ff0)
and you send a packet to 1.2.0.16 ?

It's on-net for neither interface, so, unless there's another interface
that it is on-net for, the normal "not on an attached net" routing
mechanisms control what happens. (More interesting would be a packet
to 1.2.16.0, which may even have been what you meant.)

If the destination is on-net for fewer than two interfaces, there's no
ambiguity: either it goes out the interface it's on-net for, or there
is no such interface, in which case the routing table controls. If the
destination is on-net for multiple interfaces, I see two reasonable
approaches offhand (pick one, or send to all); the only respect in
which this is even slightly more difficult than the same case with
contiguous netmasks is that here, neither one is a subnet of the other.
I see no problem with making it formally undefined, with actual
behaviour a matter of quality-of-implementation and/or local policy.
That's what we've had in practice on any implementation supporting
noncontiguous netmasks anyway.

Post by Ignatios Souvatzis
What about
1.2.0.1/255.255.8.255 (0xffff08ff)
1.2.1.0/255.255.15.241 (0xffff0ff1) ?

With the same destination? Again, it's on-net for neither interface,
so there's no issue here as far as I can see - or, for 1.2.16.0, the
same remarks apply.

Post by Ignatios Souvatzis
(Yes, I must admit that I've seen one use of them where only one
interface was involved, and the situation on the router wasn't
ambiguous.)

My own case was similar; I ran a (small but) production network with a
netmask of 255.255.255.216 (0xffffffd8) for years. Except for the
router to the world, everything had only one interface, and, on that
router, the situation was entirely unambiguous. (I think the rest of
its containing network routed it as if it were two /29s, but that
detail is lost to the mists of memory.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

Post by Mouse

Post by John Hawkinson

Why? What harm are [noncontiguous netmasks] doing that outweighs
(to you) breaking an occasionally useful (if little-used) facility
that's been there pretty much since day one?

No one can agree what they are supposed to mean.

"on-net" = "dst address & mask == local address & mask" (mutatis
mutandis for "local address" for things like routes). Who thinks they
mean anything else?

How are the semantics when you have (partial) overlaps? With CIDR prefixes,
"most specific wins", but what is "most specific" when matching two
possibly matching routes with a 255.0.255.0 and 255.0.0.255 mask? This
is one of the problems I see.

The second drawback I can see is "data structures" - if you know netmasks
are contiguous, you can build more efficient route lookup structures for
that special case.

On the commercial side, Cisco stopped supporting non-continguous netmasks
about 10 years ago, mostly because they rewrote the FIB code (CEF) and the
new stuff was not written to handle it...

(I'm not a NetBSD kernel developer, I just read this list because there's
lots to learn - but my professional work is "routing in the Internet", so
these questions do show up occasionally)

gert

[Mouse]

Post by John Hawkinson

Post by David Young
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

If you want to do that, please use
inet 169.253.162.222/16
which is more standard notation (so-called "CIDR" notation) for IPv4.

Indeed, some programs accept it for v6 as well. But - unless you also
propose to break noncontiguous netmasks completely - you have to be
prepared to report the mask as other than a width if it's
noncontiguous.

Not that noncontiguous masks are common. I'm the only person I have
ever even heard of who ran one other than for testing. But, if they're
possible for userland to create even by mistake (which is not the same
as being possible for ifconfig to set), they really should be reported
when querying, for much the same reason you bring up with respect to
broadcast addresses below: if it goes wonky it needs to be mentioned.
Indeed, I had an unpleasant bug once which arose from certain bits
being ignored when printed but accepted, and used, when set wrong; if
they'd been reported it would have been much easier to find and thus
fix.

Not that that's a reason to not report it as a CIDR width if it _is_ a
contiguous mask, of course.

Post by John Hawkinson
Also, my recent experience is that while rarely is the broadcast
address useful, when it's wrong, you are not likely to query
specifically for it, and removing it means you're less likely to
notice the problem.

This is true. If you really want to delete it from the common case, I
would suggest reporting it by default iff it's not set to the default
for the address-and-mask in question.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Wed, 12 Jun 2013 09:07:43 -0400 (EDT)
From: Mouse <***@Rodents-Montreal.ORG>
Message-ID: <***@Chip.Rodents-Montreal.ORG>

| Why? What harm are they doing that outweighs (to you) breaking an
| occasionally useful (if little-used) facility that's been there pretty
| much since day one?

I am fairly sure that the IETF decided to abandon all support for those
things back when the router requirements rfcs were being written (mid 90's)
- they had their uses back when subnets were first invented, but lack of
support from some major vendors meant that in practice they couldn't be used
in a lot of sites, even where there was some minor benefit to be gained (which
is really just avoiding renumbering, as any even half sane use of non-contig
masks is just a 1:1 mapping from another numbering scheme using contig masks).

The real killer for them however is that no-one has even been able to
describe (let alone make work) what is supposed to happen when a network
has two different sets of non-contig masks applied - and since there is
no way to prevent that if non-contig masks are allowed at all, and as they
add no real value (just a minor convenience) - they were dropped.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matt Thomas]

Post by Mouse

Post by John Hawkinson

Post by David Young
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

If you want to do that, please use
inet 169.253.162.222/16
which is more standard notation (so-called "CIDR" notation) for IPv4.

Indeed, some programs accept it for v6 as well. But - unless you also
propose to break noncontiguous netmasks completely - you have to be
prepared to report the mask as other than a width if it's
noncontiguous.

Breaking noncontiguous netmasks sounds like a good idea to me.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Matt Thomas

[...] unless you also propose to break noncontiguous netmasks
completely [...]

Breaking noncontiguous netmasks sounds like a good idea to me.

Why? What harm are they doing that outweighs (to you) breaking an
occasionally useful (if little-used) facility that's been there pretty
much since day one?

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Robert Elz
I am fairly sure that the IETF decided to abandon all support for
those things back when the router requirements rfcs were being
written (mid 90's) - they had their uses back when subnets were first
invented, but lack of support from some major vendors meant that in
practice they couldn't be used in a lot of sites,

There was a time when lack of support from some major vendors meant
that subnet masks not on octet boudaries couldn't be used, too. I see
no reason to let half-assed vendor implementations deprecate a useful
feature.

Post by Robert Elz
The real killer for them however is that no-one has even been able to
describe (let alone make work) what is supposed to happen when a
network has two different sets of non-contig masks applied -

See my list message just now in response to Ignatios. "Local policy",
which may mean "whatever the implementation happens to give you".
That's what we've always had in practice anyway on implementations that
support them.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Wed, 12 Jun 2013 11:57:35 -0400 (EDT)
From: Mouse <***@Rodents-Montreal.ORG>
Message-ID: <***@Chip.Rodents-Montreal.ORG>

| There was a time when lack of support from some major vendors meant
| that subnet masks not on octet boudaries couldn't be used, too. I see
| no reason to let half-assed vendor implementations deprecate a useful
| feature.

I agree, but only when it is a useful feature. non-octet boundary subnets
are useful, non-contig are not. For example in another message you said ...

***@Rodents-Montreal.ORG said:
| My own case was similar; I ran a (small but) production network with a
| netmask of 255.255.255.216 (0xffffffd8) for years.

which means that you could do

for (addr = iterate over every assigned address (in that network)) {
newaddr = (addr & 0xffffffc7) |
(addr & 0x18) << 1 |
(addr & 0x20) >> 2;
}

and then use those new addresses, with a netmask of 255.255.255.224, right ?

Sure, by using the non-contig mask you avoid the renumbering (which is
why non-contig existed at all in the early versions of this - when the
benfits of subnets at all had to be sold) but that's all you gain right?
One renumber event and your non-contig would be gone forever, at little
cost, and with a gain of much simplicity.


| See my list message just now in response to Ignatios.

I did, though he asked (and thus you answered) the wrong question, instead
of ...

***@NetBSD.org said:
| the interesting case is, what happens when you have two interfaces with
| addresses/netmasks

| 1.2.0.1/255.255.0.255 (0xffff00ff)
| 1.2.1.0/255.255.15.240 (0xffff0ff0)

| and you send a packet to 1.2.0.16 ?

the real question is what happens when someone sends to 1.2.1.1 ?


| "Local policy",
| which may mean "whatever the implementation happens to give you".

And how do I exactly configure that to work in any way that anyone
can comprehend?

| That's what we've always had in practice anyway on implementations that
| support them.

Yes, in practice, no-one ever used anything except the simple cases, like
the one you described, which is no mor ethan a minor convenience. You're
not really using the true power of non-contig masks - which is a good thing,
as that power is all destructive.

Keeping this stuff just for the simple cases isn't worth the problems it
causes for people who don't understand the problems - if non-contig masks
had never been invented, no-one would be clamoring for them now, would they?

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Robert Elz

I ran a (small but) production network with a netmask of
255.255.255.216 (0xffffffd8) for years.

newaddr = (addr & 0xffffffc7) |
(addr & 0x18) << 1 |
(addr & 0x20) >> 2;
and then use those new addresses, with a netmask of 255.255.255.224, right ?

Only at the price of using addresses assigned to other people. (Well,
and, it'd be 240 in the last octet of the mask, not 224.)

If I could have synchronized the renumbering with the other users, and
administrator, of the relevant /27, yes, we could have done that. You
seem to think that would have been trivial, or at least easy; I doubt
it, and there's no way would it have been as easy as just using the
noncontiguous netmask.

Post by Robert Elz

See my list message just now in response to Ignatios.

I did, though he asked (and thus you answered) the wrong question,
instead of ...

1.2.0.1/255.255.0.255 (0xffff00ff)
1.2.1.0/255.255.15.240 (0xffff0ff0)
and you send a packet to 1.2.0.16 ?

the real question is what happens when someone sends to 1.2.1.1 ?

Or any of the 15 other addresses which are on-net for each interface.
(My mistake in my response to Ignatios; 1.2.16.0 is not one of them.)

Post by Robert Elz

"Local policy", which may mean "whatever the implementation happens
to give you".

And how do I exactly configure that to work in any way that anyone
can comprehend?

That depends on your implementation. Perhaps you don't; such
implementations are deficient and should wither and die.

Post by Robert Elz

That's what we've always had in practice anyway on implementations
that support them.

Yes, in practice, no-one ever used anything except the simple cases,
like the one you described,

Quite likely. Given the mailing lists I'm on and the number of times
I've mentioned on them that I'm the only person I've ever even heard of
who ran a noncontiguous netmask in production, I would expect to have
heard if anyone else did likewise.

Post by Robert Elz
which is no mor ethan a minor convenience.

Spoken like someone who's never had to renumber a production network
(which, given who you are, I find rather surprising). I'm in the
process of moving between cities, which involves moving between
connectivity providers, hence changing networks (I don't say
"renumbering" because I'm not just moving and keeping the rest of the
network design constant); I'm finding it somewhat surprising all the
places, some of them not under my direct control, that know IPs on the
old network. I've got the next-hop host out from the old house gateway
running with two of the old network's IPs aliased onto its lo0 because
of this effect (fortunately, I control that host - one of the benefits
of working for my upstream...).

Post by Robert Elz
You're not really using the true power of non-contig masks - which is
a good thing, as that power is all destructive.

"rm -rf" has a lot of power, (almost?) all destructive, too; is it a
bad thing to have it available? Yes, it's a bit of a strawman, but my
point is that, even admitting (arguendo) that the part after your comma
is correct, destructive power is not necessarily bad. And I remain
unconvinced of that antecedent. Just because NC netmasks can be used
in confusing and broken ways doesn't mean they have no nonconfusing and
nonbroken uses - I see this as a place to apply "Unix doesn't prevent
you from doing stupid things because that also prevents you from doing
clever things".

Post by Robert Elz
[I]f non-contig masks had never been invented, no-one would be
clamoring for them now, would they?

Well, no, but that's pretty much tautological; one can't really clamor
for something one doesn't have the concept of, can one? And if enough
people had the concept to clamor, that would constitute invention,
especially in a case like this where the thing putatively being
invented is fundamentally nonphysical.

But I actually think that, as long as they're spoken of as masks, the
possibility of noncontiguous masks is obvious, or at most only barely
latent; if nothing else, someone will make a coding mistake and
generate, say, 255.255.7.0 instead of 255.255.224.0 somewhere. To
avoid that, you'd really need to store them as widths instead of masks,
which is inconvenient enough to use that using real masks is an obvious
optimization. So I think your hypothetical is a bit like saying "if
nobody had invented zero, we wouldn't have had the US banking
meltdown": the antecedent requires/implies so many counterfactuals it's
impossible to take more than wild guesses at what the resulting world
would be like.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Wed, 12 Jun 2013 18:36:05 -0400 (EDT)
From: Mouse <***@Rodents-Montreal.ORG>
Message-ID: <***@Chip.Rodents-Montreal.ORG>

| Only at the price of using addresses assigned to other people.

Yes, the network needs a consistent addressing plan, which
should be decided, and implemented, by the network manager.

| (Well, and, it'd be 240 in the last octet of the mask, not 224.)

Arithmetic was never my strong point, clearly I miscounted the number of 1's...

| You seem to think that would have been trivial, or at least easy;

Not at all (and you come back to that point again later, I won't
duplicate the reply...) I know renumbering can be difficult, though in
a /24 it is generally tractable. As you suggest, I've been involved in
this more than once, and I know what's involved. The point was that it
is a one off (even if it takes a few intermediate steps to accomplish, and
gets spread out over some time) - on the other hand, using a non-contig
mask is a forever decision, it causes maintenance headaches for the rest
of eternity. Renumbering is certainly a more painful course to take
than the costs of dealing with a non-contig netmask right now, but when
you add up all the costs, over the years (people making mistakes with
config, difficulties spotting which subnet as it isn't obvious, ... lots
and lots of little things, over and over again - especially as personel
changes) and almost always the one off renumbering will turn out to be
the lesser evil.


| > the real question is what happens when someone sends to 1.2.1.1 ?
| Or any of the 15 other addresses which are on-net for each interface.

yes, of course. And I note that you didn't answer...

| That depends on your implementation.

Which implementation? There are likely to be several different ones.

There never was any thought seriously given to how this should work (back
when this was being discussed, we did try to come up with a definition for
how it should all work ... and failed)

Attempting to seriuously use stuff which is "however the implementation
decides to do it" is seriously a brain dead choice.

| But I actually think that, as long as they're spoken of as masks, the
| possibility of noncontiguous masks is obvious, or at most only barely
| latent; if nothing else, someone will make a coding mistake and
| generate, say, 255.255.7.0 instead of 255.255.224.0 somewhere.

Sure, so (as v6 does, or should be doing, as non-contig is definitely not
supported there) the config code should check for invalid values and
reject them. The test is easy.

| To avoid that, you'd really need to store them as widths instead of masks,

No - you could just have the config be a width, but then calculate the
mask and use that (which is how v6 gets done, though the calc is done in
userland so a broken program could do odd things, or attempt them, I have
never looked to see if the v6 kernel code checks the masks for sanity) or the
code can just check the mask when it is assigned, and reject bad ones.

| which is inconvenient enough to use that using real masks is an obvious
| optimization.

Internally, yes of course, but they don't need to be visible anywhere
outside the guts of the routing/forwarding code.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

You seem to think [renumbering] would have been trivial, or at least

As you suggest, I've been involved in this more than once, and I know
what's involved. The point was that it is a one off (even if it
takes a few intermediate steps to accomplish, and gets spread out
over some time) - on the other hand, using a non-contig mask is a
forever decision, it causes maintenance headaches for the rest of
eternity.

Odd, then, that it caused me no maintenance headaches at all. Or at
least none that I can remember now; it's been many years, but I think I
would have remembered anything I could reasonably ascribe to the
non-contiguous netmask. Even then I knew I was in relatively untested
territory doing that.

Post by Robert Elz
the real question is what happens when someone sends to 1.2.1.1 ?

Or any of the 15 other addresses which are on-net for each interface.

yes, of course. And I note that you didn't answer...

I didn't feel it needed any answer beyond what I wrote in my other list
post. I see two immediately obvious possibilities ("pick one" and
"send to all"); there are doubtless plenty of others. It's a matter
for local policy, even if that policy is to abidcate responsibility to
"whatever this implementation happens to do".

That depends on your implementation.

Which implementation? There are likely to be several different ones.

Which implementation? The one being run on the machine where that
packet send occurs, or which handles the routed packet in question, of
course. Which other one could possibly be relevant?

There never was any thought seriously given to how this should work
(back when this was being discussed, we did try to come up with a
definition for how it should all work ... and failed)

I don't see any need to nail it down. Let different implementations
experiment with support for different algorithms; maybe standardize if
one clear winner emerges, but, even if not, so what? I see no need to
have prescribed behaviour nailed down in all possible cases, especially
when there is no "rough consensus" to standardize on.

In fact, about the only thing that strikes me as stupider than that in
a case like this is forbidding experimentation. :-)

Attempting to seriuously use stuff which is "however the
implementation decides to do it" is seriously a brain dead choice.

Yes. On an implementation that doesn't take pains to do any particular
thing when faced with a configuration like that, it becomes "don't do
that, then". Unix has never had a shortage of brain-dead ways to
configure a system; I see no need to pay this one any particular mind.

But I actually think that, as long as they're spoken of as masks,
the possibility of noncontiguous masks is obvious, or at most only
barely latent; [...real masks vs widths...]

Internally, yes of course, but they don't need to be visible anywhere
outside the guts of the routing/forwarding code.

My point is that it is very hard to _not_ invent noncontiguous
netmasks, even if only within the kernel, even if only as unrealized
potential.

Indeed, given the generality of the routing table code, I suspect
noncontiguous v6 netmasks might well work if a way existed to set them.
(Well, work as well as v4 noncontiguous netmasks do, at least.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Matt Thomas

Post by Mouse

Post by John Hawkinson

Post by David Young
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

If you want to do that, please use
inet 169.253.162.222/16
which is more standard notation (so-called "CIDR" notation) for IPv4.

Indeed, some programs accept it for v6 as well. But - unless you also
propose to break noncontiguous netmasks completely - you have to be
prepared to report the mask as other than a width if it's
noncontiguous.

Breaking noncontiguous netmasks sounds like a good idea to me.

+1 It is the @##%@@!@#~! non-contiguous masks that caused a lot of unneeded
complexity in the networking code; code that was actually never used in real
life.

christos



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Hawkinson]

Post by Mouse
Why? What harm are they doing that outweighs (to you) breaking an
occasionally useful (if little-used) facility that's been there pretty
much since day one?

No one can agree what they are supposed to mean.
No one knows how to use them.
They are undocumented.
They complicate things like the present case: showing a prefix length
instead of a netmask.

--***@mit.edu
John Hawkinson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Erik Fair]

One thing I've long wished for is network interface status from NetBSD akin to what one sees from a Cisco router's "show interface" command, specifically including items like packets per second, bits per second, last input, last output, etc.

I note also that the "collisions" counter reported by netstat(1) is of marginal utility for modern FDX ethernet interfaces when attached to switches.

Whether these sorts of reports go in netstat or ifconfig is a matter for debate, though I'd argue that traffic flow stuff is more properly put into netstat.

Erik <***@netbsd.org>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

One thing I've long wished for is network interface status from NetBSD akin $

Perhaps. It would mean deciding what sort of timescale to do the
averaging over - do you happen to know what Cisco uses for that?

I note also that the "collisions" counter reported by netstat(1) is of margi$

This is true. But I don't think it would be a good idea to drop it for
interfaces not capable of half-duplex operation; (a) I'm not sure there
are enough such to matter and (b) I think a consistent output format is
more important than skipping a value on occasions when it does happen
to be meaningless. (There are also pseudo-interfaces which overload
the collisions value for other kinds of mild error; sl and tun are the
first two I noticed in a quick grep.)

Whether these sorts of reports go in netstat or ifconfig is a matter for deb$

I agree.

Personally, I don't think the traffic-rate stuff belongs in the kernel.
I'd prefer to see that implemented in netstat by sampling stats twice
with a measured delay and doing the arithmetic there. In aid of doing
this with very short delays, I'd say it would be good to make network
stats come back from the kernel with a timestamp attached. "Mechanism,
not policy."

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Erik Fair]

Post by Mouse
Personally, I don't think the traffic-rate stuff belongs in the kernel.
I'd prefer to see that implemented in netstat by sampling stats twice
with a measured delay and doing the arithmetic there. In aid of doing
this with very short delays, I'd say it would be good to make network
stats come back from the kernel with a timestamp attached. "Mechanism,
not policy."

Uh, "load average"?

An example "show interface" output from a Cisco route server:

Ethernet1/0 is up, line protocol is up
Hardware is AmdP2, address is 0050.73d0.cd1c (bia 0050.73d0.cd1c)
Description: "mdf001ffisxs0003.lax1 e4/24"
Internet address is 12.129.193.235/29
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 2 drops, 184 flushes
5 minute input rate 2000 bits/sec, 3 packets/sec
5 minute output rate 2000 bits/sec, 3 packets/sec
144626276 packets input, 3744307030 bytes, 0 no buffer
Received 100821 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
157988942 packets output, 624419973 bytes, 0 underruns
0 output errors, 108111 collisions, 0 interface resets
0 babbles, 0 late collision, 393433 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Cisco has used "five minutes" for their rate average for as long as I can remember. Akin to Unix's three load averages: 1 min, 5 min, 15 min, maintained by our kernel clock interrupt handler.

Given that Unix still doesn't distinguish between output queue limit drops and mbuf exhaustion drops (see PR kern/7285 http://gnats.netbsd.org/7285 ), reporting of I/F queue drops in the netstat -i display seems prudent, too, as you see above.

Erik <***@netbsd.org>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Erik Fair

Post by Mouse
Personally, I don't think the traffic-rate stuff belongs in the
kernel. I'd prefer to see that implemented in netstat by sampling
stats twice with a measured delay and doing the arithmetic there.
[...] "Mechanism, not policy."

Uh, "load average"?

Good point.

Given the decaying-average nature of the load average, it requires
enough state that it has to either be in the kernel or be in a
long-running daemon (or, perhaps, a frequently-started but very
short-running daemon which keeps state elsewhere, like a file). I'm
not sure which design I prefer (though admittedly the in-kernel one has
the advantage of already existing).

My impression is that the interface statistics you're looking for are
not decaying averages, so that concern doesn't apply. But even if
that's correct...

Post by Erik Fair
Ethernet1/0 is up, line protocol is up

[...]

Post by Erik Fair
5 minute input rate 2000 bits/sec, 3 packets/sec
5 minute output rate 2000 bits/sec, 3 packets/sec

...five minutes is long enough that it's not practical to do a "sample
twice with a delay" when the statistic is requested. However, it is
practical to do something like sample every minute and use historical
data; on the machines where I care about such things I sample every
five minutes (driven off cron) and save the data.

Is the Cisco data "the five minutes before the query time"? Or is it
"some recent five minute interval", such as the interval between the
most recent two times floor(uptime / five minutes) changed? Or some
mix, such as "the five minutes before the most recent time
floor(uptime / one second) changed"?

I'm not sure whether I think the benefits of doing it in the kernel
instead outweigh the costs. I suppose it depends at least in part on
what the costs are, which depends on things such as the answers to the
previous paragraph.

Also, Cisco's raison d'etre is such things; they can afford to dedicate
more resources (here mostly meaning RAM) to such things than a
general-purpose OS might want to. Or perhaps a kernel option could
control it, so that high-RAM machines can get detailed stats without
crippling low-RAM machines.

Or, modern NetBSD being what it is, perhaps it should just go in;
people using machines with less than a gig (or whatever) of spare RAM
can always just run something else.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Jun 14, 1:07pm, Mouse wrote:
}
} >> Personally, I don't think the traffic-rate stuff belongs in the
} >> kernel. I'd prefer to see that implemented in netstat by sampling
} >> stats twice with a measured delay and doing the arithmetic there.
} >> [...] "Mechanism, not policy."
} > Uh, "load average"?
}
} Good point.
}
} Given the decaying-average nature of the load average, it requires
} enough state that it has to either be in the kernel or be in a
} long-running daemon (or, perhaps, a frequently-started but very
} short-running daemon which keeps state elsewhere, like a file). I'm
} not sure which design I prefer (though admittedly the in-kernel one has
} the advantage of already existing).
}
} My impression is that the interface statistics you're looking for are
} not decaying averages, so that concern doesn't apply. But even if
} that's correct...
}
} > An example "show interface" output from a Cisco route server:
}
} > Ethernet1/0 is up, line protocol is up
} [...]
} > 5 minute input rate 2000 bits/sec, 3 packets/sec
} > 5 minute output rate 2000 bits/sec, 3 packets/sec
}
} ...five minutes is long enough that it's not practical to do a "sample
} twice with a delay" when the statistic is requested. However, it is
} practical to do something like sample every minute and use historical
} data; on the machines where I care about such things I sample every
} five minutes (driven off cron) and save the data.
}
} Is the Cisco data "the five minutes before the query time"? Or is it
} "some recent five minute interval", such as the interval between the
} most recent two times floor(uptime / five minutes) changed? Or some
} mix, such as "the five minutes before the most recent time
} floor(uptime / one second) changed"?
}
} I'm not sure whether I think the benefits of doing it in the kernel
} instead outweigh the costs. I suppose it depends at least in part on
} what the costs are, which depends on things such as the answers to the
} previous paragraph.
}
} Also, Cisco's raison d'etre is such things; they can afford to dedicate
} more resources (here mostly meaning RAM) to such things than a
} general-purpose OS might want to. Or perhaps a kernel option could
} control it, so that high-RAM machines can get detailed stats without
} crippling low-RAM machines.

Early Cisco routers were very much starved for RAM. Even
modern ones may not have a lot of RAM for administrative stuff
since it may be wanted for things like holding the OS (early routers
ran the OS from flash memory, modern ones keep compressed images
in flash memory), holding routing tables, etc.

}-- End of excerpt from Mouse

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by David Young
[...]
Finally, for the sake of consistency, let's put all of the addresses,
wm0: flags < up, running >
media: Ethernet none (none)
link 00:26:2d:f3:c8:c7
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1
That is an efficient and consistent display. I estimate that it will
meet my information needs more than 95% of the time when I run 'ifconfig
wm0', and it will meet my needs more quickly than the status quo because
it is less cluttered and more compact.
wm0: flags < up, broadcast, running, simplex, multicast > mtu 1500
capabilities: ip4csum-rx, ip4csum-tx, tcp4csum-rx, tcp4csum-tx,
tcp6csum-rx tcp6csum-tx, tso4, tso6,
udp4csum-rx, udp4csum-tx, udp6csum-rx, udp6csum-tx
enabled: <none>
ether capabilities: vlan-mtu, vlan-hwtagging, jumbo-mtu
ether enabled: <none>
media: Ethernet none (none)
link 00:26:2d:f3:c8:c7
inet 169.254.162.222 prefixlen 16 broadcast 169.254.255.255
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

I think capabilities (both supported and enabled) should still be in the
default output; it's an important information when you're configuring a
network interface.
Maybe some of them could be merged, e.g. when you have ip4csum-rx, ip4csum-tx
print ip4csum (ifconfig accepts this as input).

[David Young]

Post by Manuel Bouyer

Post by David Young
[...]
Finally, for the sake of consistency, let's put all of the addresses,
wm0: flags < up, running >
media: Ethernet none (none)
link 00:26:2d:f3:c8:c7
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1
That is an efficient and consistent display. I estimate that it will
meet my information needs more than 95% of the time when I run 'ifconfig
wm0', and it will meet my needs more quickly than the status quo because
it is less cluttered and more compact.
wm0: flags < up, broadcast, running, simplex, multicast > mtu 1500
capabilities: ip4csum-rx, ip4csum-tx, tcp4csum-rx, tcp4csum-tx,
tcp6csum-rx tcp6csum-tx, tso4, tso6,
udp4csum-rx, udp4csum-tx, udp6csum-rx, udp6csum-tx
enabled: <none>
ether capabilities: vlan-mtu, vlan-hwtagging, jumbo-mtu
ether enabled: <none>
media: Ethernet none (none)
link 00:26:2d:f3:c8:c7
inet 169.254.162.222 prefixlen 16 broadcast 169.254.255.255
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

I think capabilities (both supported and enabled) should still be in the
default output; it's an important information when you're configuring a
network interface.
Maybe some of them could be merged, e.g. when you have ip4csum-rx, ip4csum-tx
print ip4csum (ifconfig accepts this as input).

I like the idea of combining the keywords that way, but even with
compression, the capabilities and enables take at least 4 out of 9 lines
in a fairly normal default display:

wm0: flags < up, running >
capabilities: ip4csum, tcp4csum, tcp6csum, tso4, tso6,
udp4csum, udp6csum
enabled: <none>
ether capabilities: vlan-mtu, vlan-hwtagging, jumbo-mtu
ether enabled: <none>
media: Ethernet none (none)
link 00:26:2d:f3:c8:c7
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

I am pretty sure that most of the time, people are not looking for the
capabilities/enables in the ifconfig output.

I find it hard to ignore the larger issue, though, which is that those
capability flags are only useful insofar as the NetBSD networking stack
and drivers are distrusted or buggy and some masochists like to turn
knobs until they find a combo that works. :-) Ordinarily a driver should
enable the offload capabilities that are known to work reliably, and it
should not advertise the buggy ones.

Dave

[Mouse]

Post by David Young

Post by Manuel Bouyer
Maybe some of them could be merged, e.g. when you have ip4csum-rx,
ip4csum-tx print ip4csum (ifconfig accepts this as input).

I like the idea of combining the keywords that way, but even with
compression, the capabilities and enables take at least 4 out of 9
wm0: flags < up, running >
capabilities: ip4csum, tcp4csum, tcp6csum, tso4, tso6,
udp4csum, udp6csum
enabled: <none>
ether capabilities: vlan-mtu, vlan-hwtagging, jumbo-mtu
ether enabled: <none>

This could easily be compressed by doing something like printing the
capabilities with or without a -, the way ifconfig accepts them:

# ifconfig wm0 ip4csum -tcp4csum
# ifconfig wm0
capabilities: ip4csum -tcp4csum ...

Post by David Young
I am pretty sure that most of the time, people are not looking for
the capabilities/enables in the ifconfig output.

"Most of the time", people are looking for one particular piece of
information, and all the rest iis ignorable. The problem is, it's hard
to predict what that one piece is.

It's perhaps arguable that there should be one command to report
addresses, one command to report flags, one command to report
capabilities, one command to report media, etc - or perhaps different
flags to a single command.

It's just a question of where to draw the "this is too far in this
direction, that's too far in that direction" lines. I think the
current design is a not-horrible drawing of those lines; while some of
the lines could be pushed around a bit, I don't think it's a big deal.

Post by David Young
Ordinarily a driver should enable the offload capabilities that are
known to work reliably, and it should not advertise the buggy ones.

Yes and no. Since things like checksum offload - and even more so TCP
segmentation offload - break tcpdump (or equivalent)'s ability to see
the packets as they actually appear on the wire, I think it should be
possible to turn them off without having to compile a custom kernel
without them (in which case they end up permanently off, too).

Or do offload-capable drivers report on-the-wire packets back up to the
host after the offloaded operations have happened? That doesn't match
my own experience, but that experience is relatively minimal.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Swindells]

Post by David Young
I find it hard to ignore the larger issue, though, which is that those
capability flags are only useful insofar as the NetBSD networking stack
and drivers are distrusted or buggy and some masochists like to turn
knobs until they find a combo that works. :-) Ordinarily a driver should
enable the offload capabilities that are known to work reliably, and it
should not advertise the buggy ones.

The offload features can't be used if the device is linked to another
using bridge(4), there may be other combinations of pseudo-interfaces
that cause problems too.

I use the offload capabilities on most of my systems but I think they
should still default to off for now.

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by David Young
[...]
I like the idea of combining the keywords that way, but even with
compression, the capabilities and enables take at least 4 out of 9 lines
wm0: flags < up, running >
capabilities: ip4csum, tcp4csum, tcp6csum, tso4, tso6,
udp4csum, udp6csum
enabled: <none>
ether capabilities: vlan-mtu, vlan-hwtagging, jumbo-mtu
ether enabled: <none>
media: Ethernet none (none)
link 00:26:2d:f3:c8:c7
inet 169.254.162.222 prefixlen 16
inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1
I am pretty sure that most of the time, people are not looking for the
capabilities/enables in the ifconfig output.
I find it hard to ignore the larger issue, though, which is that those
capability flags are only useful insofar as the NetBSD networking stack
and drivers are distrusted or buggy and some masochists like to turn
knobs until they find a combo that works. :-) Ordinarily a driver should
enable the offload capabilities that are known to work reliably, and it
should not advertise the buggy ones.

it's more complicated than that; there are cases (e.g. mixing
offload-enabled an non-enabled interfaces in a bridge) breaks things
in subtle ways, and it's not the ethernet driver's fault.
So yes, I need to see them.

[Roy Marples]

Post by Manuel Bouyer
it's more complicated than that; there are cases (e.g. mixing
offload-enabled an non-enabled interfaces in a bridge) breaks things
in subtle ways, and it's not the ethernet driver's fault.
So yes, I need to see them.

If you know enough about creating bridges and enabling offload then you
ought to also know to see this information via the -v flag.
For example, the ip output from Linux

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 00:50:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 10.73.0.30/24 brd 10.73.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 xxxx:xxxx:31:2:250:8dff:xxxx:xxxx/64 scope global dynamic
valid_lft 2591887sec preferred_lft 604687sec
inet6 fe80::250:8dff:xxxx:xxxx/64 scope link
valid_lft forever preferred_lft forever

This suits my needs 99% of the time.
For that extra 1% I can use flags to get the extra information.

I'm fully in favour of a more compressed alternative default view to
ifconfig.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Roy Marples

Post by Manuel Bouyer
it's more complicated than that; there are cases (e.g. mixing
offload-enabled an non-enabled interfaces in a bridge) breaks things
in subtle ways, and it's not the ethernet driver's fault.
So yes, I need to see them.

If you know enough about creating bridges and enabling offload then
you ought to also know to see this information via the -v flag.

my comment was about enabling offload by default.
If it's enabled by default, then the default ifconfig view should show
if offload if there or not.

Post by Roy Marples
For example, the ip output from Linux

I wouldn't quote linux network tools as example myself, I've always found
them hard to use. How to find the information you're looking for is not
obvious.

[Mouse]

Post by Manuel Bouyer

Post by Roy Marples
For example, the ip output from Linux

I wouldn't quote linux network tools as example myself, I've always
found them hard to use. How to find the information you're looking
for is not obvious.

Indeed. If anyone knows how to get Linux to give the information
NetBSD's ifconfig reports on the "media:" line, please tell me!

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Mouse

Post by Manuel Bouyer

Post by Roy Marples
For example, the ip output from Linux

I wouldn't quote linux network tools as example myself, I've always
found them hard to use. How to find the information you're looking
for is not obvious.

Indeed. If anyone knows how to get Linux to give the information
NetBSD's ifconfig reports on the "media:" line, please tell me!

there is ethtool... But that's the lunix way of doing things. Like having
tail -F and tailf.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Manuel Bouyer
my comment was about enabling offload by default.
If it's enabled by default, then the default ifconfig view should show
if offload if there or not.

dyoung indicated once the example you gave where it's relevant is fixed
it's fine to be removed which I'm happy with

Post by Manuel Bouyer

Post by Roy Marples
For example, the ip output from Linux

I wouldn't quote linux network tools as example myself, I've always found
them hard to use. How to find the information you're looking for is not
obvious.

Please don't apply generic blanket statements like that, there are
plently of network tools on Linux which work on NetBSD.
Some linux tools are indeed hard to use and confusing, but I find the
same with some NetBSD tools also.

But back on topic, I do find the content of the default ip output gives
me the information I need 99% of the time without spamming stuff I'm
really not that interested in. And I look at network configs a lot due
to what I do in the open source world.

Things I care about

1) device name
2) media type
3) link status (include Network connected to if wireless)
4) addresses

Anything else is just extra admin detail which goes beyond the setup of
a singular interface

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Robert Swindells

Post by David Young
I find it hard to ignore the larger issue, though, which is that those
capability flags are only useful insofar as the NetBSD networking stack
and drivers are distrusted or buggy and some masochists like to turn
knobs until they find a combo that works. :-) Ordinarily a driver should
enable the offload capabilities that are known to work reliably, and it
should not advertise the buggy ones.

The offload features can't be used if the device is linked to another
using bridge(4), there may be other combinations of pseudo-interfaces
that cause problems too.

This is one of the bugs that needs to be fixed. I agree that the
default capability-flag settings should not change until the various
bugs are fixed.

Same goes for the bpf bugs that der Mouse mentions. Those are more
difficult to fix: how should TSO be treated by what is essentially a
diagnostic interface? Turning off segmentation offload while a bpf tap
is active will change the performance of the system you're observing.
Tapping synthetic segmented packets is misleading. You could tap
unsegmented packets, but how will an app distinguish those from real
packets?

Dave

[David Young]

Post by Manuel Bouyer

Post by David Young
I find it hard to ignore the larger issue, though, which is that those
capability flags are only useful insofar as the NetBSD networking stack
and drivers are distrusted or buggy and some masochists like to turn
knobs until they find a combo that works. :-) Ordinarily a driver should
enable the offload capabilities that are known to work reliably, and it
should not advertise the buggy ones.

it's more complicated than that; there are cases (e.g. mixing
offload-enabled an non-enabled interfaces in a bridge) breaks things
in subtle ways, and it's not the ethernet driver's fault.
So yes, I need to see them.

The bridge is one of those buggy parts of the networking stack that I
was talking about.

Dave

[David Young]

Post by Mouse
There's one thing I notice about these purported improvements: they are
improvements aimed strictly at human interaction. If these are
adopted, I expect a lot of scripts to explode very badly - I know some
of mine would.

I, too, have scripts that would explode. This is a sticking point
for changing a lot of things in a UNIX: the human interface and the
software interface are oftentimes the same, so improving one interface
may make the other worse. I'm interested in finding ways to separate
the interfaces.

(Perhaps one way of describing the problem is to say that there is no
separation of content and presentation in UNIX.)

The usual way to separate the interfaces is to check
isatty(STDOUT_FILENO) and to assume that if it's true, then there is a
person reading the output, and if it's false, then there is a program
reading the output. That doesn't get us very far. Even if a second
program reads the output, a person may ultimately read the output of
the second program. The second program may be a pager like 'more', for
example, or it may be an awk script that filters the output before the
user reads it.

Post by Mouse
I would also expect a lot of sysadmins getting surprised and annoyed
upon discovering that their reflexes are broken by an "upgrade" -
basically, the human-layer version of the same thing - but that's a
risk for almost any change.

I feel strongly that is important to avoid breaking users' reflexes,
however, I think that ifconfig can be changed in ways that make it more
useful while supporting either the old reflexes or the formation of
new ones. If the updated display is sufficient most of the time, then
existing reflexes won't have to change.

Dave

[Christos Zoulas]

Post by David Young
The usual way to separate the interfaces is to check
isatty(STDOUT_FILENO) and to assume that if it's true, then there is a
person reading the output, and if it's false, then there is a program
reading the output. That doesn't get us very far. Even if a second
program reads the output, a person may ultimately read the output of
the second program. The second program may be a pager like 'more', for
example, or it may be an awk script that filters the output before the
user reads it.

I dislike this; I prefer an explicit flag that changes the format of the
output. At least this makes debugging easier.

ifconfig -a | grep foo

printing different stuff than ifconfig -a is madness.


christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Christos Zoulas

Post by David Young
The usual way to separate the interfaces is to check
isatty(STDOUT_FILENO) and to assume that if it's true, then there is a
person reading the output, and if it's false, then there is a program
reading the output. That doesn't get us very far. Even if a second
program reads the output, a person may ultimately read the output of
the second program. The second program may be a pager like 'more', for
example, or it may be an awk script that filters the output before the
user reads it.

I dislike this; I prefer an explicit flag that changes the format of the
output. At least this makes debugging easier.

I dislike it, too. I also dislike that if I set flags that dress up the
ifconfig output with, say, changes in type emphasis or color, it will
not survive a pipeline. I would like to have a "late binding" of the
style to the content.

Dave

[Christoph Badura]

Post by David Young
I was just reminded what improvements can be made to ifconfig output

I gather there are two crucial points to your proposal:

- you want to display interface configuration information in a more
format more friendly to humans.
- you don't want to remember to have to use a special command line flag.

Others have pointed out that changing ifconfig's default output format
is problematic.

But there is an easy alternative. Produce the new format under a
different name. You could call it "ifinfo". It's even shorter to type.

--chris

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lars Schotte]

On Thu, 13 Jun 2013 21:00:02 +0200

Post by Christoph Badura

Post by David Young
I was just reminded what improvements can be made to ifconfig output

- you want to display interface configuration information in a more
format more friendly to humans.
- you don't want to remember to have to use a special command line flag.
Others have pointed out that changing ifconfig's default output format
is problematic.
But there is an easy alternative. Produce the new format under a
different name. You could call it "ifinfo". It's even shorter to type.
--chris

I do not know what you are arguing all the time about.
Some of you seen the GNU/Linux "ip" command? Maybe a good improvement of ifconfig
could look like a combination of the Linux "ip" and "iw" commands.

Hawk!

[Jean-Yves Migeon]

Post by Lars Schotte
On Thu, 13 Jun 2013 21:00:02 +0200

Post by David Young

Post by David Young
I was just reminded what improvements can be made to ifconfig

output

Post by David Young
when I read this ifconfig output that appeared on current-users

- you want to display interface configuration information in a more
format more friendly to humans.
- you don't want to remember to have to use a special command line flag.
Others have pointed out that changing ifconfig's default output format
is problematic.
But there is an easy alternative. Produce the new format under a
different name. You could call it "ifinfo". It's even shorter to type.
--chris

I do not know what you are arguing all the time about.
Some of you seen the GNU/Linux "ip" command? Maybe a good improvement of ifconfig
could look like a combination of the Linux "ip" and "iw" commands.

I don't think so. Today "ip" is used for just about anything and not
just "IP configuration", but also device options and SR-IOV virtual
functions. Beware of one size fits all commands, they tend to become
ugly as time goes by. IMHO "ip" is a mess nowadays.

In the case of "ip addr show", the output is indeed synthetic and
convenient, but "ip" syntax is just cumbersome. Please, no, don't turn
ifconfig into "ip+iw". I would rather favor an explicit flag to give a
more useful output, or have a _careful_ look at what others OS did. Just
look at the horrid mess created by "ip" when you configure an IP alias,
and then try to manipulate it through ifconfig. And that's one example
among many (route/source routing, virtual functions, ...)

[Lars Schotte]

On Fri, 14 Jun 2013 15:41:29 +0200

Post by Jean-Yves Migeon
I don't think so. Today "ip" is used for just about anything and not
just "IP configuration", but also device options and SR-IOV virtual
functions. Beware of one size fits all commands, they tend to become
ugly as time goes by. IMHO "ip" is a mess nowadays.

that not something that could not be changed. how you style the output can be a
different topic and of course, can be done better than Linux's IP command.

Post by Jean-Yves Migeon
In the case of "ip addr show", the output is indeed synthetic and
convenient, but "ip" syntax is just cumbersome. Please, no, don't turn
ifconfig into "ip+iw". I would rather favor an explicit flag to give a
more useful output, or have a _careful_ look at what others OS did. Just
look at the horrid mess created by "ip" when you configure an IP alias,
and then try to manipulate it through ifconfig. And that's one example
among many (route/source routing, virtual functions, ...)

??? LOL ... i do not see a problem there as well. of course, on Linux only IP should
be used and ifconfig on Linux is unusable in some cases, but that's not an argument
against it.

so i agree on that point that it should be styled better than linux does, but on the
other topics i do not see a difference. ifconfig on BSD's are mess nowadays too.

or are you wanting to sell me that FreeBSD's way to configure wlans is cool?

[Jean-Yves Migeon]

Post by Lars Schotte

Post by Jean-Yves Migeon
In the case of "ip addr show", the output is indeed synthetic and
convenient, but "ip" syntax is just cumbersome. Please, no, don't turn
ifconfig into "ip+iw". I would rather favor an explicit flag to give a
more useful output, or have a _careful_ look at what others OS did. Just
look at the horrid mess created by "ip" when you configure an IP alias,
and then try to manipulate it through ifconfig. And that's one example
among many (route/source routing, virtual functions, ...)

??? LOL ... i do not see a problem there as well.

1 - Configure an IP alias for an interface with ip:

ip addr add <IP> dev <whatever>

Then just do an ifconfig -a, look for it, and unset it.

Now do the same, this time by creating the alias via ifconfig eth:<N>
and use ip(8). See? Two ways of doing the same thing, however you do not
end up with the same result.

2 - Use ip rules, create a dedicated routing table, then netstat -r.

Post by Lars Schotte
so i agree on that point that it should be styled better than linux does, but on the
other topics i do not see a difference. ifconfig on BSD's are mess nowadays too.
or are you wanting to sell me that FreeBSD's way to configure wlans is cool?

I am not selling anything, ergonomy is a matter of personal taste.
However I consider that a command that starts with a 3 page-long BNF
definition is just silly, and I understand why many stayed with the old,
broken ifconfig/route.

[Lars Schotte]

I like BNF !

Like with PF's ;-)

On Sat, 15 Jun 2013 08:45:50 +0200

Post by Jean-Yves Migeon
I am not selling anything, ergonomy is a matter of personal taste.
However I consider that a command that starts with a 3 page-long BNF
definition is just silly, and I understand why many stayed with the old,
broken ifconfig/route.

[Darren Reed]

Post by Christoph Badura

Post by David Young
I was just reminded what improvements can be made to ifconfig output

- you want to display interface configuration information in a more
format more friendly to humans.
- you don't want to remember to have to use a special command line flag.
Others have pointed out that changing ifconfig's default output format
is problematic.
But there is an easy alternative. Produce the new format under a
different name. You could call it "ifinfo". It's even shorter to type.

This is the only sensible approach.

If someone wants to "fix" the administrative front end for changing things then wrap that up in a new command too :) or fold a new administrative interface and new query interface into a new command.

Trying to make safe changes to ifconfig's output format/content is fraught. Lets just not do it.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jean-Yves Migeon]

Post by Lars Schotte
I like BNF !
Like with PF's ;-)
On Sat, 15 Jun 2013 08:45:50 +0200

Post by Jean-Yves Migeon
I am not selling anything, ergonomy is a matter of personal taste.
However I consider that a command that starts with a 3 page-long BNF
definition is just silly, and I understand why many stayed with the old,
broken ifconfig/route.

Fair enough :)