Discussed with: Michael Dexter, Jan Bramkamp, jwd
Details
Details
Diff Detail
Diff Detail
- Repository
- R9 FreeBSD doc repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| website/content/en/releases/15.0R/relnotes.adoc | ||
|---|---|---|
| 875 | "The IP requires IP addresses" doesn't seem quite right. "It requires IP addresses to be assigned to the bridge interface itself, not to any of the member interfaces." perhaps? | |
Comment Actions
I was hoping for it to read "The Internet Protocol requires IP addresses..." because I want to put it on the internet protocol and not on FreeBSD. That is, FreeBSD allowed the old behavior, but the rest of the network never worked in all situations.
Comment Actions
Rebased, changed first IP to Internet Protocol to try to make it clearer.
If it still doesn't read well I'm happy to change it again.
| website/content/en/releases/15.0R/relnotes.adoc | ||
|---|---|---|
| 875 | i don't think this is right: IP itself doesn't require IP addresses to be assigned to a bridge rather than the member interfaces, this is a limitation of FreeBSD's implementation. it's true almost every other implementation of bridge has the same limitation (by design) but it's not inherent in IP. | |
| website/content/en/releases/15.0R/relnotes.adoc | ||
|---|---|---|
| 875 | The sysctl should be enclosed in backticks. | |
| website/content/en/releases/15.0R/relnotes.adoc | ||
|---|---|---|
| 874 | I will again humbly suggest that this change not be made in 15.0, but after the branch instead. In the meantime, the kernel should log a scary warning to the console when a bridge member has an IP address assigned. This is how we handled the removal of implicit netmasks, and it gives users more time to migrate their setups to the more restrictive default. This change is going to disrupt a lot of upgrades to 15.0. | |
Comment Actions
I do not like disruptive OS changes.
I like POLA.
We are the torchbearers of UNIX.
Half a century tradition.
Keep the big routers working, and look good doing it.
But I am the doc comitter, I'm supposed to tell the story of what you guys have done.
Is this what you guys have done?
| website/content/en/releases/15.0R/relnotes.adoc | ||
|---|---|---|
| 874 | i am considering this, we'll see. the issue is that assigning addresses to member interfaces doesn't work properly; we're not just deprecating an old feature, we're preventing people from configuring their network interface in a way that doesn't work. but it be the case that the downside of the change is too disruptive to make in 15.0 without an intermediate warning stage. | |
| website/content/en/releases/15.0R/relnotes.adoc | ||
|---|---|---|
| 874 | I ran into an issue on a couple of machines. The setup there is that the machines have one physical interface configured by DHCP and these machines are used to run virtual machines using bhyve. Therefore I had in /etc/rc.conf the setup of the physical interface via DHCP, creation of the bridge and adding the physical interface to the bridge. I changed this to using DHCP on the bridge interface. This does not work via /etc/rc.conf and I can't access the system anymore over the network. Running dhclient manually works without any problem. | |
| website/content/en/releases/15.0R/relnotes.adoc | ||
|---|---|---|
| 874 | i had another report of DHCP not working on a bridge. it may be related to devd; does it work if you use SYNCDHCP instead? i'll have a look at this and see if we can fix it in time for 15.0, but in the mean time, i think we are going to release with member_ifaddrs=1. | |
| website/content/en/releases/15.0R/relnotes.adoc | ||
|---|---|---|
| 874 |
Yes, it does. The interface comes up, goes down and up again when added to the bridge. The NIC is connected to a CISCO switch, which then takes some time to get the port active again.
OK. That would keep existing configurations working. | |
Comment Actions
The release note is wrong now: for now, bridge will continue to accept member interfaces with addresses assigned.