Retiring dhclient

[Joerg Sonnenberger]

Hi all,
I would like to retire dhclient before netbsd-6. I don't think it
provides a functional advantage over dhcpcd. The reverse is not true.
I want to collect TODO items for this to happen, mostly in the
documentation section to deal with the changes.

The first important item that comes to mind is the retirement of
/sbin/dhclient-script. If a user has custom modifications to this file,
they need to be ported to /libexec/dhcpcd-hooks or
/etc/dhcpcd.{enter,exit}hook. This should normally be either just copy and
paste or disabling of the normal hooks. More importantly, a number of
custom modifications can be done from the command line directly now.
This is a case of documentation, IMO.

The second important item is that dhcpcd by default depends on working
link state management in the driver. Sadly, quite a few of our older
drivers don't do it properly. Typical issue is calling if_reset from
if_ioctl e.g. to update multicast filters. This is a two fold issue:
(1) Fixing kernel drivers to not do this.
(2) Documenting the work arounds (aka crippling dhcpcd with -K)
Building a list of drivers affected would be a good start.

What other items are missing?

Joerg

--
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 Joerg Sonnenberger
Hi all,
I would like to retire dhclient before netbsd-6. I don't think it
provides a functional advantage over dhcpcd. The reverse is not true.
I want to collect TODO items for this to happen, mostly in the
documentation section to deal with the changes.

*snip snip*

Post by Joerg Sonnenberger
The second important item is that dhcpcd by default depends on working
link state management in the driver. Sadly, quite a few of our older
drivers don't do it properly. Typical issue is calling if_reset from
(1) Fixing kernel drivers to not do this.
(2) Documenting the work arounds (aka crippling dhcpcd with -K)
Building a list of drivers affected would be a good start.

I do not recognize the typical based on your description. Please
explain in more detail.

Post by Joerg Sonnenberger
What other items are missing?

dhclient-exit-hooks compatibility.

Dave

[Joerg Sonnenberger]

Post by David Young

Post by Joerg Sonnenberger
Hi all,
I would like to retire dhclient before netbsd-6. I don't think it
provides a functional advantage over dhcpcd. The reverse is not true.
I want to collect TODO items for this to happen, mostly in the
documentation section to deal with the changes.

*snip snip*

Post by Joerg Sonnenberger
The second important item is that dhcpcd by default depends on working
link state management in the driver. Sadly, quite a few of our older
drivers don't do it properly. Typical issue is calling if_reset from
(1) Fixing kernel drivers to not do this.
(2) Documenting the work arounds (aka crippling dhcpcd with -K)
Building a list of drivers affected would be a good start.

I do not recognize the typical based on your description. Please
explain in more detail.

Consider a driver using mii(4). Calling reset from if_ioctl normally
does a reset of the PHY. This in turn results in a link down message to
userland, so dhcpcd will renegociate the lease. Typical circumstances
for calling reset are changes to the multicast filter and
entering/leaving promisc mode. For some PHYs it might really be
necessary to tell the generic layer to ignore link state changes for a
bit, but the common use cases shouldn't require anything like that.

Post by David Young

Post by Joerg Sonnenberger
What other items are missing?

dhclient-exit-hooks compatibility.

Can you be more specific? The variables are essentially the same,
equivalent functionality is available (see the section in my original
mail that you've skipped).

Joerg

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

[Ted Lemon]

Post by Joerg Sonnenberger
I would like to retire dhclient before netbsd-6. I don't think it
provides a functional advantage over dhcpcd. The reverse is not true.
I want to collect TODO items for this to happen, mostly in the
documentation section to deal with the changes.

Huh. I too think that dhclient is desperately lacking in functionality, but I'm curious to know why you think dhcpcd is a big improvement. IMHO there actually _isn't_ a good open source network configuration program, and the fact that 'dhcpcd' has the acronym 'dhcp' in it tends to lead me to assume that it's no exception.

Having said that, I would certainly like to see this problem solved, and if you really think that dhcpcd is part of the path to solving it, I guess it sounds like a good idea.


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

[Hubert Feyrer]

Asking out of sheer ignorance: does either dhclient or dhcpcd support
DHCPv6?


- Hubert

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

[Ted Lemon]

Asking out of sheer ignorance: does either dhclient or dhcpcd support DHCPv6?

The current ISC dhclient does, but I don't know if anyone's imported it.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Takahiro Kambe]

In message <B42FD035-8CAC-4743-AEF1-***@fugue.com>
on Wed, 16 Nov 2011 06:59:06 +0800,

Post by Ted Lemon

Asking out of sheer ignorance: does either dhclient or dhcpcd support DHCPv6?

The current ISC dhclient does, but I don't know if anyone's imported it.

Currnet is 3.0.3 and mellon@ is written as Maintainer in
src/doc/3RDPARTY. I wish latest release is in tree.

[Christos Zoulas]

Post by Ted Lemon

Asking out of sheer ignorance: does either dhclient or dhcpcd support DHCPv6?

The current ISC dhclient does, but I don't know if anyone's imported it.

It cannot be imported cleanly because of the mess of libisc and friends.
(BIND vs non BIND ifdefs). Whoever made that mess should clean it. This
cannot be maintained sanely.

christos


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

[John Nemeth]

On Mar 3, 1:17pm, Christos Zoulas wrote:
} In article <B42FD035-8CAC-4743-AEF1-***@fugue.com>,
} Ted Lemon <***@fugue.com> wrote:
} >On Nov 16, 2011, at 6:34 AM, Hubert Feyrer <***@feyrer.de> wrote:
} >> Asking out of sheer ignorance: does either dhclient or dhcpcd support DHCPv6?
} >
} >The current ISC dhclient does, but I don't know if anyone's imported it.
}
} It cannot be imported cleanly because of the mess of libisc and friends.
} (BIND vs non BIND ifdefs). Whoever made that mess should clean it. This
} cannot be maintained sanely.

Does this mess affect dhcpd and dhcrelay? If so, then the
maintenance issues are there whether dhclient is kept or not.

}-- End of excerpt from Christos Zoulas

--
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 John Nemeth
} >> Asking out of sheer ignorance: does either dhclient or dhcpcd support DHCPv6?
} >
} >The current ISC dhclient does, but I don't know if anyone's imported it.
}
} It cannot be imported cleanly because of the mess of libisc and friends.
} (BIND vs non BIND ifdefs). Whoever made that mess should clean it. This
} cannot be maintained sanely.
Does this mess affect dhcpd and dhcrelay? If so, then the
maintenance issues are there whether dhclient is kept or not.

Yes, they all use the same libraries. The current sources of dhcp come with
tar.gz version of bind, unpack it and build it.

christos


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

[Ted Lemon]

Post by Takahiro Kambe
src/doc/3RDPARTY. I wish latest release is in tree.

Yeah, that was a long time ago. It seems as if importing the latest version would be good, although I actually can't offer much support for the ISC code—I haven't worked on it in nearly a decade.


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

[Joerg Sonnenberger]

Post by Ted Lemon

Post by Joerg Sonnenberger
I would like to retire dhclient before netbsd-6. I don't think it
provides a functional advantage over dhcpcd. The reverse is not true.
I want to collect TODO items for this to happen, mostly in the
documentation section to deal with the changes.

Huh. I too think that dhclient is desperately lacking in functionality,
but I'm curious to know why you think dhcpcd is a big improvement.
IMHO there actually _isn't_ a good open source network configuration
program, and the fact that 'dhcpcd' has the acronym 'dhcp' in it tends
to lead me to assume that it's no exception.

With minimal configuration, I could get a working roaming setup on my
old laptop. E.g. based on availability, it switched between Ethernet,
Wireless and 3G.

At least for DHCPv4, I am not aware of any functionality in the older
dhclient version in base or in newer DHCP3 that dhcpcd is missing.
Please correct me if I am wrong. On the positive side, it is
significantly smaller than the version of dhclient we have in base.

Post by Ted Lemon
Having said that, I would certainly like to see this problem solved,
and if you really think that dhcpcd is part of the path to solving it,
I guess it sounds like a good idea.

Let me give back the question to you -- what problems do you see and
would like to get solved better?

Joerg

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

[Joerg Sonnenberger]

Post by Hubert Feyrer
Asking out of sheer ignorance: does either dhclient or dhcpcd
support DHCPv6?

No for dhclient in base. Not yet for dhcpcd. Roy is working on it, some
parts work, more is needed.

Joerg

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

[John Nemeth]

On Apr 7, 11:45am, Joerg Sonnenberger wrote:
}
} I would like to retire dhclient before netbsd-6. I don't think it

Why? I have a moderately complex setup and know how to use it. I
don't know dhcpcd. Obviously I could learn it, but that's not the
point. If you remove dhclient, we will still have ISC's dhcpd and
dhcrelay. This means removing dhclient won't provide a significant
savings in build time, code size, or maintenance. What is the
advantage to TNF that would offset the disadvantage to me and all the
other users of dhclient. In other words, what is the advantage to TNF
of forcing a change on a bunch of users? If you can't demonstrate a
significant advantage, then I would suggest that you shouldn't do
this. Stuff should only be removed when keeping it causes significant
pain. I don't see that as the case here.

} provides a functional advantage over dhcpcd. The reverse is not true.

Don't care. dhclient does what I need it to do.

}-- End of excerpt from Joerg Sonnenberger

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

[Ted Lemon]

Post by John Nemeth
} provides a functional advantage over dhcpcd. The reverse is not true.
Don't care. dhclient does what I need it to do.

FTR, if there is significant interest in keeping dhclient around, but agreement that its feature set is too limited, it's actually possible I could get buy-in from my management to spend a week or two making it better, including porting in dhcpv6 support from the ISC tree. I didn't propose this in my initial response to Joerg because I actually don't know the capabilities of dhcpcd, but it's definitely an option.


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

[Joerg Sonnenberger]

Post by Ted Lemon

Post by John Nemeth
} provides a functional advantage over dhcpcd. The reverse is not true.
Don't care. dhclient does what I need it to do.

FTR, if there is significant interest in keeping dhclient around, but
agreement that its feature set is too limited, it's actually possible
I could get buy-in from my management to spend a week or two making it
better, including porting in dhcpv6 support from the ISC tree.
I didn't propose this in my initial response to Joerg because
I actually don't know the capabilities of dhcpcd, but it's definitely
an option.

A short summary is
http://roy.marples.name/projects/dhcpcd/wiki/DhcpcdFeatures

Updating ISC DHCPD and friends would provide at least some value in
keeping dhclient, since ATM there are no alternatives for DHCPv6.

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

[Joerg Sonnenberger]

If dhcpcd really is better than dhclient, I could probably hack ini
DHCPv6 support pretty easily.

I think it is significantly better than the 3.x code we have in base.
I don't know what the state of multi-interface support in dhclient4 is
to know whether it can compare. Support for IPv4 LL is definitely nice
to have, but a bit smaller.

DHCPv6 support is a sore point in NetBSD for now and fixing that one way
or the other would be appreciated. Getting the support for the server is
pretty much a no brainer. For the client, it raises a few questions
about which data set to pick when both DHCP and DHCPv6 are available for
an interface and have a non-empty symmetric difference. Another item is
how to deal with partial support in the presence of multiple interfaces.
Consider having both IPv4 and IPv6 available via WLAN and only IPv4 via
Ethernet -- do you still want to enable IPv6 routing? What is the status
in this area for dhclient?

What about RA handling? Does dhclient depend on the kernel / rtsol for
that?

One thing that spooks me about dhcpcd though is that it supports dbus,
which I've always found to be basically unuseable. But I haven't
tried it in years. Do you consider this a valuable feature of dhcpcd
for NetBSD, or just a bullet point?

It exists for the sake of network manager like applications. It is also
a separate program, so no nasty tentacles in the main code :)
Personally, I don't use it.

Joerg

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

[Ted Lemon]

Post by Joerg Sonnenberger
DHCPv6 support is a sore point in NetBSD for now and fixing that one way
or the other would be appreciated. Getting the support for the server is
pretty much a no brainer.

Except for the libisc problem Christos described.

Post by Joerg Sonnenberger
For the client, it raises a few questions
about which data set to pick when both DHCP and DHCPv6 are available for
an interface and have a non-empty symmetric difference. Another item is
how to deal with partial support in the presence of multiple interfaces.
Consider having both IPv4 and IPv6 available via WLAN and only IPv4 via
Ethernet -- do you still want to enable IPv6 routing?

This is impossible to resolve if we treat configuration information as per-host. There's work going on in the IETF to consider configuration information per-provisioning-domain, where IPv4 and IPv6 would be considered separate provisioning domains, and results from different interfaces (e.g., wired and wireless) would also be considered separate provisioning domains.

I think this is the only way to successfully address this issue, but of course it requires substantial changes to the way programs that connect to the network behave. IMHO the work needs to be done in userland, not in the kernel; I can explain at length if there is interet.

Post by Joerg Sonnenberger
What is the status in this area for dhclient?

AFAIK, not implemented.

Post by Joerg Sonnenberger
What about RA handling? Does dhclient depend on the kernel / rtsol for
that?

It definitely does not do ND itself.

Post by Joerg Sonnenberger
It exists for the sake of network manager like applications. It is also
a separate program, so no nasty tentacles in the main code :)
Personally, I don't use it.

Yup, that's pretty much my experience of it too. :)


--
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, 16 Nov 2011 10:21:54 +0800
From: Ted Lemon <***@fugue.com>
Message-ID: <844EEC57-686D-4B04-8162-***@fugue.com>

| This is impossible to resolve if we treat configuration information
| as per-host.

No, it isn't - it's impossible to resolve if the aim is to specify
a method by which it must, or should, be done (which is all the IETF
can do, which is why anything dealing with this, or related, issues
is such a quagmire there), but it's actually reasonably easy when you
get to ignore the network and just consider one host, in one evnironment,
and how that host should configure its multiple interfaces and network
stacks (depending upon which are working at the time).

That's the situation here, and NetBSD could easily (well relatively)
specify, and implement, policies that can be configured by the users
to handle all the weird cases, and yet which default to a rational enough
model that most users never need to go near the config to have everything
work well enough (perhaps not optimally in some sense, but well enough
that things at least all work).

It's only when you try and handle the hard cases (like a host multi-homed
to two different providers) and expect to have the network instruct it
somehow how it should configure itself that things get truly hard to
manage. If the host gets to choose for itself, it can cope.

kre


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

[Ted Lemon]

Post by Robert Elz
It's only when you try and handle the hard cases (like a host multi-homed
to two different providers) and expect to have the network instruct it
somehow how it should configure itself that things get truly hard to
manage. If the host gets to choose for itself, it can cope.

Whatever.

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

[Ted Lemon]

Post by Ted Lemon
Whatever.

To expand on this, Robert, my point is that it's all very well and good to be a cowboy and come up with a solution that works well on the networks that you think are good networks. But to come up with a solution that will work on networks that exist in practice but are not the sorts of networks you think should exist in practice is harder. Of course it's always easier to provide a solution to a restricted problem set.

In practice, multiple interface environments where each network is connected to a separate administrative domain are common, not uncommon. If you have an iPhone, that's a device that is connected in this way. My Android phone is currently connected to my hotel network and a Taiwanese 3G provider. Neither provider is qualified to advise my device on how it should operate on the network, so trying to merge configuration information from both services is a fool's errand. Indeed, my Android phone routinely fails to connect to my mail server once per day, even though it has a perfectly valid 3G connection, because the WiFi connection reverts to the captive portal and stops allowing transit through it to my mail server.

Now, you can argue that no NetBSD device will ever be connected in this way, but I will believe you only as long as you promise never to install a cellular data modem in the USB port of your laptop.


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

[Robert Elz]

First, I know the general problem is hard, and if the aim is to
specify how it should be solved, in general, then that's a very
difficult task. Further, providing that solution is (aside from
nothing) the only thing that the IETF can really do, so the task
there truly is difficult.

My point is that in NetBSD we don't have to solve that problem
in general. We need (well, it would be nice if we could)
provide a solution that works for most people who use NetBSD,
most of the time, and which can be configured (manually, if we
can't come up with a better way for now) to handle the other cases.

It isn't that a NetBSD device "will never be connected this way",
but that most are not, and in most cases where they are (this year
anyway) the user probably knows enough to configure the problem away.

I assume that you have your iphone working in its hotel/3g environment,
and if not, I'd guess it is because the iphone doesn't provide enough
config options, not because you are unable to work out what you want it
to do ...

For us, right now, that's enough - the number of NetBSD users who need
to manually config is going to be so small, that any who aren't able
to work it out themselves, can just ask, and someone who does understand
(whatever mechanism we create) will be able to assist.

If that ever gets to be a burden (too many users asking) we can figure
out what the common element is, as in practice (if not in theory) there
will always be one - the providers just aren't that imaginative, they
all copy from each other - and provide a canned config (or even automate if
it is reasonable) to solve that particular problem.

If the IETF ever produces a general solution, then we can implement it.
In the meantime, the experience gained by projects like NetBSD (and all
the others of course) might just be useful in providing some guidance as
to what works, what doesn't, and what missing info should be provided to
ease the task.

Now you can consider this "being a cowboy" if you like - I don't, I think
it's just a prudent and sane use of resources - we (NetBSD) don't need to
solve the general problem right now, so there's no need to attempt to do
that. But that doesn't mean do nothing just because there isn't yet
a general solution available. Nor do we need to limit ourselves to
"good networks" whatever they are - just to be able to work in the common
evvironments that our users (the project's users) actually find themselves
in most frequently, today (or next year) - what is needed after that, and
what is needed in less common cases, can be handled later.

kre


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

[Ted Lemon]

The problem, Robert, is that I think only in your mind is this a simple problem for the average case. I think this is a problem users of any modern device will run into; in the sense that NetBSD only runs on ancient iron, maybe you are right. But I have to admit that that's not how I think of NetBSD, whether it's true or not.

My phone currently just breaks in the hotel environment, and even though it's broken on me twice, I still tend to forget why it's breaking, and hence how to fix it, because it's so stupid and counterintuitive.

This is precisely what a good network configuration agent is supposed to do for you, and I do not agree with you that this is a problem that need not be solved. I also don't agree with you that the problem is prohibitively difficult. IMHO it's pretty easy: you just try a reasonable collection of starting permutations and use the one that connects and authenticates successfully, discarding the rest. This is what Google Chrome does by default today for the dual-stack scenario; extending this to the multiple interface scenario is trivial.


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

[Ted Lemon]

Post by Joerg Sonnenberger
A short summary is
http://roy.marples.name/projects/dhcpcd/wiki/DhcpcdFeatures

That's very helpful—thanks!

Post by Joerg Sonnenberger
Updating ISC DHCPD and friends would provide at least some value in
keeping dhclient, since ATM there are no alternatives for DHCPv6.

There is dibbler. I don't have any experience with it, though, so I don't know if it's nicer or less nice.

If dhcpcd really is better than dhclient, I could probably hack in DHCPv6 support pretty easily. One thing that spooks me about dhcpcd though is that it supports dbus, which I've always found to be basically unuseable. But I haven't tried it in years. Do you consider this a valuable feature of dhcpcd for NetBSD, or just a bullet point?


--
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, 16 Nov 2011 16:04:32 +0800
From: Ted Lemon <***@fugue.com>
Message-ID: <A12A1A32-ED6A-4FF1-A211-***@fugue.com>

| The problem, Robert, is that I think only in your mind is this a
| simple problem for the average case.

No, not simple, or it would be done already and we wouldn't be
discussing it, but tractable.

| This is precisely what a good network configuration agent is supposed
| to do for you,

Yes, but lacking that, which your phone apparently doesn't have, and which
NetBSD currently doesn't have, wouldn't a better alternative to nothing be
a sane config that you could set once, when you did work it out, and would
then just do the right thing every later time that you connect?

That's the kind of "first step" config agent that I'd hope to see.

| and I do not agree with you that this is a problem that need not be solved.

If that is what I said, I don't agree with me either - but I don't think
I said that. What I said was that it is not a problem that the NetBSD
project needs to solve today (in general).

| I also don't agree with you that the problem is prohibitively difficult.

Well... (aside from what is "prohibitively difficult" to one engineer
is just plain hard to another, and child's play to someone else...)

| IMHO it's pretty easy: you just try a reasonable collection of starting
| permutations

Which come from? And reasonable according to whom?

| and use the one that connects and authenticates successfully,

And here's the rub - connects and authenticates to what exactly? To
your hotel network? No thanks, that's not useful to me, I want
internet connectivity, plus intra-org connectivity, but how do we test
that either of those works? Is being able to connect to google.com
the test? Not for me, I don't much care, being able to connect to
netbsd.org would be more useful (for me, but perhaps not others), and
of course, the root nameservers (for me). On the other hand, the vast
majority of the world (even of netbsd users) don't care about netbsd.org
(most of the time) or root nameservers, ever. Working out "it is working"
is a truly hard thing to do - especially when you consider all the possible
failure cases, some of which still indicate that the local connectivity is
good, and correctly configured, and something else is broken, out of our
control, and others don't.

| discarding the rest. This is what Google Chrome does by default
| today for the dual-stack scenario;

Dealing with just dual stack is comparatively trivial.

| extending this to the multiple interface scenario is trivial.

No, it isn't - consider a trivial case when (say) at the IETF,
on that hotel network (which I presume is WiFi, and so generally
to be preferred over the more expensive, and slower, 3G) decides
to implement an IPv6 google.com of their own - you connect to it
you get answers, just not the ones you hoped. Given that people
there are clever, they even have nameservers sending out apparently
correct dnssec secured IPv6 addresses for google.com - but with
access to the root servers filtered out, so you can't actually get
the certificates to verify.

Doing all this, truly properly, really is hard.

On the other hand, the method you described isn't too much away from
what I'd expect as a first, or second, step to a solution - an algorithm
that works for most people, most of the time, and some config that you
can set to tell it when it failed, so it doesn't repeat the same
mistake the next time - and leave the harder part of automatically
determining failure, and then automatically responding, for a future
revision, once we better understand how to do that. ("failure"
here is algorithm failure, not just connection failure.)

kre


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

[Ted Lemon]

Post by Robert Elz
Yes, but lacking that, which your phone apparently doesn't have, and which
NetBSD currently doesn't have, wouldn't a better alternative to nothing be
a sane config that you could set once, when you did work it out, and would
then just do the right thing every later time that you connect?

Sure, if your machine is bolted to a rack in a data center. There is no way to hard code a network configuration on a mobile device that will work in any meaningful sense. The reason Android doesn't work is that the network configuration, for the same network, no less, keeps shifting.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Post by Robert Elz
No, it isn't - consider a trivial case when (say) at the IETF,
on that hotel network (which I presume is WiFi, and so generally
to be preferred over the more expensive, and slower, 3G) decides
to implement an IPv6 google.com of their own - you connect to it
you get answers, just not the ones you hoped.

That's why IMHO you have to authenticate (by which I mean the remote server, not authenticate yourself to the network). The scenario you are worried about is perfectly possible in the dual stack case. If you think one interface is more expensive than another, you can handicap the race.
--
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 Joerg Sonnenberger

If dhcpcd really is better than dhclient, I could probably hack ini
DHCPv6 support pretty easily.

I think it is significantly better than the 3.x code we have in base.
I don't know what the state of multi-interface support in dhclient4 is
to know whether it can compare. Support for IPv4 LL is definitely nice
to have, but a bit smaller.
DHCPv6 support is a sore point in NetBSD for now and fixing that one way
or the other would be appreciated. Getting the support for the server is
pretty much a no brainer. For the client, it raises a few questions
about which data set to pick when both DHCP and DHCPv6 are available for
an interface and have a non-empty symmetric difference. Another item is
how to deal with partial support in the presence of multiple interfaces.
Consider having both IPv4 and IPv6 available via WLAN and only IPv4 via
Ethernet -- do you still want to enable IPv6 routing?

This is one of those cases where the DHCP client should use a hook to
decide. You definitely don't want to hard-code the policy.

(I like dhcpcd a lot, really, but sometimes it has hard-coded a policy
where there was already precedent for different people setting different
policies.)

Dave

[Roy Marples]

Post by David Young
This is one of those cases where the DHCP client should use a hook to
decide. You definitely don't want to hard-code the policy.
(I like dhcpcd a lot, really, but sometimes it has hard-coded a policy
where there was already precedent for different people setting different
policies.)

Can you give examples of these hard coded policies?
I'd to take the challenge of providing a dhcpcd.conf entry to make it
work how you like, or patch dhcpcd to make it so :)

Thanks

Roy


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

[roy]

If dhcpcd really is better than dhclient, I could probably hack in
DHCPv6 support pretty easily.

That would be appreciated as my development time over the past year has
been a trickle at best whilst I can provide fixes, adding full blown
DHCPv6 and IPv6 ND is a bigger task than I thought. Mainly due to my
lack of understanding of writing IPv6 code, constructing addresses from
prefixes and then trying to merge that into existing dhcpcd to keep code
size down.

If anyone wants to do it, it needs to work dual stack with the exiting
DHCPv4, IPv4LL code and follow the same routing logic and priority.
Although I do keep dhcpcd in NetBSD fairly up-to-date it's always best

One thing that spooks me about dhcpcd
though is that it supports dbus, which I've always found to be
basically unuseable. But I haven't tried it in years. Do you
consider this a valuable feature of dhcpcd for NetBSD, or just a
bullet point?

My goal at the start was to provide a GTK+ systray icon to display how
dhcpcd was configured on my attached networks.
When I started writing this someone said "Why not supply a dbus
interface so GNOME apps can communicate easily".
Sounded like a good idea at the time, along with removing the
abomination called NetworkManager.

Since then I've come to kind of loath dbus as using the raw C library
as I did, rather than the glib library (I hate needless dependencies) is
very painful.
On the other hand, dhcpcd-gtk uses it quite nicely as a very functional
(imo ofc ;) sys tray applet that allows to configure very basic ipv4
information and choose your wireless network.

Long story short, as others have pointed out, it's just a bullet point
and has no place in NetBSD base system.

Thanks

Roy

--
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, 16 Nov 2011 06:21:43 +0800
From: Ted Lemon <***@fugue.com>
Message-ID: <8C912E97-E5B6-4DBB-A668-***@fugue.com>

| I too think that dhclient is desperately lacking in functionality,
| but I'm curious to know why you think dhcpcd is a big improvement.

As Joerg said in a later reply (or replies), the big difference isn't in the
DHCP side of things, but in interaction with the rest of the system, dhclient
is simply pathetic (in all ways) in dealing with multi-interface
systems (even its logic in how it treats a config file that lists interfaces
makes no sense at all.)

This isn't something I ever complained about, as I never thought that
dhclient was really intended to be a system configuration tool, it just
kind of grew into that role in the absence of any other candidates.
I always understood that dhclient's main objective was to be able to
test dhcpd, and for that, it needed to be able to test everything in
dhcpd - and for that, I still think it does better than dhcpcd, it is
more configurable, and allows more functionality - however, when you
get beyond testing and to actual real life uses, none of that stuff
really matters, and what dhcpcd offers in terms of communicating with
the dhcp server is entirely adequate, and it is definitely much better
at dealing with multi-interface systems (even more when the actual
interfaces that work vary from use to use.)

That said, I still use dhclient personally on my laptop, though when I
configure for others, I use dhcpcd instead - like John Nemeth, I have
a moderately complex dhclient config, and inertia keeps me from switching,
and I see no particularly good reason for removing it (assuming that the
rest of ISC dhcp remains - though really dhclient is the only part of that
that demands presence in base, the server in pkgsrc would be sufficient,
as it is rarely required, for IPv4 a client is always required).

If v6 support is added (made available in NetBSD) then there'd be even
more need to retain it.

I certainly agree with using dhcpcd (for IPv4) as the default dhcp client,
but I am not sure I believe that removing dhclient (alone anyway) is
of sufficient benefit to anything to justify the (minor, it would still
be in pkgsrc I assume) pain its removal will cause those users who have
been using it for years and don't want to change.

kre


--
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 Elz
That said, I still use dhclient personally on my laptop, though when I
configure for others, I use dhcpcd instead - like John Nemeth, I have
a moderately complex dhclient config, and inertia keeps me from switching,
and I see no particularly good reason for removing it (assuming that the
rest of ISC dhcp remains - though really dhclient is the only part of that
that demands presence in base, the server in pkgsrc would be sufficient,
as it is rarely required, for IPv4 a client is always required).

I think that in many respects, dhcpcd is a huge improvement over
dhclient, and I'm not opposed to replacing dhclient with dhcpcd if old
configurations, especially carefully-crafted dhclient-exit-hooks, can be
kept working.

I think that unless we can do hi-fi dhclient emulation with dhcpcd in
6.0, we should not remove dhclient in 6.0 but wait until 7.0, instead.
I think that it is customary for NetBSD to loudly deprecate a feature in
one major release, actually remove it in the next. I would hope that we
can also replace dhcrelay and dhcpd with smaller alternatives in 7.0, or
else put them on a diet.

Dave

[Manuel Bouyer]

Post by David Young
[...]
I think that unless we can do hi-fi dhclient emulation with dhcpcd in
6.0, we should not remove dhclient in 6.0 but wait until 7.0, instead.

Seconded.

[Thor Lancelot Simon]

Post by John Nemeth
}
} I would like to retire dhclient before netbsd-6. I don't think it
Why? I have a moderately complex setup and know how to use it. I
don't know dhcpcd. Obviously I could learn it, but that's not the

It's duplicative, the system should not grow without bound, and we should
not ship two tools for the same thing for longer than we have to.

In practice, dhcpcd provides the same set of hooks that dhclient does,
with the same names as the dhclient hook scripts, so it is very, very
nearly a drop-in replacement that simply works better.

This was one of my original objections to importing dhcpcd -- that it
needed to provide dhclient compatible hook scripts -- and it was fixed
immediately by the dhcpcd maintainer and has been fixed for a long time.

The claim that is isn't exactly dhclient so we shouldn't remove dhclient
would have worked, for me, for the 5.0 release. But we've now had a
whole release cycle with both so there has been more than adequate
warning. And the bloat should not persist. Yes, other things surely
bloat the system more. No, that is not an excuse to ship two daemons
that do exactly the same thing, and to keep deferring removal of one
of them far into the future.

I would very strongly urge core to remove dhclient for 6.0.

Thor

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

[matthew green]

unless we actually advertised removing dhclient already, i don't think
doing so for netbsd-6 is a good thing. there has been no warning.

i recommend leaving it until after the branch, and advertising that
it will not be present in netbsd-7.


.mrg.

--
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 matthew green
unless we actually advertised removing dhclient already, i don't think
doing so for netbsd-6 is a good thing. there has been no warning.
i recommend leaving it until after the branch, and advertising that
it will not be present in netbsd-7.

Remove it after the branch. Or if my evil plan pans out and we get dhcp4
support in the tree...

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 Joerg Sonnenberger
The second important item is that dhcpcd by default depends on working
link state management in the driver. Sadly, quite a few of our older
drivers don't do it properly. Typical issue is calling if_reset from
(1) Fixing kernel drivers to not do this.
(2) Documenting the work arounds (aka crippling dhcpcd with -K)
Building a list of drivers affected would be a good start.
What other items are missing?

I don't know if you covered it, but currently dhcpcd by default requests
an MTU from the DHCP server and if given and valid, sets it.
A lot of drivers reset their link on MTU change. Infact, about 90% of
the dhcpcd bug reports I get is about this very behaviour. So much so
I'm sorely tempted to stop dhcpcd from doing this by default. Opinions
on what dhcpcd should do by default are welcome :)

See PR #42367 as a good example of this.

As the developer for dhcpcd I don't feel it's my place to argue for the
removal of dhclient even though I'm a NetBSD developer as well. But I'm
happy to debate the merits of dhcpcd vs dhclient, discuss improvements
to dhcpcd and time permitting even write some code!

Thanks

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 Roy Marples

Post by David Young
This is one of those cases where the DHCP client should use a hook to
decide. You definitely don't want to hard-code the policy.
(I like dhcpcd a lot, really, but sometimes it has hard-coded a policy
where there was already precedent for different people setting different
policies.)

Can you give examples of these hard coded policies?
I'd to take the challenge of providing a dhcpcd.conf entry to make it
work how you like, or patch dhcpcd to make it so :)
I don't know if you covered it, but currently dhcpcd by default requests
an MTU from the DHCP server and if given and valid, sets it.

:-)

Dave

[Roy Marples]

Post by Roy Marples

Post by David Young
This is one of those cases where the DHCP client should use a hook to
decide. You definitely don't want to hard-code the policy.
(I like dhcpcd a lot, really, but sometimes it has hard-coded a policy
where there was already precedent for different people setting different
policies.)

Can you give examples of these hard coded policies?
I'd to take the challenge of providing a dhcpcd.conf entry to make it
work how you like, or patch dhcpcd to make it so :)
I don't know if you covered it, but currently dhcpcd by default requests
an MTU from the DHCP server and if given and valid, sets it.

:-)

All too easy! In dhcpcd.conf that ships you can find this entry

# Respect the network MTU.
option interface_mtu

Simply comment it out or remove it.

You could also set
nooption interface_mtu

Which would strip it from the DHCP message if the server forces it on
you as well.

It's harcoded in the same why that a US keyboard is by default. Although
you could argue that a typical end user should neither know nor care
about MTU. I am loath to change it, as a lot of other OSes ship with it
default to request and set.

Thanks

Roy

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

[David Brownlee]

Post by Roy Marples

Post by Roy Marples

Post by David Young
This is one of those cases where the DHCP client should use a hook to
decide.  You definitely don't want to hard-code the policy.
(I like dhcpcd a lot, really, but sometimes it has hard-coded a policy
where there was already precedent for different people setting different
policies.)

Can you give examples of these hard coded policies?
I'd to take the challenge of providing a dhcpcd.conf entry to make it
work how you like, or patch dhcpcd to make it so :)
I don't know if you covered it, but currently dhcpcd by default requests
an MTU from the DHCP server and if given and valid, sets it.

:-)

All too easy! In dhcpcd.conf that ships you can find this entry
# Respect the network MTU.
option interface_mtu
Simply comment it out or remove it.
You could also set
nooption interface_mtu
Which would strip it from the DHCP message if the server forces it on you as well.
It's harcoded in the same why that a US keyboard is by default. Although you could argue that a
typical end user should neither know nor care about MTU. I am loath to change it, as a lot of other
OSes ship with it default to request and set.

Maybe there could be an interface characteristic that dhcpcd (or other
userland tools) could query, so it could default it on for known good
interfaces only.

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

[Thor Lancelot Simon]

Post by Roy Marples

Post by Joerg Sonnenberger
The second important item is that dhcpcd by default depends on working
link state management in the driver. Sadly, quite a few of our older
drivers don't do it properly. Typical issue is calling if_reset from
(1) Fixing kernel drivers to not do this.
(2) Documenting the work arounds (aka crippling dhcpcd with -K)
Building a list of drivers affected would be a good start.
What other items are missing?

I don't know if you covered it, but currently dhcpcd by default requests
an MTU from the DHCP server and if given and valid, sets it.
A lot of drivers reset their link on MTU change. Infact, about 90% of
the dhcpcd bug reports I get is about this very behaviour.

Perhaps it would be better to set the MTU only if it actually differs from the
MTU already configured on the adapter?

Thor

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

[Thor Lancelot Simon]

[Ow, ow, ow! Please limit your line length to 80 characters when posting to
the NetBSD mailing lists!]

Thor, get real. Presentation != representation. If your MUA doesn't get that, you need to update it, because you're experiencing a _lot_ of pain, not just from me.

Now, that's pretty rude. Basic netiquette says keep line lengths under 80.
If your user agent wants reflowable text, there's a perfectly good way for it
to achieve that with other compatible user agents while not emitting lines
longer than 80: it can mark the text as format=flowed.

If your MUA can't or won't mark text it wants reflowed on the other end as
format=flowed, please use an appropriate filter to make up for its
shortcomings before posting to public lists.

Thor

--
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 Thor Lancelot Simon
Perhaps it would be better to set the MTU only if it actually differs from the
MTU already configured on the adapter?

That is an option, but I doubt it would help much work as why would you
send an MTU otpion of 1500?

Thanks

Roy

--
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 Thor Lancelot Simon
Perhaps it would be better to set the MTU only if it actually differs from the
MTU already configured on the adapter?

A lot of those configuration parameters are weird to me. Why should the
DHCP server have a better idea of what the MTU should be than the client
does? These were put in the spec for completeness, and I suppose it's
not out of the question that they might be useful, but it seems unlikely
that they would be useful by default.

I did actually use it myself at one time, as I had to use an MTU of 1492
to get my Linux router to work for my home network. Interestingly, one
of my hardware applicances (by memory my Wii) did set MTU via DHCP but
not allow it manually.

Now I have replaced that with a NetBSD router I can happly use 1500 MTU
for my IPv4 network so my personal need has gone.

Weird? Maybe, but this is the only reason I can think of why the default
is a good thing.

Now, while I know a fair chunk about DHCPv4, I know little about MTU and
it's application in terms of who knows best (client vs server) or what
the best default would be for NetBSD.

Thanks

Roy


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

[Joerg Sonnenberger]

Post by Thor Lancelot Simon
Perhaps it would be better to set the MTU only if it actually differs from the
MTU already configured on the adapter?

A lot of those configuration parameters are weird to me. Why should
the DHCP server have a better idea of what the MTU should be than the
client does?

Where should an arbitrary client know the best MTU for the network from?
The DHCP server is (supposedly) managed by network administrators, which
should know better. Path MTU discovery can deal e.g. with PPPoE
overhead, but the more reliable choice really is often to just cap the
MTU at 1492. Noone forces the server to announce one, after all.

Joerg

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

[Thor Lancelot Simon]

Post by Thor Lancelot Simon
Perhaps it would be better to set the MTU only if it actually differs from the
MTU already configured on the adapter?

A lot of those configuration parameters are weird to me. Why should the DHCP server have a better idea of what the MTU should be than the client does? These were put in the spec for completeness, and I suppose it's not out of the question that they might be useful, but it seems unlikely that they would be useful by default.

[Ow, ow, ow! Please limit your line length to 80 chracters when posting to
the NetBSD mailing lists!]

Consider the case in which you want to take machines out of the vendor's
shipping box, do no firmware-level configuration, have them autoboot
from the network, and run, with no client-side configuration at all.

If you are not running a 1500 MTU, how else *do* you tell them what MTU
to use? Generally, if you want to avoid doing any network configuration on
the client side because you are using DHCP, why should you have to set the MTU
by hand?

So I think it's reasonable for the server to send the MTU, but -- since
for some MTU values and some adapter types the client *has to* reset its
PHY or even part of its MAC to do an MTU change -- the DHCP client
software should be careful not to try to change the value on the adapter
if the new value received from the server is the same as what was already
configured.


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

[Joerg Sonnenberger]

Post by Thor Lancelot Simon
So I think it's reasonable for the server to send the MTU, but -- since
for some MTU values and some adapter types the client *has to* reset its
PHY or even part of its MAC to do an MTU change -- the DHCP client
software should be careful not to try to change the value on the adapter
if the new value received from the server is the same as what was already
configured.

BTW, this is exactly what I meant in my initial mail. I think we want to
add support for suppressing this link state messages to the net/if.c
logic for informing userland. I.e. if the link goes down now and comes
back in the next $X seconds, consider it normal behavior of the PHY
reset and not as unplugged cable.

Joerg

--
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 Joerg Sonnenberger

Post by Thor Lancelot Simon
So I think it's reasonable for the server to send the MTU, but -- since
for some MTU values and some adapter types the client *has to* reset its
PHY or even part of its MAC to do an MTU change -- the DHCP client
software should be careful not to try to change the value on the adapter
if the new value received from the server is the same as what was already
configured.

BTW, this is exactly what I meant in my initial mail. I think we want to
add support for suppressing this link state messages to the net/if.c
logic for informing userland. I.e. if the link goes down now and comes
back in the next $X seconds, consider it normal behavior of the PHY
reset and not as unplugged cable.

I disagree. Consider the case where a laptop goes into standyby when
connected. The correct behaviour on resume is to send notify userland
that link is down and then link is back up only if one is currently
connected. This could be a very small timewindow, but is the correct
behaviour so the client can re-negoiate the correct information if it
has changed network in the meantime.

Better behaviour would be to mark these faulty drivers as not having
working link detection as my marking it down then up during a simple MTU
change is clearly broken in my eyes. Basically they should not set
IFM_AVALID.

Thanks

Roy

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

[Joerg Sonnenberger]

Post by Roy Marples

Post by Joerg Sonnenberger

Post by Thor Lancelot Simon
So I think it's reasonable for the server to send the MTU, but -- since
for some MTU values and some adapter types the client *has to* reset its
PHY or even part of its MAC to do an MTU change -- the DHCP client
software should be careful not to try to change the value on the adapter
if the new value received from the server is the same as what was already
configured.

BTW, this is exactly what I meant in my initial mail. I think we want to
add support for suppressing this link state messages to the net/if.c
logic for informing userland. I.e. if the link goes down now and comes
back in the next $X seconds, consider it normal behavior of the PHY
reset and not as unplugged cable.

I disagree. Consider the case where a laptop goes into standyby when
connected. The correct behaviour on resume is to send notify
userland that link is down and then link is back up only if one is
currently connected. This could be a very small timewindow, but is
the correct behaviour so the client can re-negoiate the correct
information if it has changed network in the meantime.

This isn't what I am talking about. Suspend/resume involves an explicit
IF_DOWN/IF_UP cycle, so it doesn't matter here. I am talking about
ifconfig $nic $option with option not including down. This should IMHO
not trigger a link state message, even if e.g. setting promisc mode,
changing MTU or multicast filters require a PHY reset.

Joerg

--
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 Joerg Sonnenberger
This isn't what I am talking about. Suspend/resume involves an explicit
IF_DOWN/IF_UP cycle, so it doesn't matter here. I am talking about
ifconfig $nic $option with option not including down. This should IMHO
not trigger a link state message, even if e.g. setting promisc mode,
changing MTU or multicast filters require a PHY reset.

Ah good.

So we can expect `ifconfig re0 mtu 1492; ifconfig re0 down; ifconfig re0
up` to change the MTU without affecting link state but the latter two
calls straight afterwards do.

Thanks

Roy

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

[Joerg Sonnenberger]

Post by Roy Marples

Post by Joerg Sonnenberger
This isn't what I am talking about. Suspend/resume involves an explicit
IF_DOWN/IF_UP cycle, so it doesn't matter here. I am talking about
ifconfig $nic $option with option not including down. This should IMHO
not trigger a link state message, even if e.g. setting promisc mode,
changing MTU or multicast filters require a PHY reset.

Ah good.
So we can expect `ifconfig re0 mtu 1492; ifconfig re0 down; ifconfig
re0 up` to change the MTU without affecting link state but the
latter two calls straight afterwards do.

Yes. It does mean that there is a window in which unplugging the cable
and plugging it back won't be noticed, but it is my believe that is more
acceptable than the current status quo.

Does anyone know how long PHY resets for affected cards take?

Joerg

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

[Nick Reilly]

Post by Joerg Sonnenberger
Yes. It does mean that there is a window in which unplugging the cable
and plugging it back won't be noticed, but it is my believe that is more
acceptable than the current status quo.
Does anyone know how long PHY resets for affected cards take?

Just a nit: The PHY shouldn't be resetting, MTU is at the MAC layer in
Ethernet.

I disagree with not showing the link down for two reasons.
1) 10GigE has a Reconciliation Sublayer. If we go down (Local Fault)
then the far end will go to Remote Fault and go down as well. This
causes all kinds of confusion when one end is saying the other went down
and the faulty end claims it didn't go down at all.

2) Various routing protocols that are link state driven - these should
get notified of every link transition. In this case the link is unlikely
to be active in routing but this change would affect all link down glitches.

Now I do agree that the last think you want is to end up going around in
circles with the DHCP response driving a new MTU which resets the MAC
and that triggers a new DHCP request. I believe that should be handled
at the application level i.e. in dhcpd with a link down tolerance. It's
the same idea but done in each application rather than the stack itself.

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

[Joerg Sonnenberger]

Post by Nick Reilly
Now I do agree that the last think you want is to end up going
around in circles with the DHCP response driving a new MTU which
resets the MAC and that triggers a new DHCP request. I believe that
should be handled at the application level i.e. in dhcpd with a link
down tolerance. It's the same idea but done in each application
rather than the stack itself.

The application can't distinguish broken hardware from real user
interaction. If you are about this (e.g. to use it for link driven
protocols), use a non-broken NIC.

Joerg

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

[David Laight]

Post by Joerg Sonnenberger
Does anyone know how long PHY resets for affected cards take?

Link negotiation can take a while ....

I'm surprised that reducing the mtu can ever require a MAC reset.
Especially since you want to be able to set a per-path mtu.
Maybe the MACs that can do IP segmentation for large TCP??

I also suspect it would be useful to set different values for
the rx and tx mtu. I know I've seen systems that reject 1500
byte packets when the mtu is set shorter (to avoid an external
mtu blackhole).

Or rather tell IP the max mtu to send, rather then telling the
MAC driver.

David

[Thor Lancelot Simon]

Post by Nick Reilly
Now I do agree that the last think you want is to end up going
around in circles with the DHCP response driving a new MTU which
resets the MAC and that triggers a new DHCP request. I believe that
should be handled at the application level i.e. in dhcpd with a link
down tolerance. It's the same idea but done in each application
rather than the stack itself.

Yes, there should effectively be an anti-flap timer in the application
code. However, in this case, the best thing is to *not change the MTU, thus
potentially triggering a link status change* (which would be genuine and
should not be suppressed by the kernel -- as Nick notes, there are times
when you really must know if the peer may have seen a link event) unless
the "change" actually *is* a change.

[Joerg Sonnenberger]

Post by Thor Lancelot Simon
Yes, there should effectively be an anti-flap timer in the application
code.

That doesn't help and can be actively harmful. E.g. 802.11 can be quite
fast in connection to a different AP, which has the same visible impact.

Joerg

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

[Dennis Ferguson]

Post by David Laight

Post by Joerg Sonnenberger
Does anyone know how long PHY resets for affected cards take?

Link negotiation can take a while ....
I'm surprised that reducing the mtu can ever require a MAC reset.
Especially since you want to be able to set a per-path mtu.
Maybe the MACs that can do IP segmentation for large TCP??
I also suspect it would be useful to set different values for
the rx and tx mtu. I know I've seen systems that reject 1500
byte packets when the mtu is set shorter (to avoid an external
mtu blackhole).
Or rather tell IP the max mtu to send, rather then telling the
MAC driver.

I was just going to ask this too. The IP MTU you receive
via DHCP or PPP is just an IP MTU, it should have no effect on
my-very-own-network-protocol which may be sharing the same
interface hardware, so I don't want an IP MTU change to somehow
have the effect of reducing the size of frames the interface
hardware is willing to send and receive. More than this,
if it isn't otherwise inconvenient or somehow costly I would
prefer that all my network hardware interfaces be set to
receive the largest frames they are physically capable of
receiving for a number of reasons including, but not limited
to, the "be conservative in what you send, be liberal in what
you accept" dictum, no matter what size the protocols are
configured to send. The "T" in MTU is "Transmit", there isn't
a reason for it to constrain what you receive.

That would mean the only time I might ever want to tell my MAC
chip an interface MTU is for some kind of IP offload functions.
I wonder what that those functions would be, since most of the
things I can think of which might use that number don't seem
all that useful?

Dennis Ferguson

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