[Berlin-wireless] Madwifi Ad-Hoc mit HAL im ap-mode

[Felix Fietkau]

Sven-Ola Tücke wrote:
> Auch Moin,
> 
> ja - irgendwat hakt da noch. Mit fester BSSID gehts. Aber es braucht jetzt
> 2 Beacons fuer ein Standard-Merge (mit nosbeacon bzw. hal(hostap) 
> wenn IBSS). Zwei Beacons waer' sicher OK - aber beim Hochfahren 
> bringt Madwifi jetzt alle meine WRTs dazu, sofort *keine Beacons mehr* 
> zu senden. Warum? Keine Ahnung - das ist sicher interessant. Aber 
> fuer ein IBSS-Merge etwas kontraproduktiv.
Ich schau nochmal in den Code ob ich das mit den zwei Beacons noch gefixt 
kriege.

> P.S: was haelst du von diesem Fix fuer wpa_supplicant? Zeigt sonst im Sta-Mode 
> ganz viele Disconnect-Messages:
> 
> --- 360-sta_nodes.patch~        2008-10-08 07:55:18.000000000 +0200
> +++ 360-sta_nodes.patch 2008-10-08 07:55:18.000000000 +0200
> @@ -99,7 +99,7 @@
>  +
>  +      if (nstate == IEEE80211_S_RUN)
>  +              active = 1;
> -+      else if ((ostate >= IEEE80211_S_AUTH) && (nstate < ostate))
> ++      else if ((ostate > IEEE80211_S_AUTH) && (nstate < ostate))
>  +              active = 0;
>  +      else
>  +              return;
Das >= IEEE80211_S_AUTH war eigentlich gedacht, um das Roaming wesentlich
zu beschleunigen (< 1 sec im idealfall, selbst wenn der AP nicht sofort
antwortet). Sollte aber eigentlich nur dann nötig sein, wenn der Supplicant
selbst das Roaming kontrolliert. Gedacht war das ganze hauptsächlich, um
zu verhindern, dass der Supplicant-interne Timeout triggert, weil der 
üblicherweise viel zu lang ist. Gibt es außer der vielen Disconnect-Messages
noch andere Nebeneffekte?

- Felix