Witam Jakiś czas temu tu na liście przemknął temat accel-ppp. Przymierzam się do postawienia tego na debianie jako alternatywnego, bądź głównego, serwera pppoe. Może podzelicie się swoimi doświadczeniami z tym serwerkiem. 1. Czy były z nim jakieś dziwne problemy, dziwne logi? 2. Czy dodając kolejny interface do słuchania pppoe i robiąc reload daemona czy rozłącza już podłączonych klientów?
Na chwilę obecną używam rp-pppoe i nie ukrywam, że robi to jakieś dziwne akcje. Jakieś dziwne Generic-Errory w logach mimo działania. Nawet ostatnio daemony się tak zapętiły, że miałem ponad 200k połączeń, przy czym jak klient się łączył to nie miał komunikacji i było zrywane połączenie bez downowania interfejsu ppp tylko tworzyny był kolejny Load wzrósł do ponad 2300!. Pomogło kilowanie sesji pppd oraz samych serwerów pppoe-server i ponowny restart.
Z góry dzięki.
W dniu 08.10.2013 10:54, Marcin napisał(a):
Witam
Witam,
Jakiś czas temu tu na liście przemknął temat accel-ppp. Przymierzam się do postawienia tego na debianie jako alternatywnego, bądź głównego, serwera pppoe. Może podzelicie się swoimi doświadczeniami z tym serwerkiem.
- Czy były z nim jakieś dziwne problemy, dziwne logi?
- Czy dodając kolejny interface do słuchania pppoe i robiąc reload
daemona czy rozłącza już podłączonych klientów?
Na chwilę obecną używam rp-pppoe i nie ukrywam, że robi to jakieś dziwne akcje. Jakieś dziwne Generic-Errory w logach mimo działania. Nawet ostatnio daemony się tak zapętiły, że miałem ponad 200k połączeń, przy czym jak klient się łączył to nie miał komunikacji i było zrywane połączenie bez downowania interfejsu ppp tylko tworzyny był kolejny Load wzrósł do ponad 2300!. Pomogło kilowanie sesji pppd oraz samych serwerów pppoe-server i ponowny restart.
Z góry dzięki.
Właśnie jak dla mnie największą wadą accel-ppp jest brak możliwości przeładowania jego konfiguracji bez rozłączenia dotychczasowych sesji. To co jest jego zaletą (mniejsze zużycie pamięci), jest jednocześnie jego wadą przy próbie przeładowania.
W dniu 8 października 2013 11:43 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Właśnie jak dla mnie największą wadą accel-ppp jest brak możliwości przeładowania jego konfiguracji bez rozłączenia dotychczasowych sesji. To co jest jego zaletą (mniejsze zużycie pamięci), jest jednocześnie jego wadą przy próbie przeładowania.
:/ oj to nie dobrze. od czasu do czasu dochodzi mi jakiś vlan do słuchania i nie chciałbym wywalać wszystkich z tego powodu. ewentualnie przychodzi mi rozwiązanie do głowy, że robię bridgea na vlanach i accel-ppp słucha na interfejsie bridgeowym. oczywiście deny forward między vlanami :)
On 08.10.2013 11:55, Marcin wrote:
W dniu 8 października 2013 11:43 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Właśnie jak dla mnie największą wadą accel-ppp jest brak możliwości przeładowania jego konfiguracji bez rozłączenia dotychczasowych sesji. To co jest jego zaletą (mniejsze zużycie pamięci), jest jednocześnie jego wadą przy próbie przeładowania.
:/ oj to nie dobrze. od czasu do czasu dochodzi mi jakiś vlan do słuchania i nie chciałbym wywalać wszystkich z tego powodu. ewentualnie przychodzi mi rozwiązanie do głowy, że robię bridgea na vlanach i accel-ppp słucha na interfejsie bridgeowym. oczywiście deny forward między vlanami :)
Jak się doda z cli interfejs do pppoe to działa od ręki z tego co testowałem a testowałem to właśnie pod tym kątem.. chyba, że coś mi się pochrzaniło ;-)
W dniu 08.10.2013 11:57, Kamil Kordas napisał(a):
On 08.10.2013 11:55, Marcin wrote:
W dniu 8 października 2013 11:43 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Właśnie jak dla mnie największą wadą accel-ppp jest brak możliwości przeładowania jego konfiguracji bez rozłączenia dotychczasowych sesji. To co jest jego zaletą (mniejsze zużycie pamięci), jest jednocześnie jego wadą przy próbie przeładowania.
:/ oj to nie dobrze. od czasu do czasu dochodzi mi jakiś vlan do słuchania i nie chciałbym wywalać wszystkich z tego powodu. ewentualnie przychodzi mi rozwiązanie do głowy, że robię bridgea na vlanach i accel-ppp słucha na interfejsie bridgeowym. oczywiście deny forward między vlanami :)
Jak się doda z cli interfejs do pppoe to działa od ręki z tego co testowałem a testowałem to właśnie pod tym kątem.. chyba, że coś mi się pochrzaniło ;-)
Właśnie z tego co ja kojarzę, nie wszystko się da przeładować z cli.
W dniu wtorek, 8 października 2013 użytkownik Tomasz Chiliński napisał:
W dniu 08.10.2013 11:57, Kamil Kordas napisał(a):
On 08.10.2013 11:55, Marcin wrote:
W dniu 8 października 2013 11:43 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Właśnie jak dla mnie największą wadą accel-ppp jest brak możliwości przeładowania jego konfiguracji bez rozłączenia dotychczasowych sesji. To co jest jego zaletą (mniejsze zużycie pamięci), jest jednocześnie jego wadą przy próbie przeładowania.
:/ oj to nie dobrze. od czasu do czasu dochodzi mi jakiś vlan do słuchania i nie chciałbym wywalać wszystkich z tego powodu. ewentualnie przychodzi mi rozwiązanie do głowy, że robię bridgea na vlanach i accel-ppp słucha na interfejsie bridgeowym. oczywiście deny forward między vlanami :)
Jak się doda z cli interfejs do pppoe to działa od ręki z tego co testowałem a testowałem to właśnie pod tym kątem.. chyba, że coś mi się pochrzaniło ;-)
Właśnie z tego co ja kojarzę, nie wszystko się da przeładować z cli.
Dokładnie. Cześć ważnych rzeczy przeładowuje się po zabiciu procesu. Ja sobie z tym problemem skutecznie poradziłem, tylko wymaga trochę cierpliwości ;)
Pozdrawiam
9 paź 2013 09:44 "Piotrek S." komuch@gmail.com napisał(a):
Dokładnie. Cześć ważnych rzeczy przeładowuje się po zabiciu procesu. Ja sobie z tym problemem skutecznie poradziłem, tylko wymaga trochę
cierpliwości ;)
Powiesz coś więcej jak sobie z tym poradziłeś?
On 09.10.2013 10:10, Marcin wrote:
9 paź 2013 09:44 "Piotrek S." <komuch@gmail.com mailto:komuch@gmail.com> napisał(a):
Dokładnie. Cześć ważnych rzeczy przeładowuje się po zabiciu procesu. Ja sobie z tym problemem skutecznie poradziłem, tylko wymaga trochę
cierpliwości ;)
Powiesz coś więcej jak sobie z tym poradziłeś?
ale tutaj się rozchodzi o sam koncentrator pppoe żeby dodać np do nowego vlanu i to działa od ręki.
interface: connections: state: ----------------------------------- vlan100 13 active vlan900 2 active
accel-ppp# pppoe interface add eth2 accel-ppp# pppoe interface show interface: connections: state: ----------------------------------- vlan100 13 active vlan900 2 active eth2 0 active
i bez przeładowania i rozłączenia klientów jest on dostępny na eth2
W dniu 9 października 2013 10:54 użytkownik Kamil Kordas k0rdi@interblock.pl napisał:
accel-ppp# pppoe interface add eth2 accel-ppp# pppoe interface show interface: connections: state:
vlan100 13 active vlan900 2 active eth2 0 active
i bez przeładowania i rozłączenia klientów jest on dostępny na eth2
nie ukrywam, że bardzo mnie to cieszy :)
bawił/testował może ktoś obsługę ipv6?
Witam
Jeżeli temat nie jest "na już" - czyli możesz poczekać na efekty działania chwilę, to można zrobić to w ten sposób, że odpalasz drugiego accela na tej samej maszynie, już z nowymi ustawieniami i koniecznie słuchającego na innym porcie (MGMT), żeby się nie gryzły.
Na starym robisz shutdown soft i czekasz aż userki się porozłączają i wtedy się wyłącza proces. Nowe połączenia terminuje drugi accel... Działa to ładnie.
Ogólnie ładnie też działa rozkładanie na >=2 maszyny poprzez delay, ale to tak trochę OT
Pozdrawiam
W dniu 9 października 2013 10:10 użytkownik Marcin marcin@nicram.netnapisał:
9 paź 2013 09:44 "Piotrek S." komuch@gmail.com napisał(a):
Dokładnie. Cześć ważnych rzeczy przeładowuje się po zabiciu procesu. Ja sobie z tym problemem skutecznie poradziłem, tylko wymaga trochę
cierpliwości ;)
Powiesz coś więcej jak sobie z tym poradziłeś?
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Tak to wygląda mniej-więcej...
komuch@PPPoE1:~$ ps ax | grep accel
3451 ? Ssl 2070:18 /usr/sbin/accel-pppd -d -p /var/run/accel-pppd.pid -c /etc/accel-ppp.conf 8341 ? Ssl 233:45 /usr/sbin/accel-pppd -d -p /var/run/accel2-pppd.pid -c /etc/accel-ppp2.conf
W dniu 10 października 2013 13:26 użytkownik Piotrek S. komuch@gmail.comnapisał:
Witam
Jeżeli temat nie jest "na już" - czyli możesz poczekać na efekty działania chwilę, to można zrobić to w ten sposób, że odpalasz drugiego accela na tej samej maszynie, już z nowymi ustawieniami i koniecznie słuchającego na innym porcie (MGMT), żeby się nie gryzły.
Na starym robisz shutdown soft i czekasz aż userki się porozłączają i wtedy się wyłącza proces. Nowe połączenia terminuje drugi accel... Działa to ładnie.
Ogólnie ładnie też działa rozkładanie na >=2 maszyny poprzez delay, ale to tak trochę OT
Pozdrawiam
W dniu 9 października 2013 10:10 użytkownik Marcin marcin@nicram.netnapisał:
9 paź 2013 09:44 "Piotrek S." komuch@gmail.com napisał(a):
Dokładnie. Cześć ważnych rzeczy przeładowuje się po zabiciu procesu. Ja sobie z tym problemem skutecznie poradziłem, tylko wymaga trochę
cierpliwości ;)
Powiesz coś więcej jak sobie z tym poradziłeś?
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Możesz napisać coś więcej, jak masz ustawione delay i na jakiej zasadzie rozkladasz połączenia
"Piotrek S." komuch@gmail.com napisał:
Tak to wygląda mniej-więcej...
komuch@PPPoE1:~$ ps ax | grep accel
3451 ? Ssl 2070:18 /usr/sbin/accel-pppd -d -p /var/run/accel-pppd.pid -c /etc/accel-ppp.conf 8341 ? Ssl 233:45 /usr/sbin/accel-pppd -d -p /var/run/accel2-pppd.pid -c /etc/accel-ppp2.conf
W dniu 10 października 2013 13:26 użytkownik Piotrek S. komuch@gmail.comnapisał:
Witam
Jeżeli temat nie jest "na już" - czyli możesz poczekać na efekty
działania
chwilę, to można zrobić to w ten sposób, że odpalasz drugiego accela
na tej
samej maszynie, już z nowymi ustawieniami i koniecznie słuchającego
na
innym porcie (MGMT), żeby się nie gryzły.
Na starym robisz shutdown soft i czekasz aż userki się porozłączają i wtedy się wyłącza proces. Nowe połączenia terminuje drugi accel...
Działa
to ładnie.
Ogólnie ładnie też działa rozkładanie na >=2 maszyny poprzez delay,
ale to
tak trochę OT
Pozdrawiam
W dniu 9 października 2013 10:10 użytkownik Marcin
marcin@nicram.netnapisał:
9 paź 2013 09:44 "Piotrek S." komuch@gmail.com napisał(a):
Dokładnie. Cześć ważnych rzeczy przeładowuje się po zabiciu procesu. Ja sobie z tym problemem skutecznie poradziłem, tylko wymaga
trochę
cierpliwości ;)
Powiesz coś więcej jak sobie z tym poradziłeś?
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Załóżmy tak, że masz np. 1500 sesji w szczycie podniesionych i chcesz żeby to w miarę rozkładało się po równo na oba koncentratory.
Zabawa polega na tym, żeby ustawić odpowiednie opóźnienie, po którym odpowiada koncentrator, w zależności od tego ile ma zaterminowanych sesji w danym momencie.
Accel umożliwia dokładną definicję opóźnień, dla konkretnej ilości podniesionych sesji. Odpowiedzialna jest za to opcja pado-delay, znajdująca się w sekcji [pppoe] (tam gdzie masz dodane na sztywno interfejsy, gdzie jest nazwa koncentratora i service-name).
Opcja pado-delay może przyjmować jedną wartość (np. pado-delay=100) - wtedy nie jest ważne ile jest podniesionych sesji, koncentrator odpowiada (pakiet z PADO - PPPoE Active Discovery Offer) po 100ms. Oczywiście powyższe 100ms to w sytuacji, kiedy zasoby na to pozwalają - jak jest maszyna mocno obciążona, czas odpowiedzi jest wyższy - ale to chyba oczywiste :)
Z tym jednym parametrem można sobie fajnie zrobić kilka koncentratorów, gdzie np. jest jeden główny, który terminuje sesje, ale kiedy przestaje wyrabiać albo ilość zaterminowanych sesji osiągnie jakąś określoną wartość, część nowych sesji zaczyna terminować kolejny...
Drugi przypadek to pado-delay z kilkoma opcjami, np. na obu koncentratorach to samo: pado-delay=0,500:500,600:700,-1:1500 Można wyczytać to w dokumentacji, ale opiszę to na podstawie własnego doświadczenia - może dla niektórych wyda się to bardziej przystępne.
Pierwszy parametr (0) oznacza ogólne opóźnienie, tu się nic nie zmienia w stosunku do pierwszej wersji (tej z jednym parametrem), jednak tutaj zostawiamy 0. Kolejne parametry po przecinku definiują opóźnienia przy konkretnych ilościach podniesionych sesji, w takim formacie opóźnienie:ilość sesji Czyli mamy 500:500 - oznacza to, że przy osiągnięciu 500 podniesionych sesji, koncentrator czeka 500ms z odpowiedzią (PADO) i dopiero wysyła. Kolejny 600:700 - czyli po osiągnięciu 700 podniesionych sesji, czeka 600ms z PADO.
Na koniec -1:1500. Oznacza, że przy osiągnięciu 1500 sesji ma nie odpowiadać na żądania nawiązania nowych sesji. Warto się zastanowić ile mamy maksymalnie sesji podniesionych w sumie i ustawić taką wartość, żeby w razie padu jednego koncentratora, drugi mógł przejąć całość (jeżeli mamy dwa, lub ustawić 2/3 maksymalnej wartości jeżeli mamy np. 3, ale to już wedle uznania).
Jak to w praktyce działa ??
Do 500 sesji nie ma praktycznie opóźnień, więc maszyny obydwie odpowiadają w tym samym czasie i liczą się ułamki sekund, z którym się połączy... Jeżeli na jednej z nich "wskoczy" te 500 sesji podniesionych, zaczyna wprowadzać 500ms opóźnienia z odpowiedzią... czyli mamy sytuację taką, że ten drugi, który jeszcze nie osiągnął 500 sesji, odpowiada szybciej, przez co z nim nawiązywana jest nowa sesja. Jeżeli na obu osiągnięte jest po 500 sesji, sytuacja wygląda podobnie jak przed osiągnięciem 500 sesji / koncentrator - z tą różnicą, że minimalny czas odpowiedzi obu to te zdefiniowane 500ms... I tak w kółko....
W praktyce, jak zapewne widzieliście na wykresie, który wcześniej wysłałem, rozkłada się to w miarę równo. Fajnie jest, jak ma się podobne maszyny, w innym przypadku trzeba z tymi opóźnieniami trochę inaczej kombinować...
O co na koniec należy się jeszcze zatroszczyć?
Na pewno >1 koncentrator umożliwia połączenie się tym samym loginem więcej jak 1 raz w tym samym czasie. Chyba że w konfiguracji radiusa postaramy się o to, żeby sprawdzać ile w danym momencie razy zalogowany jest dany użytkownik. Dzieje się tak dlatego, że w accelu opcja single-session działa tylko w ramach jednego koncentratora.
Drugą sprawą o którą warto zadbać jeżeli mamy tylko jednego radiusa, to to, ile jednoczesnych połączeń może obsłużyć. Przy większej ilości koncentratorów dobrze by było, aby to nie stanowiło wąskiego gardła.
To chyba tyle... ale gdyby się zdarzyło, że czegoś nie napisałem, dajcie znać.
Na koniec dodam, że zdaję sobie sprawę z tego, że mocno się rozpisałem. Może opisane to tak jak dla laika, może zbyt łopatologicznie... więc ci bardziej PRO niech mi wybaczą :) ale zostanie to w archiwach, dla potomnych ;)
Pozdrawiam
W dniu 11 października 2013 16:16 użytkownik Kamil Kordas < k0rdi@interblock.pl> napisał:
Możesz napisać coś więcej, jak masz ustawione delay i na jakiej zasadzie rozkladasz połączenia
"Piotrek S." komuch@gmail.com napisał:
Tak to wygląda mniej-więcej...
komuch@PPPoE1:~$ ps ax | grep accel
3451 ? Ssl 2070:18 /usr/sbin/accel-pppd -d -p /var/run/accel-pppd.pid -c /etc/accel-ppp.conf 8341 ? Ssl 233:45 /usr/sbin/accel-pppd -d -p /var/run/accel2-pppd.pid -c /etc/accel-ppp2.conf
W dniu 10 października 2013 13:26 użytkownik Piotrek S. <komuch@gmail.com
napisał:
Witam
Jeżeli temat nie jest "na już" - czyli możesz poczekać na efekty działania chwilę, to można zrobić to w ten sposób, że odpalasz drugiego accela na tej samej maszynie, już z nowymi ustawieniami i koniecznie słuchającego na innym porcie (MGMT), żeby się nie gryzły.
Na starym robisz shutdown soft i czekasz aż userki się porozłączają i wtedy się wyłącza proces. Nowe połączenia terminuje drugi accel... Działa to ładnie.
Ogólnie ładnie też działa rozkładanie na >=2 maszyny poprzez delay, ale to tak trochę OT
Pozdrawiam
W dniu 9 października 2013 10:10 użytkownik Marcin marcin@nicram.netnapisał:
9 paź 2013 09:44 "Piotrek S." komuch@gmail.com napisał(a):
Dokładnie. Cześć ważnych rzeczy przeładowuje się po zabiciu procesu. Ja sobie z tym problemem skutecznie poradziłem, tylko wymaga trochę
cierpliwości ;)
Powiesz coś więcej jak sobie z tym poradziłeś?
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
-- Wysłane za pomocą K-9 Mail.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Witam. Mam pytanie do bardziej doświadczonych użytkowników accela. czy jeśli accel ma problem z połączeniem do radiusa (accounting) to czy rozłącza on połączone sesje, których "nie może" updateować??
W dniu 22.12.2013 22:32, Marcin napisał(a):
Witam.
Witam,
Mam pytanie do bardziej doświadczonych użytkowników accela. czy jeśli accel ma problem z połączeniem do radiusa (accounting) to czy rozłącza on połączone sesje, których "nie może" updateować??
Nie powinien. Accounting to jedno, zaś Authentication to drugie.
W dniu 22 grudnia 2013 22:47 użytkownik Tomasz Chiliński chilek@chilan.com napisał:
Nie powinien. Accounting to jedno, zaś Authentication to drugie.
no nie powinien, ale rozłącza. robiłeł ALTER na tabeli radacct. trwało to około minuty. w tym czasie, accel nie mógł "dogadać" się z radiusem i klienckie sesje, które w tym czasie powinny być accountigowane zostały zterminowane co zaskutkowało niemożłiwością ponownego zalogowania się klienta gdyż na bazie nie zostało wykonane acctstop i połączenie w bazie wisiało. dopiero jak "wyczyśliłem" wpisy w bazie to zaczęli luki się logować.
a jednak. zgodnie z dokumentacją rozłącza.
" timeout=n Timeout to wait response from server (sec). max-try=n Specifies maximum number of tries to send Access-Request/Accounting-Request queries. acct-timeout=n Specifies timeout to wait reply for Interim-Update packets. If n is greater than zero then session will be terminated after timeout exceeds. If n is zero then don't retransmit Interim-Update packets and don't terminate session. "
ze źródeł widać, że wszystkie te wartości defaultowo ustawione są na "3"
W dniu 22 grudnia 2013 22:53 użytkownik Marcin marcin@nicram.net napisał:
W dniu 22 grudnia 2013 22:47 użytkownik Tomasz Chiliński chilek@chilan.com napisał:
Nie powinien. Accounting to jedno, zaś Authentication to drugie.
no nie powinien, ale rozłącza. robiłeł ALTER na tabeli radacct. trwało to około minuty. w tym czasie, accel nie mógł "dogadać" się z radiusem i klienckie sesje, które w tym czasie powinny być accountigowane zostały zterminowane co zaskutkowało niemożłiwością ponownego zalogowania się klienta gdyż na bazie nie zostało wykonane acctstop i połączenie w bazie wisiało. dopiero jak "wyczyśliłem" wpisy w bazie to zaczęli luki się logować.
-- Pozdrawiam Marcin / nicraM
W dniu 22.12.2013 23:07, Marcin napisał(a):
a jednak. zgodnie z dokumentacją rozłącza.
" timeout=n Timeout to wait response from server (sec). max-try=n Specifies maximum number of tries to send Access-Request/Accounting-Request queries. acct-timeout=n Specifies timeout to wait reply for Interim-Update packets. If n is greater than zero then session will be terminated after timeout exceeds. If n is zero then don't retransmit Interim-Update packets and don't terminate session. "
ze źródeł widać, że wszystkie te wartości defaultowo ustawione są na "3"
No to utwierdza mnie po raz kolejny w przekonaniu, że znikome zalety ma accel-ppp w stosunku do rp-pppoe+pppd.
W dniu 22 grudnia 2013 23:14 użytkownik Tomasz Chiliński chilek@chilan.com napisał:
No to utwierdza mnie po raz kolejny w przekonaniu, że znikome zalety ma accel-ppp w stosunku do rp-pppoe+pppd.
wystarczy acct-timeout ustawić na 0 i accel już olewa, że radius nie odpowie responsem :)
ja w pppd miałem/mam dziwny przypadek. otóż z "niewiadomych" przyczyn (podejrzewam, że to stp na porcie) nagle mam tysiące nie obsłużonych połączeń, pppd nie są terminowane lecz podnoszone są nowe itd. skutkuje to loadem rzędu > 2000 i brakiem netu u ludzi. w logach czysto, lecz od czasu do czasu mam "generic-error". Podczas tej specyficznej sytuacji poszedłem ręcznie restartnąć serwer ("killall -9 pppd" dłuugo trwało) to na konsoli widziałem wpis coś o wyrejestrowanym połączeniu pppX i ze czeka na jego "zwolnienie", coś w tym stylu "pppd unregistered device".
W dniu 10 października 2013 13:26 użytkownik Piotrek S. komuch@gmail.com napisał:
Ogólnie ładnie też działa rozkładanie na >=2 maszyny poprzez delay, ale to tak trochę OT
OT jeśli chodzi o lms, ale nie o wątek :) wszelkie za mile widziane, przeciw też :)
uczestnicy (5)
-
Kamil Kordas -
Marcin -
Piotrek S. -
Tomasz Chiliński -
Tomasz Chiliński