analisa masalah dari log debug mikrotik

Manual – Wireless : Wireless Debug Log Mikrotik

Debugging masalah Wireless menggunakan Log.

Secara default log RouterOS wireless menunjukkan bahwa klien menghubungkan dan memutuskan sebagai entri sederhana:

Itu sudah cukup bagi pengguna biasa untuk mengetahui bahwa wireless client dengan alamat MAC "00:80:48:41: AF: 2A" terhubung ke interface wireless "wlan1". Tapi sebenarnya ada entri log lebih tersedia daripada yang ditampilkan dalam standar logging. Mereka disebut 'debug' log yang memberikan informasi lebih rinci. Pada contoh berikut Debug Log Anda akan melihat klien yang sama terhubung ke AP di detail lebih dari yang ditemukan di khas logging:

Log debug akan memberikan Anda informantion lebih spesifik pada setiap langkah dari koneksi wireless Klien dan pemutusan. Baris pertama menunjukkan bahwa wireless client mencoba untuk terhubung ke AP. Pada baris kedua AP diperiksa untuk melihat apakah klien yang diperbolehkan untuk terhubung ke AP dan tindakan yang dihasilkan. Dan hanya pada baris ketiga yang Anda lihat bahwa klien tersambung. Ini hanyalah salah satu contoh dari pesan log debug. Gambaran dari semua entri debug ditulis di bawah ini.
Untuk mengaktifkan log debug wireless Anda harus menjalankan perintah seperti:

Atau di Winbox:

Ini akan membantu Anda memahami dan memperbaiki masalah wireless dengan mudah dan dengan sedikit interaksi dengan tim dukungan.

Station Mode

<MAC>@<DEV>: lost connection, <REASON>
Stasiun telah kehilangan koneksi ke AP karena <REASON>
<MAC>@<DEV>: failed to connect, <REASON>
Stasiun mencoba untuk terhubung ke AP, tapi gagal karena <REASON>
<MAC>@<DEV>: established connection on <FREQ>, SSID <SSID>
Stasiun mencoba dan berhasil terhubung ke AP dengan SSID <SSID> pada <FREQ> frekuensi.
<MAC>@<DEV>: MIC failure!!!
TKIP pesan gagal memeriksa integritas, seseorang harus mencoba masuk ke atau jaringan DOS, Jika lebih dari 1 MIC kegagalan ditemui selama periode 60-an, "penanggulangan TKIP" negara dimasukkan.
<MAC>@<DEV>: enter TKIP countermeasures
Dimasukkan TKIP pencegahan negara, ini berarti bahwa Stasiun akan diputuskan dari AP dan berdiam diri untuk 60an.

Ap Mode

<DEV>: radar detected on <FREQ>
Radar terdeteksi pada <FREQ> frekuensi, AP akan mencari saluran lain
<DEV>: data from unknown device <MAC>, sent deauth [(XXX events suppressed, YYY deauths suppressed)]
Data frame dari perangkat yang tidak dikenal (baca - tidak terdaftar ini AP) dengan <MAC> alamat mac diterima, AP dikirim bingkai deauthentication untuk itu (sesuai 802.11). XXX adalah jumlah kejadian yang belum login sehingga log tidak menjadi terlalu besar (log terbatas untuk 1 entri per 5s setelah pertama 5 entri), YYY adalah jumlah frame deauthentication yang seharusnya telah dikirim, tetapi tidak dikirim , sehingga sumber daya tidak sia-sia mengirimkan frame deauthentication terlalu banyak (hanya 10 frame per detik deauth diperbolehkan).
Penyebab kemungkinan pesan tersebut adalah bahwa Stasiun sebelumnya terhubung ke AP, yang belum tahu itu telah turun dari meja pendaftaran AP, pengiriman data ke AP. pesan Deauthentication memberitahu Stasiun yang tidak lagi terhubung.

<DEV>: denying assoc to <MAC>, failed to setup compression
Gagal untuk menginisialisasi kompresi di AP, kemungkinan besar karena ada terlalu banyak klien mencoba untuk terhubung dan menggunakan kompresi.

<DEV>: <MAC> is new WDS master
WDS-slave telah membentuk koneksi untuk menguasai WDS, ini berarti bahwa slave WDS mulai menerima klien dan bertindak sebagai AP.

<DEV>: <MAC> was WDS master
Pesan ini muncul setelah koneksi dengan <MAC> terputus, berarti bahwa slave WDS akan memutuskan semua klien dan mulai scanning untuk menemukan master baru WDS.

<MAC>@<DEV>: connected [, is AP][, wants WDS]
Stasiun dengan alamat <MAC> terhubung. jika "adalah AP" hadir - perangkat remote AP, jika "adalah WDS" hadiah, perangkat remote ingin mendirikan WDS link.
<MAC>@<DEV>: disconnected, <REASON>
Koneksi dengan Stasiun dengan alamat <MAC> diakhiri karena <REASON>

<MAC>@<DEV>: disconnected, <REASON>
Koneksi dengan Stasiun dengan alamat <MAC> diakhiri karena <REASON>

<DEV>: TKIP countermeasures over, resuming
pencegahan TKIP (60s periode diam) atas, AP resume bertindak sebagai AP.

<DEV>: starting TKIP countermeasures
Memasuki TKIP pencegahan negara (60s periode diam), semua klien akan hilang.

<Reason>

"joining failed" –  hanya dapat terjadi pada kartu Prism dalam modus stasiun, gagal untuk terhubung ke AP karena beberapa alasan
"join timeout" –  yang terjadi di Stasiun, gagal untuk menyinkronkan ke AP (menerima frame suar pertama). Kebanyakan sinyal lemah mungkin, remote dimatikan, gangguan yang kuat, beberapa isu lain yang terkait RF yang membuat komunikasi tidak mungkin.
"no beacons" – tidak ada rambu yang diterima dari remote akhir dari link WDS. Kebanyakan sinyal lemah mungkin, remote dimatikan, gangguan yang kuat, beberapa isu lain yang terkait RF yang membuat komunikasi tidak mungkin.
"extensive data loss" – interface lokal memutuskan untuk menjatuhkan koneksi ke perangkat remote karena ketidakmampuan untuk mengirim data ke remote setelah beberapa kegagalan pada tingkat serendah mungkin. Kemungkinan penyebab - terlalu sinyal lemah, perangkat remote dimatikan, gangguan yang kuat, beberapa isu lain yang terkait RF yang membuat komunikasi tidak mungkin.
"decided to deauth, <802.11 reason>" – interface setempat memutuskan melakukan remote deauthenticate menggunakan alasan 802.11 <802.11 alasan>.
"inactivity" - perangkat remote tidak aktif terlalu lama
"device disabled" - interface lokal punya dinonaktifkan 
"got deauth, <802.11 reason>" - menerima pemisahan frame dari perangkat jarak jauh, kode 802.11 alasannya adalah dilaporkan dalam <802.11 alasan> 
"got disassoc, <802.11 reason>" - received disassociation frame from remote device, 802.11 reason code is reported in <802.11 reason>
"auth frame from AP" - otentikasi frame dari perangkat jarak jauh yang dikenal sebagai AP, modus perubahan yang nampaknya paling pada perangkat remote dari AP untuk Stasiun. 
"bad ssid" - ssid buruk untuk link WDS
"beacon from non AP" - menerima frame beacon dari perangkat remote yang dikenal non-AP node, modus perubahan pada perangkat yang paling mungkin jauh dari Station ke AP.
"no WDS support" - tidak melaporkan mendukung WDS
"failed to confirm SSID" - gagal untuk mengkonfirmasi SSID ujung lain dari link WDS. 
"hardware failure" - beberapa kegagalan perangkat keras atau perilaku tak terduga. Tidak mungkin untuk dilihat. 
"lost connection" - hanya dapat terjadi pada kartu Prism dalam modus stasiun, koneksi ke AP yang hilang karena beberapa alasan. 
"auth failed <802.11 status>" - yang terjadi di Stasiun, AP menyangkal otentikasi, 802.11 kode status dilaporkan dalam <802.11 status>. 
"assoc failed <802.11 status>" - yang terjadi di Stasiun, AP menyangkal asosiasi, 802.11 kode status dilaporkan dalam <802.11 status>. 
"auth timeout" - yang terjadi di Stasiun, Stasiun tidak menerima respon terhadap frame otentikasi, baik link buruk atau AP mengabaikan Stasiun ini untuk beberapa alasan. 
"assoc timeout" - yang terjadi di Stasiun, Stasiun tidak menerima respon terhadap frame asosiasi, baik link buruk atau AP mengabaikan Stasiun ini untuk beberapa alasan.
"reassociating" - yang terjadi di AP: sambungan diasumsikan akan hilang, karena Stasiun itu dianggap sudah diasosiasikan upaya untuk asosiasi lagi. Semua informasi koneksi terkait harus dihapus, karena selama proses asosiasi parameter koneksi dinegosiasikan (karena itu "terputus"). Alasan mengapa Stasiun reassociates harus mencari di Station (penyebab paling mungkin adalah bahwa Stasiun karena alasan tertentu menjatuhkan koneksi tanpa memberitahu AP - misalnya hilangnya data, perubahan konfigurasi). 
"compression setup failure" - koneksi tidak mungkin, karena sumber daya tidak cukup untuk melakukan kompresi (terlalu banyak stasiun yang ingin menggunakan kompresi sudah terhubung)

<802.11 Reason> And <802.11 Status>

Ini adalah alasan angka kode status / dikodekan ke dalam pesan 802.11 manajemen. Pesan Log termasuk kode numerik dan deskripsi tekstual dari standar yang tepat dalam kelompok standar 802.11. Meskipun ini dimaksudkan untuk sejelas mungkin, harus diperhitungkan bahwa alasan sebenarnya / kode status yang muncul dalam bingkai manajemen tergantung hanya pada peralatan atau pembuat perangkat lunak - di mana satu perangkat mengirimkan 802.11 bingkai manajemen termasuk alasan yang tepat / kode status untuk situasi yang menyebabkan frame yang lain, dapat mengirim frame dengan alasan "tidak ditentukan" / kode status. Oleh karena alasan / kode status hanya harus dipertimbangkan informasi.
Seperti 802.11 standar berevolusi, RouterOS bisa kehilangan deskripsi tekstual untuk kode alasan / status bahwa beberapa perangkat digunakan. Dalam kasus seperti nilai numerik harus digunakan untuk pencarian makna dalam standar 802.11.
Dalam rangka untuk benar menafsirkan alasan / kode status, pemahaman yang baik tentang standar 802.11 kelompok diperlukan. Sebagian besar dari uraian tekstual adalah self-menjelaskan. Penjelasan untuk beberapa yang paling sering terlihat reson kode / status berikut.
class 2 frame received (6) - perangkat diterima "kelas 2" frame (asosiasi / reassociation frame manajemen) sebelum menyelesaikan proses otentikasi 802.11; 
class 3 frame received (7) - perangkat menerima "kelas 3" frame (bingkai data) sebelum menyelesaikan proses asosiasi;