1

(2 odpowiedzi, napisanych Oprogramowanie / Software)

Może coś wieczorem uda mi się złapać, na razie jestem pewien, że to jest przyczyną. Wcześniej myślałem, że to wina network-managerea.

Zauważyłem taki problem.
Mam lede 17.01-SNAPSHOT, r3566-98c003e.

Mam natywne ipv6 na WAN. Z lede do sieci lokalnej działa mi przekazwyanie prefixu do wewnątrz. Jednak lede daje adresy z preffered-lifetime 0.

Oto zrzut z hosta w lan, jego pliku dzierżaw dla dhclient6

  iaaddr fde3:a387:7e44::110 {
      starts 1515444789;
      preferred-life 4294967295;
      max-life 4294967295;
    }
    iaaddr 2a02:e88:c4:fff0::c7e {
      starts 1515444789;
      preferred-life 0;
      max-life 0;
    }
    iaaddr fde3:a387:7e44::c7e {
      starts 1515444789;
      preferred-life 0;
      max-life 0;
    }

To jest chyba problem podstawowy, potem na laptopie w pracy, pozostawia mi te adresy i wybiera niższy adres do wysyłania pakietów a oczywiście z pracy tych sieci nie mam dostępnych (mowa tu głównie o network-managerze na linuxie), na windowsie wydaje się, że nie stosuje się do preffered-life 0; i nie trzyma go w nieskończoność.

Oczywiście na WAN podaje poprawne te paramery, co w LEDE może przekształcać te czasy, kiedyś był radadv, teraz obsługa jest natywna, nie mogę się doszukać. dnsmasq?

--
Zmieniłem jeszcze ra_useleasetime w dhcp configu. Zobacze czy to przyniesie jakieś efekty

To działało tylko zza ich liveboxów i to w v2 jeśli dobrze pamiętam. Na GPONie może być zupełnie inaczej. Najlepiej było by podpytać na infolinii. Rozumiem, że masz jakiegoś ONT w tej technologii w domu.

4

(3 odpowiedzi, napisanych Oprogramowanie / Software)

Ok. Widze ze zmienili podejscie. A LEDE tez tak kompiluja? Czy zostaje mi samemu budowac obraz ze zrodel?

5

(3 odpowiedzi, napisanych Oprogramowanie / Software)

Witam,
Czy ta wersja 1.9.1.1 (r49398), by obsy, jest niekompatybilna z v6?
Chce dociągnąc moduły do jądra i są błędy niezgodności wersji.

Installing kmod-ipv6 (3.18.23-1) to root...
Downloading http://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/packages/base/kmod-ipv6_3.18.23-1_ar71xx.ipk.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-ipv6:
 *      kernel (= 3.18.23-1-b2f200610f46d20ef52d269421369d0c) * 
 * opkg_install_cmd: Cannot install package kmod-ipv6

Zaktualizowałem z 1.6.2.2 dziś się do gałęzi 1.9 ale rozumiem, że musiałbym przesiąść się na oryginalnego by mi ipv6 zadziałało?
Pozdrawiam
KO

Tak możesz tak zrobić.

1) Dać adres IP z innej podsieci na rejestrator (np. 192.168.0.2/24)
2) Dać adresy IP na kamery z sieci (192.168.1.x/24)
3) Domyślny routing ustawić na gargolya i nadać mu subinterfesy 192.168.1.1 oraz 192.168.0.1.

kombinować z ebetables/iptables,
ruch przychodzący z kamery IP np. 192.168.1.9 port 8000 na 192.168.0.2 port 8001

Ale dalej wydaje mi się, żę błąd tkwi w konfiguracji rejestartora.
Ewentualnie kontakt ze sprzedawcą, dostęp do FTP'a i pewnie sie znajdzie nowy soft. Mało prawdopodobne by wyszło to z taki błędem i nikt do tej pory tego nie poprawił.

A można tam dodać kamerę ręcznie w tym rejestratorze? Bo jak rozdzielisz sieci to rejestrator nie znajdzie Ci żadnej kamery i takie kombinacje w gruncie rzeczy stają sie nic nie warte.

Chyba złe rozumowanie. W końcu każdy na wp.pl wchodzi na port 80 i nie ma z tym problemu.

Kamery mogą mieć ten sam port dla protokołu ONVIF, tak jak piszesz ale to nie oznacza, że tam pójdzie strumień protokołu RTP. Wydaje mi się, że to rejestrator będzię się łączył z kamerą i pobierał strumień, nie odwrotnie.
Przy chińskim wynalazku wireshark i słuchaj ruchu, coś na pewno wyjdzie.

Przekierowanie "lokalne" tak jak piszesz w tym wypadku nie ma miejsca, sprzęt robi jako switch to wszystko w jednej sieci siedzi.

8

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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ł.

9

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

10

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

11

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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

12

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

13

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

14

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

15

(18 odpowiedzi, napisanych Oprogramowanie / Software)

Gargoyle PL 1.6.2.2 (b70bfc1)
To jest na 842ND

16

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

17

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

18

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

19

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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.

20

(18 odpowiedzi, napisanych Oprogramowanie / Software)

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

Witam,
Czy jest coś takiego jak w temacie, czyli softowy kontroler dla klientów WiFi. Tak sobie pomyślałem by rozeznać temat, bo póki co używam roamingu na zasadzie różnych kanałów i trybów bridge gargoyle, ale może by to jeszcze rozszerzyć o coś więcej.
KO

22

(109 odpowiedzi, napisanych Oprogramowanie / Software)

A jednak ntpd z busyboxa nad czymś nie nadąża.

Zrobiłem kilka AP w sieci i czas synchronizuje od siebie z serwera lokalnego i wyjątkowo własnie ntpd z gargoyle ma problem z moją wersją (ntpd z ubuntu srv 14.04). Przy czym zastrzegam, że wszystkie inne urządzenia synchronizują czas bezbłędnie wink

192.168.20.12.50699 > 192.168.20.1.ntp: [udp sum ok] NTPv4, length 48
        Client, Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   230606609.289603441 (2043/05/30 09:51:45)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 230606609.289603441 (2043/05/30 09:51:45)
18:20:54.635547 IP (tos 0xc0, ttl 64, id 3430, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.20.1.ntp > 192.168.20.12.50699: [udp sum ok] NTPv4, length 48
        Server, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 3 (8s), precision -22
        Root Delay: 0.000000, Root dispersion: 0.037078, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 230606609.289603441 (2043/05/30 09:51:45)
          Receive Timestamp:    3622465254.635501682 (2014/10/16 18:20:54)
          Transmit Timestamp:   3622465254.635536789 (2014/10/16 18:20:54)
            Originator - Receive Timestamp:  -903108650.654101729
            Originator - Transmit Timestamp: -903108650.654066622
18:20:54.680537 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.20.10.34776 > 192.168.20.1.ntp: [udp sum ok] NTPv4, length 48
        Client, Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   480036299.298352360 (2051/04/25 07:53:15)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 480036299.298352360 (2051/04/25 07:53:15)
18:20:54.680578 IP (tos 0xc0, ttl 64, id 10653, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.20.1.ntp > 192.168.20.10.34776: [udp sum ok] NTPv4, length 48
        Server, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 3 (8s), precision -22
        Root Delay: 0.000000, Root dispersion: 0.037078, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 480036299.298352360 (2051/04/25 07:53:15)
          Receive Timestamp:    3622465254.680537402 (2014/10/16 18:20:54)
          Transmit Timestamp:   3622465254.680569350 (2014/10/16 18:20:54)
            Originator - Receive Timestamp:  -1152538340.617814958
            Originator - Transmit Timestamp: -1152538340.617783069

Czyli ja mu czas wysyłam on ma mnie w nosie smile

PS zmieniłem trochę konfigurację serwera ntp, widać że teraz już mu pasuje:

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server tempus1.gum.gov.pl iburst
server tempus2.gum.gov.pl
server koala.uci.uni.torun.pl
server 127.127.1.0
fudge 127.127.1.0 stratum 10
restrict 127.0.0.1
restrict ::1
restrict 192.168.20.0 mask 255.255.255.0 notrap nomodify nopeer noquery
broadcast 192.168.20.255
restrict 192.168.1.0 mask 255.255.255.0 notrap nomodify nopeer noquery
broadcast 192.168.1.255

A nie lepiej

opkg update
opkg upgrade libopenssl

24

(3 odpowiedzi, napisanych Oprogramowanie / Software)

Weź lepiej sprawdź chauwa czy dobrze mówisz, bo stały adres IP w iPlusie był zawsze i tak pobierany z automatu a zmieniało się APN na m2m, a ty masz internet, więc pewnie dlatego wychodzi tak jak wychodzi. (używałem tej usługi parę lat, nie mam jej od dłuższego czasu ale myślę, że tu się nic nie zmieniło).

No tak własnie zrobiłem, przerobiłem bo używam paczki od Ciebie ale mam w sumie więcej niż jedną instancję. Nie brałem pod uwagę, że nie przewiduje się więcej niż jednej usługi smile