Hi Paul, On Wednesday 26 March 2008 19:11:52 Paul Hedderly wrote: > Kel Modderman wrote: > > I think this patch works, but modifies wpa_action in a way it is clearly not > > intended to be. > > > > When wpa_supplicant experiences a CONNECTED|DISCONNECTED event it executes > > an action script like: <script> <interface> <event>, and wpa_cli sets a few > > env > > variables at that time too. > > > > When <interface> is in a bridge do we always want to act on the bridge and > > not > > the interface? If this is always the case should wpa_supplicant supply the > > bridge interface name as argument when it is started with the bridge option? > > If not, we should make this somehow adjustable. > > > > One way would be to have WPA_BRIDGE variable set by wpa_cli at script > > execution > > time, as it does for WPA_ID and WPA_CTRL_DIR, rather than to rely on > > environment variables inherited from daemon start time. Otherwise, the > > script > > could check IF_WPA_BRIDGE before ignoring the arguments wpa_cli gave it and > > using IFACE environment variable that is set only at daemon start time. > > > > Thanks, Kel. > > > You are right that my patch it is a totally brute force approach and > assumes that the wireless interface is the primary bridge interface - I > submitted it only to demonstrate what I wanted to be able to do and show > that it is possible - I have actually changed most references to > WPA_IFACE to IFACE in the script for myself in the down and check subs. > But that is not a complete solution. > > So yes having an interfaces variable like "wpa_control_bridge -" sounds > like a great idea. > > One thing I think should be clear, is that if the wireless interface is > part of a bridge, it's own IP should never be set, and there should > never be any routes on it.
Please try attached patch to /sbin/wpa_action, without your other changes, see if it works. > > So if the wireless is part of a bridge (and setting "wpa_iface" gives > that expectation,) then wpa should either control IP/routes on the > bridge or do nothing with IP at all. So perhaps the option should be > "wpa_ignore_ip -" having the default to do IP/route/dhcp setting on the > bridge, giving room for those who might be using their laptop as > effectively a roaming access point. (That would be a weird setup - using > an AP to control the SSID, and using a station to route traffic... :O) > > Hmm second thought - it may be more logical to set "wpa_iface <blah>" > and "wpa_ip_iface <foO>" or "wpa_ip_iface none". > > Anyway, my hack is making me very happy here - What I havent got round > to testing properly is if it will still work fine with a normal setup. > Oh hang it, I'll do a quick check now.... Yes - it all appears to work > just fine. > > By the way - are we much closer to a fix for 373180 > <mailto:[EMAIL PROTECTED]>? When testing I keep forgetting to kill > wpa_supplicant and I wonder why nothing works... No. See my last comment on that thread. Thanks, Kel. --- --- debian/ifupdown/wpa_action.sh (revision 1157) +++ debian/ifupdown/wpa_action.sh (working copy) @@ -36,6 +36,10 @@ exit 0 fi +if [ "$IF_WPA_BRIDGE" ]; then + WPA_IFACE="$IF_WPA_BRIDGE" +fi + case "$WPA_ACTION" in "CONNECTED") wpa_log_init --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
