<div dir="ltr"><div>Oh, I made a mistake.</div><div><div>I did not use hostapd, I only used wpa_supplicant with ovs to use wlan0 as just port.</div></div><div><br></div>My context is a little different, but I think it is the same reason. <div>Wpa_supplicant use -i option, so I assumed it is the same reason.<div><br></div><div>Thanks,</div><div>Junguk</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-19 10:55 GMT-07:00 Helmut Schaa <span dir="ltr"><<a href="mailto:helmut.schaa@googlemail.com" target="_blank">helmut.schaa@googlemail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Nov 19, 2014 at 6:42 PM, Junguk Cho <<a href="mailto:jmanbal@gmail.com">jmanbal@gmail.com</a>> wrote:<br>
> When I add wlanX to bridge in openvswitch, the bridge does not reply EAPOL<br>
> frame<br>
> even though I set up rules between wlanX and br0 with in_port and out_port<br>
> fileds.<br>
><br>
> I can only see EAPOL (Message 1 of 4 ) in bridge with tcpdump but it did not<br>
> reply.<br>
> So I assumed EAPOL authentication is related to wlanX.<br>
><br>
> Is it right? Just wondering why it did not reply to EAPOL message.<br>
<br>
</span>hostapd needs to know about the bridge/ovs interface to register a<br>
PF_PACKET socket for EAPOL frames.<br>
Otherwise hostapd opens a socket on wlanX but since EAPOL frames are<br>
data frames they end up being bridged and hostapd never receives them.<br>
<span class=""><br>
> Would you please clarify "I'm using this one but did not consider sending it<br>
> upstream as it is quite a hack"?<br>
<br>
</span>I'm using the patch referenced in my previous email but it is more of<br>
a hack then a clean patch ...<br>
<span class="HOEnZb"><font color="#888888"><br>
Helmut<br>
</font></span></blockquote></div><br></div>