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. 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... -- Paul
