IPv4 broken on r222048

Garrett Cooper yanegomi at gmail.com
Tue Jun 7 18:15:08 UTC 2011

On Tue, Jun 7, 2011 at 11:13 AM, Bjoern A. Zeeb
<bzeeb-lists at lists.zabbadoz.net> wrote:
> On Jun 7, 2011, at 6:00 PM, Garrett Cooper wrote:
>> On Tue, Jun 7, 2011 at 10:41 AM, Bjoern A. Zeeb
>> <bzeeb-lists at lists.zabbadoz.net> wrote:
>>> On Jun 7, 2011, at 5:29 PM, Garrett Cooper wrote:
>>>> Hi,
>>>>    I'm running into an issue where ifconfig isn't executing properly,
>>>> and is emitting the following message:
>>>> # ifconfig re0 inet w.x.y.z
>>>> ifconfig: can't set link-level netmask or broadcast
>>>> #
>>> ...
>>>>    I haven't traced down what commit exactly is causing this, but the
>>>> issue appears to be a purely userland based problem so far (I
>>>> accidentally forgot to swap kernels before booting up the second time
>>>> and the symptoms are exactly the same).
>>> Yes, you lost.  My changes did that.  You are the second to hit it.
>>> Your kernel does not have "FEATURES()"  present and the new user space
>>> that came a couple of days later expect it and disable your IPv4
>>> because of that.
>>> The real problem is when people update the kernel, then update world
>>> and then figure out they need to go back to kernel.old.
>>> I'll add an UPDATING entry.
>> That I would expect, but I just built the kernel last night, installed
>> it, and am running it right now and I run into the same issue as I do
>> with the older kernel :). Was there any magic foo that I needed to use
>> to get FEATURES working properly, or was it supposed to be seamless? I
>> don't know because I never had a need to fiddle around with the
>> framework..
> It's supposed to be seamless.  Can you check if you have the following two?
> sysctl kern.features.inet
> sysctl kern.features.inet6
>> Looks like I need an old userland, because a new kernel/userland combo
>> doesn't seem to work as advertised :/...
> I think I just found a good "recovery" idea -- I should disable the
> features with rescue builds.  That should give one a working
> /rescue/ifconfig in all cases and should be sufficient to recover?

    That would be a good backup plan so people could at least avoid
painting themselves into a corner by accident.

More information about the freebsd-current mailing list