Freesco, NND, CDN, EOS
http://forum.freesco.pl/

Problemy z routerami klienckimi po pppoe
http://forum.freesco.pl/viewtopic.php?f=38&t=18105
Strona 1 z 2

Autor:  Albercik [ wtorek, 9 lutego 2010, 00:49 ]
Tytuł:  Problemy z routerami klienckimi po pppoe

Jeden z routerów działających jeszcze na NND postanowiłem zmienić na CDN, poinstalowałem odpowiednie paczki, odpaliłem działa. Podmieniłem i od tego momentu zaczęły dziać się dziwne rzeczy, routery klienckie, które dotychczas działały prawidłowo - tylko jednej marki!!! -przestały funkcjonować poprawnie, dokładniej: łączył się po pppoe, wszystkie parametry otrzymywał, ale klient żadnej strony nie mógł otworzyć, co więcej można pingować strony po nazwach i po ip, można wejść na stronkę routera CDN, zdarzy się chwilowe otwarcie strony, a następnie już strony stają na amen. Najgorsze jest to, że na kablu wszystko jest ok. Dzisiaj wpadł mi w ręce Dlink, który na kablu łączy się doskonale, a podłączony do klienta radiowego nie potrafi nawet się zalogować. Najpierw podejrzewałem DNS, ale wiadomo - skoro mogę pingować stronę po nazwie to ta opcja odpada, następny mój pomysł to MTU, ale jakie nie ustawię, czy to na CDN czy na kliencie, nie daje rezultatu. Nadmienię jeszcze, że komputery każde jak dotąd działają prawidłowo. Zmieniłem także rozmiar paczki mss na mniejszą na CDN, też na nic. Proszę o pomysły, moje skończyły się kilka dni temu i błądzę po omacku :roll:

--EDIT--
Zapomniałem dodać, że na tychże routerkach klienckich internet nie działa na LANie, na wi-fi działa znakomicie. Wymiękam...

--EDIT--
Nastepna ciekawostka: wchodze na strone CDN i moge ogladac wszystko, przegladac podstrony, ale mam tam takie iso testowe, ponad 1GB obraz dysku do sprawdzania jakosci pobierania danych - niestety nie mozna go pobrac, ale widze go w przegladarce. POMOCY :)

--EDIT--
Nastepna ciekawostka : mozna zalogowac sie do CDN przez ssh, GG działa...

i torrenty działają...

--EDIT--
Generalnie zwykłe routery w standardowych ustawieniach zmniejszają TTL o 1, tak robią TPLinki (sprawdziłem),a ten nie, po nim jest nadal TTL 64. Ma to jakieś znaczenie w tym wypadku?

Autor:  Albercik [ środa, 10 lutego 2010, 14:43 ]
Tytuł: 

Nikt nie jest w stanie podpowiedzieć czegoś?

Autor:  Maciek [ środa, 10 lutego 2010, 15:08 ]
Tytuł: 

Ja mam tylko jedną uwagę, brak zmniejszania TTL nie ma tu akurat negatywnych skutków.

Autor:  tasiorek [ czwartek, 11 lutego 2010, 11:02 ]
Tytuł: 

Sprawdz ping mala i duza paczka. Nie znam dobrze pppoe, ale obstawiam ze to jednak problem z mtu.

Autor:  Maciek [ czwartek, 11 lutego 2010, 11:41 ]
Tytuł: 

Tak tasiorku, wszystko wygląda na to, że to MTU, też analizowałem ten problem. Ale jak temu zaradzić.

Autor:  Albercik [ czwartek, 11 lutego 2010, 20:53 ]
Tytuł: 

tasiorek pisze:
Sprawdz ping mala i duza paczka. Nie znam dobrze pppoe, ale obstawiam ze to jednak problem z mtu.


Zgadzam się z Tobą, dokładnie tak to wygląda, ale tyle nakombinowałem, że pomysły mi się skończyły. Max rozmiar pakietu przechodzącego bez straty to 1444B, umownie - 1440B. Ustawienie tego na dowolnych interfejsach fizycznych czy wirtualnych nie zmienia sytuacji.

Autor:  barte-k [ niedziela, 14 lutego 2010, 22:08 ]
Tytuł: 

Albercik, a jakieś logi pppd? Może po analizować ruch sieciowy przez tcpdump?

Hint: http://www.linuxquestions.org/questions ... ost3645047

Autor:  Albercik [ niedziela, 14 lutego 2010, 23:41 ]
Tytuł: 

barte-k pisze:
Albercik, a jakieś logi pppd? Może po analizować ruch sieciowy przez tcpdump?

Hint: http://www.linuxquestions.org/questions ... ost3645047


Logi rozbudowane, ale są ok. Zrobiłem testy pobierania pliku - największy, jaki dało się pobrać miał 5,2kB. Plik powiększałem każdorazowo o 100B, 5,3KB już nie poszedł. Nie wiem w sumie czy to w ogóle ma znaczenie.

Autor:  tasiorek [ niedziela, 14 lutego 2010, 23:42 ]
Tytuł: 

Proponuje sprawdzic (np. pingiem) jaka najwieksza paczka przechodzi i ustawic takie mtu na routerach.

Autor:  Albercik [ poniedziałek, 15 lutego 2010, 00:23 ]
Tytuł: 

tasiorek pisze:
Proponuje sprawdzic (np. pingiem) jaka najwieksza paczka przechodzi i ustawic takie mtu na routerach.


Albercik pisze:
następny mój pomysł to MTU, ale jakie nie ustawię, czy to na CDN czy na kliencie, nie daje rezultatu


Albercik pisze:
max rozmiar pakietu przechodzącego bez straty to 1444B, umownie - 1440B. Ustawienie tego na dowolnych interfejsach fizycznych czy wirtualnych nie zmienia sytuacji.


barte-k pisze:
Albercik, a jakieś logi pppd? Może po analizować ruch sieciowy przez tcpdump?

Hint: http://www.linuxquestions.org/questions ... ost3645047


Sprawdziłem, jedyny log to:
: [/] [] ()
23:17:25.823368 PPPoE  [len 48 > 42!] [ses 0xb] IP komp2_100.25420 > 200.0.0.239.ssh: . ack 4178969348 win 65027


--EDIT--

Jedyna różnica pomiędzy logami z kompa, a tymi z routerów klienckich to ten element:
Cytuj:
[len 48 > 42!]


Nie znalazłem informacji, co odpowiada tym liczbom.

Autor:  barte-k [ poniedziałek, 15 lutego 2010, 20:20 ]
Tytuł: 

Przyznam, niecodzienna sytuacja. Ale piszesz że po kablu działa zatem możemy ostrożnie założyć, że konfiguracja serwera jest poprawna.
Jedyne co się zmienia to sposób połączenia klienta z serwerem, czy tak? I co to za marka która sprawia problemy? Jakie inne ficzery zaimplementowaleś? (IMQ, Niceshaper05)

Autor:  Albercik [ środa, 17 lutego 2010, 16:26 ]
Tytuł: 

barte-k pisze:
Przyznam, niecodzienna sytuacja. Ale piszesz że po kablu działa zatem możemy ostrożnie założyć, że konfiguracja serwera jest poprawna.
Jedyne co się zmienia to sposób połączenia klienta z serwerem, czy tak? I co to za marka która sprawia problemy? Jakie inne ficzery zaimplementowaleś? (IMQ, Niceshaper05)


Wyłączyłem wszystko, kolejkowanie, imq, wszelkie dodatki zostały wyrzucone. Na tą chwilę jest postawiony podstawowy router + rp-pppoe. Jest w tej chwili wszystko dokładnie tak, jak na NND, na którym wszystko pracowało ok. Routery TPLinka pracują prawidłowo.

Zrobiłem pewne doświadczenie, moja struktura tej gałęzi sieci w której to testowałem wygląda tak:

: [/] [] ()

świat---[CDN]-->[RB411-most naMT z EOIPem]---[RB600-most z EOIPem + antenki klienckie]----> [apclient+router klienta]



Z racji tego, że EOIP to też kapsułkowanie więc zabiera następne bajty z nagłówka, podwójnie, więc 48B odpada. W tym wypadku postanowiłem zmienić tryb pomiędzy MTkami na WDS, nic to nie dało. Zrobiłem też taki model na stole

: [/] [] ()
...CDN]-->[UBNT-WDS]----[UBNT-WDS]---router kliencki


...i wszystko działa jak należy. Niestety nie miałem pod ręką MTków.

--EDIT--

Ustawiłem wszystko na domyślne i pojawiły się jakieś logi na CDN:
kernel.log
: [/] [] ()
Feb 17 19:09:29 pppoe1 kernel: MPPE/MPPC encryption/compression module registered
Feb 17 19:09:29 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Feb 17 19:09:32 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Feb 17 19:09:35 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Feb 17 19:09:38 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Feb 17 19:09:41 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Feb 17 19:09:44 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Feb 17 19:09:47 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Feb 17 19:09:50 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Feb 17 19:09:53 pppoe1 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00


: [/] [] ()
Feb 15 11:40:00 pppoe1 kernel: EIP: 0060:[<f9dae939>] EFLAGS: 00010282 CPU: 0
Feb 15 11:40:00 pppoe1 kernel: EIP is at mppe_alloc+0x139/0x4a0 [ppp_mppe_mppc]
Feb 15 11:40:00 pppoe1 kernel: EAX: ffffffea EBX: f5913680 ECX: 00000000 EDX: 00000000
Feb 15 11:40:00 pppoe1 kernel: ESI: f5b07eb4 EDI: f59136f8 EBP: 00000000 ESP: f5b07e28
Feb 15 11:40:00 pppoe1 kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Feb 15 11:40:00 pppoe1 kernel: Process pppd (pid: 14527, ti=f5b06000 task=f5af65b0 task.ti=f5b06000)
Feb 15 11:40:00 pppoe1 kernel: Stack:
Feb 15 11:40:00 pppoe1 kernel: f5f89d7c fffffffe c110c88f 003318d5 f5b07eb0 bfb092b8 f4c85400 fffffff2
Feb 15 11:40:00 pppoe1 kernel: <0> f9daf32b 00000000 00000000 003318d5 f54ce340 f5b07eb4 f9dafb00 bfb09234
Feb 15 11:40:00 pppoe1 kernel: <0> f7e3893b f5f89808 00000015 f7364b04 f5913200 f54ce390 bfb09234 f59315a0
Feb 15 11:40:00 pppoe1 kernel: Call Trace:
Feb 15 11:40:00 pppoe1 kernel: [<c110c88f>] ? __link_path_walk+0x8f/0xd50
Feb 15 11:40:00 pppoe1 kernel: [<f7e3893b>] ? ppp_ioctl+0xd4b/0xea0 [ppp_generic]
Feb 15 11:40:00 pppoe1 kernel: [<c10c177e>] ? filemap_fault+0x9e/0x420
Feb 15 11:40:00 pppoe1 kernel: [<c10d92b0>] ? all_vm_events+0x40/0x90
Feb 15 11:40:00 pppoe1 kernel: [<f7e37bf0>] ? ppp_ioctl+0x0/0xea0 [ppp_generic]
Feb 15 11:40:00 pppoe1 kernel: [<c1110422>] ? vfs_ioctl+0x22/0xa0
Feb 15 11:40:00 pppoe1 kernel: [<c1110641>] ? do_vfs_ioctl+0x81/0x5c0
Feb 15 11:40:00 pppoe1 kernel: [<c10ddf8e>] ? handle_mm_fault+0x17e/0xa50
Feb 15 11:40:00 pppoe1 kernel: [<c1110c0e>] ? sys_ioctl+0x8e/0xb0
Feb 15 11:40:00 pppoe1 kernel: [<c1003e93>] ? sysenter_do_call+0x12/0x28


: [/] [] ()
Feb 15 12:12:51 pppoe1 kernel: ppp: compressor dropped pkt
Feb 15 12:12:51 pppoe1 kernel: ppp: compressor dropped pkt
Feb 15 12:12:57 pppoe1 kernel: ppp: compressor dropped pkt
Feb 15 12:12:57 pppoe1 kernel: ppp: compressor dropped pkt
Feb 15 12:13:03 pppoe1 kernel: ppp: compressor dropped pkt


: [/] [] ()
pppd[5201]: Failed to connect PPPoE socket: 114 Operation already in progress
pppoe-server[5383]: recv (receivePacket): Network is down
pppoe-server[1210]: PADT: Generic-Error: session closed

Autor:  czerwo [ piątek, 19 lutego 2010, 12:25 ]
Tytuł: 

hm wysypało się??
Przynajmniej tak to wygląda. Sprawdziłbym:
1. Inna wersje pppoe
2. Cos nie tak z jajem?? Jakiś moduł sie wywala? Inna wersja jaja?

Autor:  barte-k [ piątek, 19 lutego 2010, 23:13 ]
Tytuł: 

Zgadzam się z czerwo, sprawdziłbym inne wersje jądra, w tym oryginalne Archowe
Wersja jądra 2.6.31PGF raczej miała jakiś patch mppe, może coś nie wyszło?

Autor:  Albercik [ sobota, 20 lutego 2010, 00:46 ]
Tytuł: 

barte-k pisze:
Zgadzam się z czerwo, sprawdziłbym inne wersje jądra, w tym oryginalne Archowe
Wersja jądra 2.6.31PGF raczej miała jakiś patch mppe, może coś nie wyszło?


Tych jajek już było 3, każde inne, patchowane i nie, pppd już 2.4.2 , 2.4.3, 2.4.4 , teraz 2.4.5 . System odpada, a te logi to wynik mojej wesołej twórczości w stanie ostatecznym. Macie jakieś jajo dla podmiany ? Chętnie skorzystam, z routera zrobiłem poligon doświadczalny :)
Cały czas online z Saturasem czy Maćkiem, a także z pomocą człowieka z trzepaka o nicku "zlyZwierz". Według mnie właśnie nadszedł kres pomysłów.

Autor:  czerwo [ sobota, 20 lutego 2010, 09:21 ]
Tytuł: 

Moja skromna propozycja ;]
Jako, że ppp tez ma pewne zależności ...
Zwykła maszyna na niej arch
Skonfigurować sprawdzić czy działa
Jak działa i się nie wysypuje to:
Router na nowo postawić na CDN
Sprawdzić czy działa, jak się wysypuje to przełożyć dyski na krzyż
jak się wysypuje CDN nadal a arch nie to znaczy, że problem systemowy więc już coś wiemy
Więc zaczyna się teraz głupia robota ;]
Porównać zawartość archa z CDN wystarczy pacman -Q i porównać co jest w innych wersjach

I jeszcze coś
Wersja : 2.4.4-7
Zależy od : glibc libpcap>=1.0.0

libpcap 1.0.0-1
glibc 2.9-4

Na tej wersji jak najbardziej działa. Ale to już dość stare ;]

Autor:  Albercik [ sobota, 20 lutego 2010, 13:07 ]
Tytuł: 

czerwo pisze:
Moja skromna propozycja ;]
Jako, że ppp tez ma pewne zależności ...
Zwykła maszyna na niej arch
Skonfigurować sprawdzić czy działa
Jak działa i się nie wysypuje to:
Router na nowo postawić na CDN
Sprawdzić czy działa, jak się wysypuje to przełożyć dyski na krzyż
jak się wysypuje CDN nadal a arch nie to znaczy, że problem systemowy więc już coś wiemy
Więc zaczyna się teraz głupia robota ;]
Porównać zawartość archa z CDN wystarczy pacman -Q i porównać co jest w innych wersjach

I jeszcze coś
Wersja : 2.4.4-7
Zależy od : glibc libpcap>=1.0.0

libpcap 1.0.0-1
glibc 2.9-4

Na tej wersji jak najbardziej działa. Ale to już dość stare ;]


To już zostało zrobione, efekt ten sam. Zrobiłem doświadczenie : zasymulowałem dokładnie taki sam model sieci na biurku - działa, więc z jednej strony wina CDN to nie jest, z drugiej jednak na NND ten problem nie występuje. To wygląda jak zagadka typu "Gdzie jest Wally" :roll:

Autor:  czerwo [ sobota, 20 lutego 2010, 13:16 ]
Tytuł: 

Albercik pisze:
To już zostało zrobione, efekt ten sam. Zrobiłem doświadczenie : zasymulowałem dokładnie taki sam model sieci na biurku - działa, więc z jednej strony wina CDN to nie jest, z drugiej jednak na NND ten problem nie występuje. To wygląda jak zagadka typu "Gdzie jest Wally" :roll:

Możesz jaśniej?? Co to znaczy efekt nie występuje? Jak za symulowałeś? I czy biurko było czarne czy brązowe :twisted:

Autor:  Albercik [ sobota, 20 lutego 2010, 13:27 ]
Tytuł: 

czerwo pisze:
Możesz jaśniej?? Co to znaczy efekt nie występuje? Jak za symulowałeś? I czy biurko było czarne czy brązowe :twisted:


Co do systemu - jak wyżej, już pisałem. Model sieci - jak wyżej, też opisałem, ale rozrysuję to jakkolwiek będzie jaśniej:
: [/] [] ()
świat--[CDN]---[MT(411)-Bridge/EOIP,WDS- jakkolwiek]----[MT(RB600)-Bridge+AP] ----[APClient---router kliencki(z problemami)]


Jeśli kolor biurka może mieć takie znaczenie jak dns'y dla mc, to mogę nawet powiesić je na kominie obok nadajnika i przemalować na dowolny kolor :twisted:

Autor:  czerwo [ sobota, 20 lutego 2010, 13:45 ]
Tytuł: 

Ale czy próbowałeś zrobić to samo na archu??

Strona 1 z 2 Strefa czasowa UTC+2godz.
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/