Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Nov 2013 13:47:42 +0900 (JST)
From:      Hiroki Sato <hrs@FreeBSD.org>
To:        jhb@FreeBSD.org
Cc:        clutton@zoho.com, adrian@FreeBSD.org, freebsd-wireless@FreeBSD.org, freebsd-arch@FreeBSD.org
Subject:   Re: service netif restart [iface] runs a wpa_supplicant twice
Message-ID:  <20131112.134742.1669584178551946391.hrs@allbsd.org>
In-Reply-To: <201311051154.18872.jhb@freebsd.org>
References:  <1383419596.3253.42.camel@eva02.mbsd> <CAJ-VmomAiBTFiiFn6ENtJMjBurhq-U2nFh_vWeOxkN=3d6MZTQ@mail.gmail.com> <201311051154.18872.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Baldwin <jhb@freebsd.org> wrote
  in <201311051154.18872.jhb@freebsd.org>:

jh> I also tested vlans created via vlans_<if> and they should use the same fix as
jh> well.  Note that this model is more consistent with how cloned_interfaces
jh> works where ifn_start is not explicitly run when each interface is created.
jh> Instead, we rely on devd kicking off pccard_ether for those as well.

 No, for cloned_interfaces, the ifn_start will be kicked even when
 devd is unavailable because rc.d/netif calls clone_up() and then
 ifn_start() sequentially.  Since an IFNET ATTACH event is generated
 upon clone_up(), so actually the ifn_start() runs twice on every boot
 time (or rc.d/netif restart ifn).

 Since childif_*() is invoked at the end of ifn_*(), configuration of
 the child interfaces does not happen.  This is the reason why there
 was ifn_start() in childif_create().

 It is not efficient and it is reasonable to leave ifn_start() to devd
 if available, but it is difficult to detect it correctly because the
 IFNET ATTACH handler may be disabled in devd.conf.  "pgrep devd" is
 not reliable enough.

 As pointed out, this duplication can be a problem when configuration
 is performed by a program because multiple instances of the program
 are invoked.  In the other cases, there is no problem because
 ifn_start() is idempotent, though.

 As a workaround, dhclient is not invoked from ifconfig_up() like
 this:

   222          if wpaif $1; then
   223                  /etc/rc.d/wpa_supplicant start $1
   224                  _cfg=0          # XXX: not sure this should count
   225          elif hostapif $1; then
   226                  /etc/rc.d/hostapd start $1
   227                  _cfg=0
   228          fi
   229
   230          if dhcpif $1; then
   231                  if [ $_cfg -ne 0 ] ; then
   232                          ${IFCONFIG_CMD} $1 up
   233                  fi
   234                  if syncdhcpif $1; then
   235                          /etc/rc.d/dhclient start $1
   236                  fi
   237                  _cfg=0
   238          fi

 ifconfig_IF="DHCP" means to leave invoking dhclient to devd, and
 ifconfig_IF="SYNCDHCP" means rc.d/netif calls dhclient directly.  I
 think similar workaround can be implemented for WPA and HOSTAP and
 solve the originally-reported problem.

 For inconsistency childif_*(), what do you think about integrating
 vlans_IF and wlans_IF into cloned_interfaces and removing the
 childif_*() stage in ifn_*()?  We can keep vlans_IF and wlans_IF as
 well as introduce a new syntax into cloned_interfaces like

  cloned_interfaces="em0.100 em0.110 em0.myvlan ath0.wlan0"

 which is equivalent to

  vlans_em0="100 110 myvlan"
  wlans_ath0="wlan0"

 The rc.d/netif does clone_up() for the child interfaces first and
 then does ifn_start() for them, so

 # service netif restart wlan0

 works as expected (tear down, recreate, and reconfigure the
 interface).

 Of course, this does not solve the duplicate invocation of the netif
 script.  To solve it, I think we need a knob to disable IFNET events
 in a per-interface basis temporarily.

-- Hiroki

----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (FreeBSD)

iEYEABECAAYFAlKBsu4ACgkQTyzT2CeTzy37MQCgpHsiUmxgrWJT9xbljklDRJPR
r0wAnRdU90LfIZn7mgQFEwvNB42WZMGs
=LYHy
-----END PGP SIGNATURE-----

----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131112.134742.1669584178551946391.hrs>