Re: kern/87506 : [PATCH] Fix alias support on vr interfaces

From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 10/28/05

  • Next message: John Baldwin: "Re: kern/87506 : [PATCH] Fix alias support on vr interfaces"
    Date: Fri, 28 Oct 2005 11:04:20 -0700
    To: John Baldwin <jhb@freebsd.org>
    
    
    

    On Fri, Oct 28, 2005 at 01:57:04PM -0400, John Baldwin wrote:
    > On Thursday 27 October 2005 04:14 pm, Brooks Davis wrote:
    > > On Thu, Oct 27, 2005 at 04:02:26PM -0400, Anish Mistry wrote:
    > > > On Thursday 20 October 2005 05:29 pm, Brooks Davis wrote:
    > > > > On Thu, Oct 20, 2005 at 04:51:21PM -0400, John Baldwin wrote:
    > > > > > On Thursday 20 October 2005 02:27 pm, Anish Mistry wrote:
    > > > > > > On Thursday 20 October 2005 11:15 am, John Baldwin wrote:
    > > > > > > > On Thursday 20 October 2005 10:23 am, Tom McLaughlin wrote:
    > > > > > > > > Hi, would someone be available to look at kern PR 87506? I
    > > > > > > > > found the problem while building a jail on my 6.0-RC1 box.
    > > > > > > > > When setting an alias on a vr device with ifconfig the
    > > > > > > > > alias address replaces the initial address of the device.
    > > > > > > > > marcus@ took a look at the problem for me and provided the
    > > > > > > > > patch for the vr interface which I tested and it resolved
    > > > > > > > > the problem. Without the patch I can't create a jail that
    > > > > > > > > is network accessible.
    > > > > > > > >
    > > > > > > > > Marcus also notes in the PR that the rl, sis, ti, and tl
    > > > > > > > > may also be affected by this bug. If anyone has any other
    > > > > > > > > questions or needs someone to test any changes to the patch
    > > > > > > > > just let me know. I only have vr interfaces on my FreeBSD
    > > > > > > > > machines though. Thanks.
    > > > > > > > >
    > > > > > > > > Tom
    > > > > > > >
    > > > > > > > I'm not sure that fix is really the right fix. The patch
    > > > > > > > just makes vr(4) ignore changes to if_flags while the driver
    > > > > > > > is up. Probably there is a bug in vr(4)'s handling of alias
    > > > > > > > addresses. I did just reproduce this on my laptop's rl(4)
    > > > > > > > interface though. I'll see if I can't figure out what is
    > > > > > > > happening.
    > > > > > >
    > > > > > > I'm also seeing this too along with the following.
    > > > > > >
    > > > > > > I'm not sure if this is related, but I'm seeing the following
    > > > > > > on RELENG_6 and CURRENT, but and older RELENG_5 as of ~2 months
    > > > > > > ago doesn't show this problem.
    > > > > > > I'm trying to setup my workstation with a normal DHCP'd address
    > > > > > > and an alias IP for a jail running on the system, but the alias
    > > > > > > setting wipes out all the other addresses on the interface.
    > > > > > > in /etc/rc.conf:
    > > > > > > ifconfig_rl0="DHCP"
    > > > > > > ifconfig_rl0_alias0="inet 192.168.1.10 netmask 255.255.255.255"
    > > > > > >
    > > > > > > I've checked the rc boot order (on RELENG_6 and CURRENT) and it
    > > > > > > seems correct:
    > > > > > > netif
    > > > > > > dhclient
    > > > > > > netif
    > > > > > >
    > > > > > > I narrowed it down to:
    > > > > > > dhclient rl0
    > > > > > > ifconfig rl0 inet 192.168.1.11 netmask 0xffffffff alias
    > > > > > > [dhclient prints a message here saying connection closed and
    > > > > > > exiting]
    > > > > > >
    > > > > > > All of the other addresses on the card are removed.
    > > > > > > I'm also seeing this on dc. So thinking it to be a problem in
    > > > > > > ifconfig I copied over the version from my RELENG_5 box, and
    > > > > > > that did the same thing...so this seems to be present several
    > > > > > > of the network drivers in RELENG_6/CURRENT.
    > > > > >
    > > > > > Yes, it seems to be an issue with dhclient. If I turn dhclient
    > > > > > off and manually configure my NIC then the alias works fine:
    > > > > > rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    > > > > > options=8<VLAN_MTU>
    > > > > > inet6 fe80::290:f5ff:fe0e:c8e5%rl0 prefixlen 64 scopeid
    > > > > > 0x2 inet 10.50.41.234 netmask 0xfffffe00 broadcast 10.50.41.255
    > > > > > inet 10.50.41.101 netmask 0xffffffff broadcast 10.50.41.101 ether
    > > > > > 00:90:f5:0e:c8:e5
    > > > > > media: Ethernet autoselect (100baseTX <full-duplex>)
    > > > > > status: active
    > > > >
    > > > > I believe the problem is that adding an address to a NIC causes a
    > > > > call to ifp->if_init() which resets the media and triggers a
    > > > > LINK_DOWN event in all too many cases. Using if_init here is
    > > > > rather like driving finishing nails with a sledge hammer.
    > > >
    > > > Has there been any resolution of this issue? Since 6.0 is just around
    > > > the corner.
    > >
    > > No. It's going to require non-trivial changes to the design of drivers
    > > and eventually some changes to the driver API to really fix this so it's
    > > really too late in the game.
    > >
    > > I think we need to document the lack of support for this configuration
    > > and move on. Frankly, it's a configuration I see no compelling reason
    > > to support. If you are setting alises, you should know what your
    > > address is so you don't need dhcp. I'm aware there are other reasons to
    > > want dhcp, but I personally put this sort of thing in the "that would be
    > > nice" category. We should try to fix it, but it's no where near the top
    > > of my list.
    >
    > Actually, I think the best fix would be to add some de-bounce logic to
    > dhclient so that when it gets a link down state, it waits a second before
    > acting on it, and if it gets a link up event before the second expires it
    > just cancels the pending link down action. That change would probably go a
    > long way to fixing several people's problems with spurious link state
    > changes.

    True. Dhclient should however complain loudly if it happens with any
    kind of frequency. Note that one second probably won't cut it with many
    gigabit nics. :(

    -- Brooks

    -- 
    Any statement of the form "X is the one, true Y" is FALSE.
    PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
    
    



  • Next message: John Baldwin: "Re: kern/87506 : [PATCH] Fix alias support on vr interfaces"

    Relevant Pages

    • Re: Sen. Specter threatens to cut off funding for secret wiretaps
      ... Of course that's not Iraq either but you get my drift. ... the same reason Clinton wasn't convicted by the senate. ... fix it is to legislatively close that loophole. ... initiating impeachment proceedings would be political suicide. ...
      (rec.martial-arts)
    • Re: WMP 9 - no full mode?
      ... Turns out the fix was not gpedit, ... For some undesirable reason, our corporate IT ... regedit turned all th eusual features back on! ... > Beauty is only skin deep, but ugly goes clear to the ...
      (microsoft.public.windowsmedia.player)
    • Re: new to python - trouble calling a function from another function
      ... called the standards governing Python behaviour, ... have a good reason not to. ... I determined that I had a tab in front of the function name however the actual fix was to put in spaces until it lined up with all the other 'def' lines. ...
      (comp.lang.python)
    • Re: Sen. Specter threatens to cut off funding for secret wiretaps
      ... the same reason Clinton wasn't convicted by the senate. ... fix it is to legislatively close that loophole. ... Congress doesn't have the power to arrest. ... The dems don't have the power to force an impeachment. ...
      (rec.martial-arts)
    • Re: whats the ifc corresponding argument for -bp in absoft f90
      ... > The problem is dsinwhere y is a single precision floating point while ... Guess I have to ask why you don't just fix the code? ... Is this the *ONLY* reason you are using the -dp option? ... I wouldn't guarantee that it necessarily has such a switch. ...
      (comp.lang.fortran)