ETSI DFS time limit

Panjan · Beitrag von **Panjan** » 12 Apr 2006, 14:34

Hallo,

das Thema Radarmustererkennung ist mit der 6.06 ja im Prinzip durch.

Wie kommt es, dass ich dann trotzdem immer noch ETSI-DFS-time-limits habe?

Auszug aus dem Log:

2797 12.4.2006 14:06:41 WLAN-2 Key handshake with peer 00:07:d5:01:0f:17 successfully comp 0007d5010f17
2796 12.4.2006 14:05:30 WLAN-2 Channel change due to ETSI DFS time limit 0007d5010c0f
2795 12.4.2006 4:12:38 WLAN-2 Key handshake with peer 00:07:d5:01:0f:17 successfully comp 0007d5010f17
2794 12.4.2006 4:12:28 WLAN-2 Channel change due to ETSI DFS time limit 0007d5010c0f

Hier sind zwei Sachen erstaunlich:

1. Der Wert DFS-Rescan-Stunden steht auf 4. Um 4 Uhr hätte also ein "manually forced scan" laufen müssen.
2. Warum ist 10 Stunden später das Time-Limit schon wieder abgelaufen, obwohl dazwischen keine Einträge im Log stehen?

Gruß
Panjan

alf29 · Beitrag von **alf29** » 12 Apr 2006, 14:45

Moin,

istr das ein OAP? Die 12 Minuten Differenz könnten sich
durch die falsch gehende Uhr ergeben (Timestamps werden
m.W. beim Neusetzen der Uhr nachgezogen), wenn nach
dem Rescan die interne Uhr per NTP neu gesetzt wurde.

Was um 14 Uhr passiert ist, weiß ich aber auch nicht
aus dem Stegreif...

Gruß Alfred

Panjan · Beitrag von **Panjan** » 12 Apr 2006, 14:55

alf29 hat geschrieben:Was um 14 Uhr passiert ist, weiß ich aber auch nicht
aus dem Stegreif...

Dann lasse ich mich mal überraschen. Wir hatten das schon häufiger. EFS-Timelimits, obwohl keine Kanalwechsel protokolliert waren. Aber da insgesamt das Problem der Kanalwechsel größer war, hatte ich mich bis jetzt noch nicht gemeldet.

Gruß
Panjan

Panjan · Beitrag von **Panjan** » 13 Apr 2006, 08:46

Hallo,

vielleicht hilft das weiter:

1. Gestern um 21.15 hatte ich dann zum dritten Mal eine neue Kanalsuche aufgrund ETSI DFS-Time-Limit.

2799 12.4.2006 21:15:51 WLAN-1 Key handshake with peer 00:07:d5:01:0c:b1 successfully comp 0007d5010cb1
2798 12.4.2006 21:15:45 WLAN-1 Channel change due to ETSI DFS time limit 0007d5010c10

2. Ich habe aufgrund der Radarsignalprobleme öfters die Firmeware geändert. Ich konnte davon ausgehen, dass an diesem Tag auch immer ein ETSI-DFS-Time-Limit auftritt.

Gruß
Panjan

Panjan · Beitrag von **Panjan** » 13 Apr 2006, 08:52

Und noch etwas: Das verhalten ist nicht auf einen OAP beschränkt!

Gruß Panjan

alf29 · Beitrag von **alf29** » 13 Apr 2006, 10:53

Hi,

auf einem OAP würde ich's verstehen, die 6.0x hat da
offensichtlich noch den Bug, daß beide WLAN-Tasks die
Zeitboni herunterzählen und die demzufolge spätestens
nach einem halben Tag aufgebraucht sind. Das ganze ist
etwas verzwickt, deshalb wird's erst mit der 6.10 eine
Lösung dafür geben. Aber welche anderen Geräte meinst
Du denn noch?

Gruß Alfred

Panjan · Beitrag von **Panjan** » 13 Apr 2006, 11:02

alf29 hat geschrieben:Auf einem OAP würde ich's verstehen, ... Aber welche anderen Geräte meinst Du denn noch?

Zum Glück sind es nur OAPs, aber davon haben wir mehrere. Ich wollte mit meiner Bemerkung nur sagen, dass sich das Problem nicht auf einen OAP beschränkt.

Gruß
Panjan

Panjan · Beitrag von **Panjan** » 29 Apr 2006, 14:06

Hallo,

es gibt noch eine Konstellation, bei der ein unnötiger Rescan aufgrund DFS-Timelimit entsteht.

- OAP wird stromlos gemacht und wieder eingeschaltet.
- Zeit steht iregendwo im Jahr 1900
- Im Laufe des Tages bekommt der OAP über NTP eine neue Zeit
- Irgendwann nachts kommt er erzwungene DFS-Scan
- ca. 24 Stunden nach dem Einschalten des Geräts erfolgt ein Rescan aufgrund DFS-Timelimit.

Ist es möglich, direkt beim Einschalten des Geräts per NTP eine Uhrzeit zu holen?

Gruß
Panjan

alf29 · Beitrag von **alf29** » 29 Apr 2006, 15:53

Moin,

Ist es möglich, direkt beim Einschalten des Geräts per NTP eine Uhrzeit zu holen?

Das tut das Gerät ja, wenn ein NTP-Server konfiguriert ist. Das Problem ist nur u.U., daß
die WLAN-Verbindung (noch) nicht steht und der NTP-Server nur darüber erreichbar ist...

Gruß Alfred