1 Temat przez kolszak (edytowany przez kolszak 2015-01-02 10:22:04)

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Temat: ARP - prośba o sprawdzenie

Czy ktoś mógłby mi potwierdzić jak zachowuje się tablica ARPów. Na takim schemacie (pewnie ktoś też ma taką topologię).

Server Ubuntu 14.04 eth1 -> do niego przez switcha TPILINKA -> Gargoyle(842ND v2) sztuk 5, każdy ma swój adres.

Adresacja na eth1 192.168.20.1/24 (ap dowolnie z tej klasy).

Do AP mam podłączone urządzenia po WiFi, zuważyłem ze bardzo długo trwa rozwiązywanie ARP, mianowicie. Wychodzący pakiet ICMP zaczyna się odpowiedź od 6 requesta, w tym czasie widać na tcpdumpie ze serwer chce rozwiązać ARP, bo w tablicy ma już info o przeterminowanym wpisie.

Długo to trwa, zaczyna mi pomijać niektóre zadania do drukarki bo już w cups widze, że drukarka była niedostępna.
Pierwsze co to wywale tego switcha tplinka, ale może ktoś ma jakieś inne pomysły.
Statyczne ARP'y zostawiam na koniec.

Oczywiście gargoyle działają jako bridge smile

--
KO

kolszak's Strona

2 Odpowiedź przez kolszak (edytowany przez kolszak 2014-11-18 15:45:19)

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Jeszcze raz, prośba o zerknięcie, może Cezary mi coś podpowiesz.

Mamy taki przykład

Wycinek tablicy ARP

karol@polimer:~$ ip -s nei sh
fe80::788b:5320:6399:6727 dev eth0 lladdr 00:1e:33:d1:44:ad router used 112980/113040/1850 probes 0 STALE
192.168.20.152 dev eth1 lladdr 00:80:92:ce:0c:a3 used 63/57/13 probes 1 STALE
192.168.20.153 dev eth1 lladdr 00:80:92:c3:1e:18 used 91/89/45 probes 1 STALE

Test ICMP do 192.168.20.152

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:22:22.728754 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 1, length 64
15:22:23.735704 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 2, length 64
15:22:24.743697 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 3, length 64
15:22:25.751698 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 4, length 64
15:22:26.759695 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 5, length 64
15:22:27.737617 ARP, Request who-has 192.168.20.152 tell 192.168.20.1, length 28
15:22:27.742804 ARP, Reply 192.168.20.152 is-at 00:80:92:ce:0c:a3 (oui Unknown), length 46
15:22:27.767696 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 6, length 64
15:22:27.770796 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 15911, seq 6, length 64
15:22:28.768405 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 7, length 64
15:22:28.770897 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 15911, seq 7, length 64
15:22:29.769963 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 8, length 64
15:22:29.772895 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 15911, seq 8, length 64
15:22:30.771958 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 15911, seq 9, length 64
15:22:30.774907 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 15911, seq 9, length 64

Topologia:
http://s30.postimg.org/8dqfdyp8t/topologia.jpg

Ogólnie od strony karty ETH1 mam problem niby wpis w tablicy ARP istnieje, ICMP wysyłam np. na AP z gargoylem ale Pierwsze kilka pakietów (przez 5 sekund tak jest w kernelu ustawiony parametr do wysłania ARP requesta) idzie w kosmos zgodnie z tcpdumpem.
Potem gdy wyjdzie (patrz tcpdum) ARP request nagle wszystko zaczyna działać. Dotyczy to gargoyle jak i drukarek za nimi (WIFI).
Switcha wymieniłem. Ustawienia ARPów na serwerze mam takie same na obie karty i tylko w stronę routerów z gargoylem to występuje.
Oczywiście gargoyle działa jako głupi switch wifi, serwer DHCP jest na serwerze stąd mam roaming. Tylko ten dziwny problem. No kończą mi się pomysły.
Żadnych strat pakietów problemów wskazujących na okablowanie nie widzę. Bo jak już komunikacja ruszy to idealnie. Do czasu kiedy urządzenia przestaną wysyłać dane, wtedy kolejne wzbudzenie trwa właśnie tyle czasu.

Na tą chwilę rozwiązałem problem ominięciem (w sreenie idzie icmp na drukarkę co 2 sekudny), bo miałem problem, gdy po dłuższym nie używaniu szło zadanie wydruku i CUPS odrzucał je z racji niedostępności drukarki.

--
KO

kolszak's Strona

3 Odpowiedź przez build000 (edytowany przez build000 2014-11-18 17:00:43)

  • Zarejestrowany: 2013-06-25
  • Posty: 2,058

Odp: ARP - prośba o sprawdzenie

Mimo wszystko mi się wydaje, że nadal użyty switch źle kuma z gargoyle/openwrt - nie pytaj mnie na jaki zamienić i jak go ustawić - od tego znajdziesz tu lepsiejszych fachmanów wink I chyba musisz pomajstrować z DHCP na serwerze.

4 Odpowiedź przez m80 (edytowany przez m80 2014-11-18 17:13:22)

  • m80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2013-04-27
  • Posty: 269

Odp: ARP - prośba o sprawdzenie

Cześć
1. Na Ubuntu masz uruchomiony serwer DHCP czy wszystkie adresy na sztywno?
2. Wszystkie AP-ki masz podpięte przez porty LAN do switcha?
3. Na wszystkich AP-ekach masz wyłączony firewall, dhcp?
4. Kanały na AP-ekach nie kolidują ze sobą?
5. AP-ki (192.168.20.12 i 192.168.20.13) masz połączone jak na obrazku? szeregowo przez porty LAN?

5 Odpowiedź przez kolszak (edytowany przez kolszak 2014-11-18 17:15:10)

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

A co niby mam zmieniać przy DHCP, to nie ma tutaj nic do rzeczy, ma się świetnie. Problem tkwi zupełnie gdzie indziej. Ten switch który jest teraz wcześniej był przetestowany w środowisku "odtworzeniowym" i działał dobrze a tu się okazuje że na miejscu to samo co na starym switchu.

--
KO

kolszak's Strona

6 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Do m80 tak jak na obrazku. Ogólnie odstawcie WiFi, bo problem da się odtworzyć dokładnie na adresach które mają przypisane AP, czyli na kablu. Nie trzeba do tego wcale urządzenia na bezprzewodówce. To samo co uzyskałem z drukarką WiFi uzyskam z adresem IP który ma przypisany AP.

--
KO

kolszak's Strona

7 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Drukarki sobie działaja po WiFi, ale tak jak pisze to samo odtworze na IP przypisanych na AP połączonych kablem tak jak na rysunku. Firewalle były wyłączane na Gargoylu ale to nic nie zmieniło.

--
KO

kolszak's Strona

8 Odpowiedź przez m80

  • m80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2013-04-27
  • Posty: 269

Odp: ARP - prośba o sprawdzenie

A Gargulca jaką wersję masz na AP?

9 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Gargoyle PL 1.6.2.2 (b70bfc1)
To jest na 842ND

--
KO

kolszak's Strona

10 Odpowiedź przez m80

  • m80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2013-04-27
  • Posty: 269

Odp: ARP - prośba o sprawdzenie

I wszystkie AP masz podłączone do switcha przez porty LAN a nie WAN?
Co to za switch? Zarządzalny?

11 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Nie switch teraz nie jest zarządzalny to 100 Edimaxa, wczesniej byl Tplink. Podłączane mam różnie bo wszystkie i tak mają w jednym VLANie porty (AP). Poprostu na każdym dopisany WAN jest do LANu.
Ze switcha tablicy ARPów nie odczytam jeśli o to chodzi. Ale przy moim mega wku.. to moge go podmienic na junipera srx100 choc to przerost formy nad trescia dla tego zastosowania.
Jedyne co rozni srodowisko testowe na ktorym Edimax dzialal to kabel tj. typ,producent,dlugosc Ale to sie kupy nie trzyma by kabel tak w trabe walil jak juz arp jest to dziala bezstratnie.

--
KO

kolszak's Strona

12 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Może kluczem jest ARP nat, ale nie mogę nic znaleźć na ten temat dla mojej konfiguracji (nie jest to wifi bridge) jak tak sobie słucham na interfejsie tcpdumpem to nie widze by wogóle coś tam się nie działo.

--
KO

kolszak's Strona

13 Odpowiedź przez m80

  • m80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2013-04-27
  • Posty: 269

Odp: ARP - prośba o sprawdzenie

Może problem leży po stronie serwera...
nie masz jakiś wpisów w /etc/ethers?
ustawionych jumbo frames?
Licznik kolizji jest zerowy na interfejsie podłączonym do switcha?

14 Odpowiedź przez kolszak (edytowany przez kolszak 2014-11-18 18:30:09)

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Tak zadnych kolizji nic, ten serwer ma dwie karty sieciowe mial te same ustawienia na obu, i na tej drugiej wszystko gra. Ale też się skłaniam ku serwerowi, choć jeszcze brak ARPów na tcpdumpie na tej karcie w strone AP mnie martwi.

Nie no coś tam jednak leci jeśli chodzi o ARP'y. Popatrze sobie na AP 192.168.20.11 Do niego nic nie jest podłączone. Jestem ciekaw co jest problemem...

Cały problem powstaje gdy urządzenie (nie ważne AP czy drukarka) jest nieużywane tj. nie ma do niej ani z niej żadnego ruchu. Przykład:

18:13:23.847153 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17790, seq 1, length 64
18:13:24.845620 ARP, Request who-has 192.168.20.152 tell 192.168.20.1, length 28
18:13:24.847236 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17790, seq 2, length 64
18:13:24.850324 ARP, Reply 192.168.20.152 is-at 00:80:92:ce:0c:a3 (oui Unknown), length 46
18:13:25.855701 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17790, seq 3, length 64
18:13:25.858943 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 17790, seq 3, length 64
18:13:26.857031 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17790, seq 4, length 64
18:13:26.859342 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 17790, seq 4, length 64
18:16:31.796362 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17808, seq 1, length 64
18:16:31.799730 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 17808, seq 1, length 64
18:16:32.793612 ARP, Request who-has 192.168.20.152 tell 192.168.20.1, length 28
18:16:32.796169 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17808, seq 2, length 64
18:16:32.797760 ARP, Reply 192.168.20.152 is-at 00:80:92:ce:0c:a3 (oui Unknown), length 46
18:16:32.799697 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 17808, seq 2, length 64
18:16:33.797764 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17808, seq 3, length 64
18:16:33.800743 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 17808, seq 3, length 64
18:27:02.500573 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17851, seq 1, length 64
18:27:03.497613 ARP, Request who-has 192.168.20.152 tell 192.168.20.1, length 28
18:27:03.500796 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17851, seq 2, length 64
18:27:03.502802 ARP, Reply 192.168.20.152 is-at 00:80:92:ce:0c:a3 (oui Unknown), length 46
18:27:04.507695 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17851, seq 3, length 64
18:27:04.510601 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 17851, seq 3, length 64
18:27:05.509677 IP 192.168.20.1 > 192.168.20.152: ICMP echo request, id 17851, seq 4, length 64
18:27:05.514317 IP 192.168.20.152 > 192.168.20.1: ICMP echo reply, id 17851, seq 4, length 64

O 18:16 wysłałem ostatni pakiet icmp na drukarkę, potem po 10 minutach wysłałem ICMP znowu i problem się ponowił (aktualnie mam zmodyfikowany na tej karcie sieciowej delay_first_probe_time na 1), wiec zwłoka czasowa jest mniejsza niż przy domyślnych 5 sekundach.

--
KO

kolszak's Strona

15 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Pytanie - Cezary.
Może to jest klucz problemu.
AP - 842ND v.2 w ilości sztuk 5 są rozprowadzone po budynku/placu. Na nich mam soft od Ciebie ale AA. http://dl.eko.one.pl/gargoyle-pl/attitu … actory.bin

Na Wiki OpenWrt
http://wiki.openwrt.org/toh/tp-link/tl-wr842nd
Piszą, że ta wersja HW jest wspierana dopiero od OpenWRT BB.
Na oficjalnych repozytoriach BB leży wersja dla 842ND v2.
Na oficjalnych repozytoriach AA NIE MA wersji dla 842ND v2.

Co to za wersja GargolePL dla 824ND rewizji 2.

Powiem tak, podstawiłem WA500G na sofcie TPLINKA, problem z ARPami nie występuje.
Zastanawiam się czy to kwestia GargoylePL. Biorę pod uwagę update do BB, tylko raczej jak się pojawię tam na miejscu.
Pzdr
KO

--
KO

kolszak's Strona

16 Odpowiedź przez Cezary

  • Skąd: Warszawa
  • Zarejestrowany: 2006-02-25
  • Posty: 115,872

Odp: ARP - prośba o sprawdzenie

Normalna, zwykła dla 842v2. To że nie ma AA dla 842v2 wcale nie znaczy że ja jej nie mam. Przecież m.in z tego powodu używasz moich obrazów że mają wsparcie dla routerów i rzeczy których nie ma normalnie w wydaniach oficjalnych, prawda?

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

Cezary's Strona

17 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Przy najbliższej okazji podmienie jedną sztukę v2 na v1.1, na której cały czas robiłem testy i było 100% OK.

--
KO

kolszak's Strona

18 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Na jednym z AP cofnąłem soft do ROM'u oryginalnego 3.12 bodajże dla 842ND v2.
Oczywiście nie mogę odtworzyć problemu. Działa dobrze. Musi być jakiś błąd w gargoyle 1.6.2, tylko mi się pomysły na jego znalezienie skończyły.
Jeśli ktoś ma wolną sztukę 842ND v2 i chce mu się odtworzyć problem to wystarczy:

1) Ustawić w tryb router (standardowo)
2) Wyłączyć serwer DHCP
3) Nadać adresację ręcznie dla AP
4) Skonfigurować wifi

Ja mam dodatkowo
5) serwer NTP ustawiony
6) wszystkie porty w jednym VLANIE wraz z portem WAN.

Po pewnym czasie pingując AP z hosta podłaczonego do niego kablem gdy nie jest generowany żadny ruch, nastąpi lag do czasu wysłania zapytania ARP.

--
KO

kolszak's Strona

19 Odpowiedź przez kolszak

  • Skąd: CT
  • Zarejestrowany: 2012-12-09
  • Posty: 55

Odp: ARP - prośba o sprawdzenie

Skończyło się na tym, że od wczoraj wszystkie 5 AP chodzi na firmwarze stockowym i nie ma problemu..
Trochę szkoda bo zawsze o wiele więcej danych wycisnę z gargoyla.
Gdy wpadnie mi w ręce 842ND v2 to będę testował dogłębnie, póki co na produkcyjnych sprzętach nie będe juz experymentował.

--
KO

kolszak's Strona