netdev - RE: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7fd6ae806627412da08b51200230b0ec@DFM-DB3MBX15-06.exchange.corp.microsoft.com>
Date:	Mon, 23 Jun 2014 18:23:34 +0000
From:	Haiyang Zhang <haiyangz@...rosoft.com>
To:	Greg KH <greg@...ah.com>
CC:	Olaf Hering <olaf@...fle.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"driverdev-devel@...uxdriverproject.org" 
	<driverdev-devel@...uxdriverproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [PATCH net-next] hyperv: Add handler for
 RNDIS_STATUS_NETWORK_CHANGE event



> -----Original Message-----
> From: Greg KH [mailto:greg@...ah.com]
> Sent: Monday, June 23, 2014 12:29 PM
> To: Haiyang Zhang
> Cc: Olaf Hering; netdev@...r.kernel.org; jasowang@...hat.com; driverdev-
> devel@...uxdriverproject.org; linux-kernel@...r.kernel.org;
> davem@...emloft.net
> Subject: Re: [PATCH net-next] hyperv: Add handler for
> RNDIS_STATUS_NETWORK_CHANGE event
> 
> On Mon, Jun 23, 2014 at 04:09:59PM +0000, Haiyang Zhang wrote:
> >
> >
> > > -----Original Message-----
> > > From: Olaf Hering [mailto:olaf@...fle.de]
> > > Sent: Monday, June 23, 2014 9:17 AM
> > > To: Haiyang Zhang
> > > Cc: Greg KH; netdev@...r.kernel.org; jasowang@...hat.com; driverdev-
> > > devel@...uxdriverproject.org; linux-kernel@...r.kernel.org;
> > > davem@...emloft.net
> > > Subject: Re: [PATCH net-next] hyperv: Add handler for
> > > RNDIS_STATUS_NETWORK_CHANGE event
> > >
> > > On Mon, Jun 23, Haiyang Zhang wrote:
> > >
> > > > > I think its reasonable to expect guest config changes on this
> > > > > new kind of host. Would a link-down/link-up event work? I'm sure
> > > > > it will, there is enough code floating around in the guests
> > > > > which handles cable
> > > unplug.
> > > >
> > > > Do you mean netif_carrier_off() / netif_carrier_on()? They are
> > > > already called in the code before this patch, but DHCP renew is
> > > > not triggered by them.
> > >
> > > I do not know how to simulate a cable unplug. The point is that
> > > calling /etc/init.d/network will fail, at least in SLES12.
> > > Maybe some sort of "DHCP refresh required" event is required?
> > > Maybe the DHCP clients need to renew on cable unplug?
> > > No idea what the solution to the issue really is.
> >
> > Yes, it will be great if there is such a "DHCP refresh required"
> > event, or DHCP clients are triggered when netif_carrier_off() then
> netif_carrier_on().
> >
> > I have tried some possibilities, like IF_OPER_DORMANT then IF_OPER_UP
> > with
> > netdev_state_change() etc. but not able to trigger DHCP review. I will
> > look at this further...
> >
> > So, what's the equivalent or similar command to "network restart" on
> > SLES12? Could you update the command line for the usermodehelper when
> > porting this patch to SLES 12?
> 
> Given that this change will fail on all future distro releases, and almost all of
> the community distros today, I don't see how this is acceptable at all.  Nor
> would it be any better if you switch to a systemd command line script as well.
> You should just work like any other network device works in this situation when
> it comes to enabling/disabling the device.  Worse case, just tear down the
> whole network device at suspend time, and recreate it at resume.

I will look into these options.

Thanks,
- Haiyang


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html