Ev ağında LAN/Ethernet üzerinden ağa bağlı bir access point olarak ASUS RP-N12 kullanıyorum. 2.4 GHz 802.11n döneminden kalma, mütevazı bir cihaz. Bu AP'nin hızı mobil cihazlarıma ve 4k dahil Netflix gibi video streaminge yetiyor fakat sorunum hız değil stabilite.
Cihaz bazen günlerce hiçbir sorun çıkarmadan çalışıyor, bazen de ağ trafiği ve kendi arayüzüne ulaşılamayacak şekilde tam kilitleniyor. Kilitlenince kapatıp açmak (power cycle) gerekiyor, sırf bu sorun yüzünden yeni access point araştırırken AP'nin remote logunu PC'ye yazacak şekilde konfigüre edip bir sonraki kilitlenmeyi beklemeye karar verdim.
Önce İçeride Ne Çalıştığına Bakalım
RP-N12'nin web arayüzünde bir sistem günlüğü bulunuyor. İlk bakışta cihazın oldukça eski bir embedded Linux sistemi kullandığı görülüyor:
Jan 1 00:00:09 kernel: klogd started: BusyBox v1.12.1
init_r4k_clocksource...
Ralink gpio driver initialized
flash manufacture id c2 device 20 16
MX25L3205D ... 4096 Kbytes
Ralink APSoC Ethernet Driver Initialization v3.1
Raeth v3.1 (Tasklet)
RT305x_ESW: Link Status Changed
Firmware BusyBox 1.12.1 tabanlı. Ethernet tarafında Ralink'in Raeth sürücüsü ve RT305x_ESW switch sürücüsü kullanılıyor. Flash ise Macronix MX25L3205D; kapasitesi yalnızca 4 MB.
Elimizde kaynakların son derece sınırlı olduğu eski nesil bir embedded Linux sistem var. Bu da işi daha zevkli hale getiriyor açıkçası :P
Logda görülen MTD partition boundary uyarıları da dikkat çekici fakat tek başına bunları arızanın göstergesi saymak doğru olmaz. Firmware'in flash partition düzeninden kaynaklanan normal boot mesajları da olabilirler.
Problem: Cihaz Kilitlendiğinde Kendi Loguna da Ulaşılamıyor
Web arayüzündeki log normal çalışma sırasında faydalı. Fakat cihaz tamamen kilitlendiğinde web arayüzünün de erişilemez hale geliyor.
Dolayısıyla logu RP-N12'nin dışına çıkarmam gerekiyor.
Fakat önce cihazın içine biraz daha yakından bakmak istedim.
Telnet'i Açmak
RP-N12'nin Administration → System bölümünde Enable Telnet seçeneği bulunuyor.
Telnet'i geçici olarak açtıktan sonra cihazın IP adresine bağlandım:
192.168.1.100
İlk denemeyi Windows'un kendi Telnet istemcisiyle yaptım. Çalışıyor fakat scrollback ve terminal davranışı pek kullanışlı değil. Özellikle uzun çıktıları incelemek için kısa sürede PuTTY'ye geçtim.
PuTTY'de ayrıca All session output logging açarak yaptığım bütün işlemleri PC tarafında kaydetmeye başladım.
Side quest: NTP sorunu, Tarih 2011'de Kalmış
Shell'e girdikten sonra ilk dikkat çeken şey cihazın saatiydi:
# date
Sat Jan 1 00:39:08 UTC 2011
Web arayüzünde NTP sunucusu olarak pool.ntp.org tanımlıydı fakat cihaz saati bir türlü güncelleyemiyordu.
İlk şüpheli doğal olarak NTP idi. Fakat biraz kurcalayınca problemin NTP ile ilgili olmadığını gördüm.
# cat /etc/resolv.conf
# route -n
192.168.1.0 0.0.0.0 255.255.255.0 U br0
127.0.0.0 0.0.0.0 255.0.0.0 U lo
0.0.0.0 0.0.0.0 0.0.0.0 U br0
/etc/resolv.conf tamamen boştu.
Daha önemlisi cihazın geçerli bir default gateway'i yoktu.
ping sonucu bunu doğruladı:
# ping -c 3 1.1.1.1
100% packet loss
# ping -c 3 pool.ntp.org
ping: bad address 'pool.ntp.org'
Burada ilginç bir ayrım var. RP-N12 access point/bridge olarak istemcilerin Ethernet trafiğini gayet güzel taşıyabiliyor. Wi-Fi istemcileri ana router üzerinden internete çıkabiliyor.
Fakat RP-N12'nin kendi Linux işletim sistemi internete çıkamıyor.
İlgili NVRAM değerlerine baktığımda tablo şöyleydi:
lan_gateway=
wan_pppoe_gateway=
wan_gateway=
dhcp_dns1_x=
wan_dns=
lan_netmask=255.255.255.0
lan_dhcp=0
lan_hostname=RP-N12
lan_ipaddr=192.168.1.100
lan_ifname=br0
lan_proto_x=0
RP-N12 192.168.1.100 statik IP adresiyle çalışıyor fakat cihazın kendi management plane'i için gateway ve DNS bilgileri oluşmamış.
NVRAM'i hemen değiştirmek istemedim. Sonuçta amacım cihazı tamir etmeden önce mevcut haliyle neden kilitlendiğini gözlemlemekti.
Bu nedenle yalnız RAM'de geçerli olacak geçici bir route ve DNS tanımladım:
Not: Bu iki değişikliği NVRAM'e yazmadım. Dolayısıyla RP-N12 reboot ederse default route ve /etc/resolv.conf değişiklikleri kaybolacak. Remote syslog bundan bağımsız; RP-N12 ile log bilgisayarı aynı 192.168.1.0/24 ağında olduğundan 192.168.1.108 adresine UDP/514 göndermek için gateway veya DNS gerekmiyor.
# route add default gw 192.168.1.1 br0
# echo "nameserver 192.168.1.1" > /etc/resolv.conf
Sonuç:
# ping -c 3 192.168.1.1
0% packet loss
# ping -c 3 1.1.1.1
0% packet loss
# ping -c 3 pool.ntp.org
0% packet loss
pool.ntp.org artık çözülüyor ve internete erişiliyordu.
Bir süre sonra firmware'in kendi NTP mekanizması da devreye girdi:
# date
Thu Sep 17 21:52:11 UTC 2026
Yani cihazın NTP sunucusuna ulaşacak yolu yoktu.
Bu arada eski firmware'in İstanbul zaman dilimi kaydı da güncel değildi. Türkiye artık yıl boyunca UTC+3 kullandığı için aynı UTC offset'ine sahip ve DST uygulamayan (GMT+03:00) Nairobi seçeneğini kullandım.
RAM Ne Durumda?
Kilitlenmenin nedenlerinden biri memory leak olabilir. Bu kadar az RAM'li bir sistemde küçük bir kernel/driver sızıntısı bile uzun uptime sonunda önemli hale gelebilir.
İlk ölçüm:
MemTotal: 13864 kB
MemFree: 976 kB
Buffers: 1104 kB
Cached: 2844 kB
Slab: 4884 kB
SReclaimable: 552 kB
SUnreclaim: 4332 kB
SwapTotal: 0 kB
Bir süre sonraki ikinci ölçüm:
MemTotal: 13864 kB
MemFree: 1244 kB
Buffers: 1184 kB
Cached: 2556 kB
Slab: 4892 kB
SReclaimable: 532 kB
SUnreclaim: 4360 kB
SwapTotal: 0 kB
Burada yalnızca MemFree değerine bakıp “RAM bitmiş” demek yanlış olur. Linux boş RAM'i cache için kullanır ve gerektiğinde bunun bir kısmını geri alabilir.
Daha ilginç değer SUnreclaim. Yaklaşık 14 MB kullanılabilir belleğin 4.3 MB kadarı reclaim edilemeyen slab durumunda.
Bu tek başına memory leak kanıtı değil.
Fakat cihaz haftalar boyunca çalışırken örneğin 4.3 MB → 5 MB → 6 MB → 8 MB şeklinde sürekli yükselen bir değer görürsek kernel veya driver tarafındaki bir sızıntı ciddi şüpheli haline gelir.
Ethernet ve Wi-Fi Sayaçları
Arıza Ethernet switch/PHY veya Wi-Fi sürücüsü tarafında da olabilir. Bunun için interface sayaçlarını da baseline olarak kaydettim.
eth2:
RX errors 0
TX errors 0
carrier 0
collisions 0
ra0:
RX errors 98
TX errors 0
Daha sonraki ölçümde Wi-Fi RX error sayısı 98'den 101'e çıktı. 2.4 GHz ortamında bu seviyedeki birkaç hata tek başına anlamlı değil.
Fakat cihaz kilitlenmeden hemen önce bu sayaç hızla yükselmeye başlarsa başka bir ipucu elde etmiş olacağız.
Kernel tarafında da özellikle şu Ralink thread'leri çalışıyor:
[RtmpCmdQTask]
[RtmpWscTask]
[RtmpMlmeTask]
Bunlar ileride Wi-Fi sürücüsü kilitlenmesi ihtimalini araştırırken işimize yarayabilir.
Asıl İş: RP-N12'ye Kara Kutu Takmak
Web arayüzünde Remote Log Server diye bir alan bulunuyor.
Plan basit:
RP-N12
192.168.1.100
|
| UDP / 514
v
Windows PC
192.168.1.108
|
v
C:\Temp\rp-n12-syslog.log
RP-N12'nin kendi syslogd prosesine baktığımda remote logging parametresinin gerçekten kullanıldığını gördüm.
/sbin/syslogd -m 0 -t GMT-3 -O /tmp/syslog.log -R 192...
ps terminal genişliği nedeniyle satırı kesiyordu. Bunun üzerine prosesin gerçek command line'ını doğrudan /proc üzerinden okudum:
# cat /proc/4924/cmdline
/sbin/syslogd-m0-tGMT-3-O/tmp/syslog.log-R192.168.1.108-L
NUL karakterleri ekranda görünmediği için argümanlar birleşik görünüyor. Gerçek yapı kabaca şöyle:
/sbin/syslogd
-m 0
-t GMT-3
-O /tmp/syslog.log
-R 192.168.1.108
-L
syslogd hedefinin 192.168.1.108 olduğu /proc üzerinden doğrulandı; hemen ardından kara kutu test mesajı gönderildi.Ufak Bir Troubleshooting Klasiği: Yanlış IP
İlk denemede Windows tarafındaki collector çalışıyor fakat RP-N12'den hiçbir paket gelmiyordu.
UDP/514 için firewall kuralı açıldı. Python listener'ın gerçekten portu dinlediği doğrulandı. Hatta localhost üzerinden gönderilen test mesajı başarıyla kaydedildi:
2026-09-18 00:56:17.096 [127.0.0.1] LOCAL SYSLOG TEST
BusyBox üzerinde doğrudan UDP paketi göndermek için nc kullanmayı düşündüm.
# nc
-sh: nc: not found
# busybox nc
nc: applet not found
İş artık Wireshark ile paketin kabloya çıkıp çıkmadığını kontrol etme noktasına gelmişti.
Sonra çok daha temel bir şey ortaya çıktı.
Windows PC'nin IP adresi 192.168.1.109 değil, 192.168.1.108 idi.
Syslog paketlerini gayet düzgün şekilde yanlış bilgisayara gönderiyorduk.
Remote Log Server adresini 192.168.1.108 olarak değiştirince bütün problem bir anda ortadan kalktı.
BLACK BOX ONLINE
RP-N12 üzerinde:
# logger "RP-N12 BLACK BOX ONLINE"
Windows tarafında ise:
2026-09-18 01:05:04.149 [192.168.1.100]
<13>kadir: RP-N12 BLACK BOX ONLINE
Artık RP-N12 kendi loglarını kendi RAM/flash alanında tutmakla kalmıyor; olayları gerçekleştiği anda başka bir bilgisayara gönderiyor.
Bir başka avantaj da PC'deki Python collector'ın her paketin başına Windows sistem saatini eklemesi. RP-N12'nin NTP'si tekrar bozulsa veya saati 2011'e dönse bile gerçek olay zamanını kaybetmeyeceğim.
Windows Tarafındaki Collector
İşin PC tarafında çok küçük bir Python programı yeterli:
import socket
from datetime import datetime
PORT = 514
LOG = r"C:\Temp\rp-n12-syslog.log"
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("0.0.0.0", PORT))
print(f"RP-N12 syslog bekleniyor UDP/{PORT}")
with open(LOG, "a", encoding="utf-8", buffering=1) as f:
while True:
data, addr = sock.recvfrom(65535)
now = datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f")[:-3]
msg = data.decode("utf-8", errors="replace").rstrip()
line = f"{now} [{addr[0]}] {msg}"
print(line)
f.write(line + "\n")
Program UDP/514'ü dinliyor, gelen paketin kaynak IP'sini ve PC'nin timestamp'ini ekleyip şu dosyaya yazıyor:
C:\Temp\rp-n12-syslog.log
Fakat burada yeni bir problem var. RP-N12 bazen haftalarca kilitlenmiyor. Her Windows açılışında gidip Python scriptini elle çalıştırmak anlamsız.
Task Scheduler ile Sessiz Autostart
Scripti kalıcı olarak:
C:\Scripts\rp-n12-syslog.py
altına taşıdım.
Windows Startup klasörüne normal bir kısayol atmak mümkün fakat bu yöntem hem daha hantal hem de konsol penceresinin görünmesine neden olabiliyor.
Bunun yerine Windows Task Scheduler kullandım.
Task adı:
RP-N12 Syslog Logger
Trigger:
At log on of WIN11\hicbi
Action:
Program/script:
C:\Python313\pythonw.exe
Add arguments:
"C:\Scripts\rp-n12-syslog.py"
Start in:
C:\Scripts
Burada python.exe yerine özellikle pythonw.exe kullanıyorum. Böylece login sırasında CMD/terminal penceresi açılmıyor; collector tamamen görünmez şekilde arka planda çalışıyor.
Task'ın üç gün sonra otomatik sonlandırılmasına neden olan varsayılan Stop the task if it runs longer than: 3 days seçeneğini de kapattım.
Ayrıca:
If the task fails:
Restart every 1 minute
Attempt to restart up to 3 times
If the task is already running:
Do not start a new instance
ayarlarını kullandım.
Gerçekten Arka Planda mı?
Task'ı elle başlattıktan sonra portu kontrol ettim:
C:\>netstat -ano | findstr "0.0.0.0:514 "
UDP 0.0.0.0:514 *:* 25904
PID'yi sorgulayınca:
C:\>tasklist /FI "PID eq 25904"
Image Name PID
=========== =======
pythonw.exe 25904
Yani görünürde hiçbir pencere olmamasına rağmen Python collector gerçekten UDP/514'ü dinliyordu.
Son uçtan uca test:
# logger "RP-N12 AUTOSTART TEST OK"
Ve log dosyası:
2026-09-18 01:19:02.442 [192.168.1.100]
<13>kadir: RP-N12 AUTOSTART TEST OK
pythonw.exe collector, AUTOSTART TEST OK mesajını ve hemen sonrasındaki klogd/syslogd restartını kaydetti.Syslog Servisinin Restart'ını Bile Yakaladık
Bir ayar değişikliğinden sonra RP-N12 kendi logging servislerini yeniden başlattı. Kara kutu bunu da kaydetti:
2026-09-18 01:20:35.116 [192.168.1.100]
<13>kernel: klogd: exiting
2026-09-18 01:20:35.127 [192.168.1.100]
<46>System log daemon exiting.
2026-09-18 01:20:35.158 [192.168.1.100]
<13>kernel: klogd started: BusyBox v1.12.1
Bu da mekanizmanın istediğimiz şekilde çalıştığını gösteriyor. RP-N12'nin kendi syslog altyapısının kapanıp yeniden açılması bile dışarıdaki logda kalıyor.
Şimdi Ne Bekliyoruz?
Artık yapılacak en doğru şey aslında hiçbir şey yapmamak.
RP-N12 normal access point görevine devam edecek. Windows PC günde uzun süre açık olduğundan Task Scheduler collector'ı otomatik olarak başlatacak ve cihazın gönderdiği mesajlar:
C:\Temp\rp-n12-syslog.log
dosyasında birikecek.
Bir sonraki kilitlenmede hemen reboot etmek yerine önce şu ayrımı yapacağım:
192.168.1.1 → ana router ping?
192.168.1.100 → RP-N12 ping?
Wi-Fi → çalışıyor mu?
Telnet → cevap veriyor mu?
Syslog → son mesaj ne?
Eğer RP-N12 ping'e cevap vermezken ana router cevap veriyorsa cihazın kendisi veya Ethernet tarafı kilitlenmiş olabilir.
İkisi birden kaybolursa RP-N12'nin Layer-2 ağı bozduğu ihtimali yeniden gündeme gelecek.
Her iki IP de cevap verirken yalnız Wi-Fi ölürse Ralink radio/driver tarafı çok daha kuvvetli bir şüpheli olacak.
Logda özellikle şu kelimeleri arayacağım:
watchdog
kernel panic
Oops
Call Trace
Out of memory
oom
Killed process
alloc
ra0
raeth
RT305x_ESW
link
reset
deauth
disassoc
Ya Cihaz Tamamen Hard-Lock Olursa?
Remote syslog'un doğal bir sınırı var.
Kernel veya SoC tamamen kilitlenirse son log mesajını gönderecek CPU zamanı bile kalmayabilir. Bu durumda dosya muhtemelen şöyle bitecek:
normal mesaj
normal mesaj
normal mesaj
son mesaj
...
ve ardından sessizlik.
Bu da aslında bilgi.
Fakat nedenini görmek için bir sonraki aşama cihazın PCB'sindeki UART hattını bulmak olacak. 3.3 V TTL seviyesinde TX/RX/GND üzerinden boot ve kernel konsoluna ulaşabilirsem Ethernet ve Wi-Fi çöktüğünde bile cihazın içeride ne yaptığını görebilirim.
UART da aynı anda tamamen susuyorsa güç, watchdog, kernel deadlock veya SoC seviyesinde hard-lock ihtimalleri daha ciddi hale gelir.
JTAG ise şimdilik gereksiz derecede ağır top.
Sonuç: Arızayı Gözlemlenebilir Hale Getirdik
Şu anda RP-N12'nin neden kilitlendiğini hâlâ bilmiyorum.
Memory leak olduğuna dair kanıt yok. Ethernet sayaçları temiz. Wi-Fi hata sayıları olağan seviyede. Cihaz bazen haftalarca problemsiz çalışabildiği için masanın başında bekleyerek arızayı yakalamak da gerçekçi değil.
Fakat başlangıçtaki durumla şimdiki durum arasında önemli bir fark var.
Başlangıçta cihaz kilitlendiğinde elimizde yalnızca:
"Wi-Fi yine gitti."
bilgisi vardı.
Şimdi ise RP-N12 kendi kernel ve sistem mesajlarını gerçek zamanlı olarak başka bir makineye gönderiyor; Windows bunlara bağımsız timestamp ekliyor ve disk üzerinde kalıcı olarak saklıyor.
Başka bir deyişle problemi henüz çözmedik.
Ama artık RP-N12 suç işlerse olay yerinde kara kutu var.
ASUS RP-N12 · BusyBox · Ralink · embedded Linux · syslog · remote syslog · UDP 514 · Task Scheduler · Python · access point · network troubleshooting
