[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9cc824381b2a4eb28a09e5a35fd8ab5e@DFM-DB3MBX15-06.exchange.corp.microsoft.com>
Date: Fri, 23 May 2014 15:19:42 +0000
From: Haiyang Zhang <haiyangz@...rosoft.com>
To: Dan Williams <dcbw@...hat.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: question: Any way to trigger DHCP renewal from kernel code?
> -----Original Message-----
> From: Dan Williams [mailto:dcbw@...hat.com]
> Sent: Friday, May 23, 2014 11:07 AM
> To: Haiyang Zhang
> Cc: netdev@...r.kernel.org
> Subject: Re: question: Any way to trigger DHCP renewal from kernel code?
>
> On Thu, 2014-05-22 at 22:24 +0000, Haiyang Zhang wrote:
> > Hi,
> >
> > Our synthetic network driver is notified when the Hyper-V host
> > resume from sleep/hibernation. We need to renew DHCP in this case.
> > I'm looking for a way to trigger DHCP renewal from kernel mode
> > code.
>
> Another approach could be to change the 'operstate' of your synthetic
> netdevice to IF_OPER_DORMANT and then back to IF_OPER_UP. Possibly like
> drivers/net/hsr/hsr_device.c does in __hsr_set_operstate().
>
> The netdev_state_change() call will send out a netlink message that the
> device has changed, which includes the device flags. Before changing
> the operstate, the flags will include IFF_RUNNING, which indicates the
> netdevice is operating and passing traffic. When you change the
> operstate to IF_OPER_DORMANT, a netlink message will be sent which does
> *not* include IFF_RUNNING. Then changing back to IF_OPER_UP will emit a
> netlink message that *does* include IFF_RUNNING again.
>
> The DHCP client can listen for device flag changes and trigger a DHCP
> renew when the IFF_RUNNING flag re-appears on the device. There are
> some notes about this in Documentation/networking/operstates.txt too.
>
> (Random note: long ago when WiMAX was relevant there was also a need to
> trigger a DHCP renew in userspace based on events from the driver; a
> renew should be performed when the device comes out of fast sleep, which
> can happen quite often. I don't remember how Inaky solved this, but I
> think it was out-of-band driver messages to the userspace control
> daemon. A more standardized kernel facility somewhat less convoluted
> than manually munging operstates would have been nice...)
Thanks a lot to you and others for the help!
- Haiyang
Powered by blists - more mailing lists