<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kel Modderman wrote:
<blockquote cite="mid:200803261109.25725.kel@otaku42.de" type="cite">
  <pre wrap="">
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: &lt;script&gt; &lt;interface&gt; &lt;event&gt;, and wpa_cli sets a few env
variables at that time too.

When &lt;interface&gt; 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.
  </pre>
</blockquote>
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&nbsp; 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.<br>
<br>
So yes having an interfaces variable like "wpa_control_bridge -" sounds
like a great idea.<br>
<br>
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.<br>
<br>
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&nbsp; 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)<br>
<br>
Hmm second thought - it may be more logical to set "wpa_iface
&lt;blah&gt;" and "wpa_ip_iface &lt;foO&gt;" or "wpa_ip_iface none".<br>
<br>
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.<br>
<br>
By the way - are we much closer to a fix for <a
 href="mailto:373180@bugs.debian.org">373180</a>? When testing I keep
forgetting to kill wpa_supplicant and I wonder why nothing works...<br>
<br>
--<br>
Paul<br>
<br>
</body>
</html>