Kablosuz arp-d kadar 192.168.1.1

Telsizim yarım saat veya daha uzun bir süre bağlandıktan birkaç dakika sonra başarısız oluyor.

belirtiler :

• yeni sayfalar açılmıyor
• indirme işlemi devam ediyor
• ping 8.8.8.8 çalışmıyor

"Düzeltme" kolaydır (rastgele bir süre sürer):

$ sudo arp -d 192.168.1.1

Bu çözüm hiçbir anlam ifade etmiyor, çünkü kontrol ettim ve ARP zehiri değil.

Bunun neden olduğu hakkında bir fikrin var mı?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=53.4 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 53.425/54.358/55.282/0.923 ms

Kablosuz Yönlendirici: ZonHub 1.0 (ISS'im tarafından sağlanan özelleştirilmiş Jungo'nun OpenRG'si olan Hitron BVW3653 Kurulu)

$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::21c:bfff:fe2a:9b6/64 scope link 
       valid_lft forever preferred_lft forever
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms
$ sudo arp -an 
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0
$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.8 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=79.8 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 53.544/62.396/79.815/12.317 ms
$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::21c:bfff:fe2a:9b6/64 scope link 
       valid_lft forever preferred_lft forever
$ sudo arp -an 
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0

Dediğim gibi, ARP zehiri değil.

NOT 1: Her şey ISS tarafından kilitlendiğinden, yönlendiricimdeki bir web sayfasına yalnızca erişebiliyorum.

Bu cevap tamamen tahminde bulunacak, aslında sebep olup olmadığını bilmiyorum ama ...

Yönelticiyi ARP tablonuzdan sildiğinizde, bilgisayarınız bir sonraki yönlendiriciye herhangi bir paket göndermek istediğinde bir ARP paketi göndermek zorunda kalır. Bu ARP paketinin yönlendiricinin ARP tablosunda kırılanları düzelttiğini tahmin ediyorum, çünkü bilgisayarınızın ARP tablosunu gönderdiğiniz örnekte iyi görünüyor ("düzeltmeden" önce ve sonra aynı).

Yönelticinin ARP tablosunun, ona bakabildiniz, bilgisayarınızın MAC adresi yerine "(eksik)" göstereceğini tahmin ediyorum (nasıl göründüğüne ilişkin bir örnek için varolmayan bir LAN adresini pinglemeyi deneyin). Bu ARP girişinin süresi dolduğunda, bir ARP paketi yayınlarsa ve bu yayın paketi hiçbir zaman bilgisayarınıza (ya da yanıt paketi yönlendiriciye asla ulaşmadı) ulaşmazsa bu duruma ulaşırdı. ARP paketiniz girişi tamamlar ve bilgisayarınıza tekrar IPv4 paketleri gönderebilir.

Şimdi, bu neden olur? İki olası neden düşünebilirim. Yönlendiricideki veya bilgisayarınızdaki yanlış yapılandırılmış bir güvenlik duvarı (bunun olası olmadığını düşünüyorum) veya kablosuz yönlendiriciden gelen yayınla ilgili bir sorun var.

802.11 standardındaki yayın paketleri biraz problemlidir. İlgili tüm istasyonlara yönlendirildiklerinden:

• Onaylanmadıkları için AP alınıp alınmadığını bilemez. Bu, tek bir yanlış yerleştirilmiş statik patlamanın bir yayın paketini öldürebileceği anlamına gelir.
• Tüm istasyonların duyabileceği bir oranda gönderilmeleri gerekir. AP, hız kontrolü algoritmaları tarafından bulunan en iyi oranı kullanamaz. Bu genellikle BSS'nin temel oranlarından çok daha düşük bir oran anlamına gelir. Bu daha fazla çalışma süresi kullanır, ancak önceki soruna yardımcı olur (düşük oranlar genellikle biraz daha sağlamdır).
• Aynı paket ilgili tüm istasyonlar tarafından çözülebilmesi gerektiğinden, istasyonun ayrı anahtarı ile şifrelenemezler. Bunun yerine, tüm ilgili istasyonların bildiği ayrı bir grup anahtarıyla şifrelenmeleri gerekir. Bu grup anahtarı periyodik olarak döndürülür (aksi halde ağı terk eden istasyonlar hala yayın paketlerinin kodunu çözebilir).

Bu son noktayla ilgili şahsen gizemli başarısızlıklara şahit oldum. Bir kez yapılandırdığım bir erişim noktası devre dışı bırakılmış grup anahtar aralığı ile geldi. “Bu aptalca” diye düşündüm, “neden bu güvenlik özelliğini devre dışı bırakırlar?” Ve bir saat olarak ayarladılar. Bir süre sonra doğru taraftan ping yaparak çözülebilecek aralıklı kablosuz bağlantı sorunlarını düzelttikten sonra (eğer kablolu ya da kablosuz taraftan olsaydım artık hatırlamıyorum - güvenlik duvarına ssh erişimim vardı ve bunun bir ARP olduğunu hatırladım.) sorun), "Ah, bu varsayılan olarak devre dışı bırakılmasının nedeni bu, erişim noktası donanım yazılımı üzerinde muhtemelen hata var ve son dakika düzeltmesi olarak sıfıra ayarladılar" diye bir fikrim vardı. varsayılan ve sorun kayboldu.

Bu senin sorunun mu hiç bilmiyorum; üretici tamamen farklıdır ve muhtemelen böyle bir ezoterik ayara dokunmadınız.

Deneyebileceğiniz bir sonraki şey, sorun olduğunda, hangi paketlerin değiştirildiğini görmek için bir keskin nişancı çalıştırmak olacaktır. İkinci bir bilgisayarınız varsa, yönlendiricinin ethernet LAN bağlantı noktalarına takıp aynı zamanda bir de sniffer çalıştırabilirsiniz (LAN üzerinde görünen bir ARP yayını hipotezimin ağda göründüğünü ancak kablosuz üzerinde bir değeri olmadığını görmek için) ).

Ve hipotezim doğruysa indirmelerin nasıl devam edeceği hakkında hiçbir fikrim yok. Belki de bir şekilde MAC adresini TCP bağlantı durumunda önbelleğe alır?