Forum Debian Users Gang

morfik · 2014-01-31 11:01:24

Zgodnie z tym co piszą na stronie http://www.linuximq.net/news.html :

Patch for Linux Kernel 3.11.x up to Linux Kernel 3.12.3.
Patch for iptables 1.4.13.x can be applied to 1.4.16.x.

Patchowanie i kompilacja iptables poszło bez problemu. Ale gdy próbuję założyć tę łatę na kernela 3.12-1-amd64 (debianowy), coś mi to nie wychodzi za bardzo:

Kod:

# patch --dry-run -p1 < ../linux-imqmq-3.11.patch
checking file drivers/net/Kconfig
checking file drivers/net/Makefile
checking file drivers/net/imq.c
checking file include/linux/imq.h
checking file include/linux/netfilter/xt_IMQ.h
checking file include/linux/netfilter_ipv4/ipt_IMQ.h
checking file include/linux/netfilter_ipv6/ip6t_IMQ.h
checking file include/linux/skbuff.h
Hunk #2 succeeded at 421 (offset -6 lines).
Hunk #3 succeeded at 459 with fuzz 2 (offset -9 lines).
Hunk #4 FAILED at 508.
Hunk #5 succeeded at 634 (offset -9 lines).
Hunk #6 succeeded at 2661 with fuzz 2 (offset -11 lines).
1 out of 6 hunks FAILED
checking file include/net/netfilter/nf_queue.h
checking file include/uapi/linux/netfilter.h
checking file net/core/dev.c
Hunk #2 succeeded at 2598 (offset -3 lines).
checking file net/core/skbuff.c
Hunk #4 succeeded at 810 (offset -3 lines).
Hunk #5 succeeded at 3217 (offset 22 lines).
checking file net/ipv6/ip6_output.c
Hunk #1 succeeded at 64 (offset -25 lines).
Hunk #2 succeeded at 140 (offset -24 lines).
checking file net/netfilter/Kconfig
Hunk #1 succeeded at 630 (offset -11 lines).
checking file net/netfilter/Makefile
checking file net/netfilter/core.c
checking file net/netfilter/nf_internals.h
checking file net/netfilter/nf_queue.c
checking file net/netfilter/xt_IMQ.c

Tam w faq jest info o debianie:

6. I get some errors applying IMQ patchs to my Debian kernel source. What is going on?

Norbert Buchmuller pointed out that Debian kernel-source-* packages are not the same as the kernel.org kernels. These kernels have some patchs applied on then, so the IMQ patch fails on skbuff.h. Following is a snip from his e-mails about this issue:

No i tam jest jeszcze:

Debian's kernel-source-* packages are not the same as the vanilla kernel.org kernels. These kernels have some patches applied on them (eg. patches for discovered exploits).

In that particular case, the '__unused' member is used up by one of those patches, and then you have to allocate a new member for IMQ. You can make the changes by hand (on that particular file).

Tzn, co mam edytować i co zmienić?

Ostatnio edytowany przez morfik (2014-01-31 11:01:47)

enether · 2014-01-31 11:10:51

Na debianowe źródła nawet grsec się nie chce nałożyć ;) Zaciągnij vanilla z kernel.org

morfik · 2014-01-31 11:17:17

A te debianowe nie są lepsze z tymi fixami co tam dodają?

enether · 2014-01-31 11:54:05

Nigdy się specjalnie nie zagłębiałem ale nie zauważyłem różnicy. Zawsze priorytetem był dla mnie działający grsec zamiast pomniejszego tuningu devów.

Piotr3ks · 2014-01-31 13:02:18

Potwierdzam, grsec gryzie się z łatami nałożonymi na standardowe jajko debianowe. Jajko z kernel.org się bez problemu patchowało.

EDIT:
Być może podobnie jest w przypadku IMQ.

Ostatnio edytowany przez Piotr3ks (2014-01-31 13:08:31)

Jacekalex · 2014-01-31 16:28:34

Ja tylko dodam, że łatki z linuximq w ogóle nieczęsto działają bezproblemowo,
o wiele lepsze łatki imq można znaleźć na dev.openwrt.org, gdzie były zawsze trochę "oszlifowane".
Ostatni raz miałem do czynienia z IMQ na jaju 3.2.
Łatki były tutaj:
https://dev.openwrt.org/browser/trunk/target/linux/ … mp;order=name
EDIT:
Teraz IMQ w ogóle tam nie widzę. ;P

Teraz z resztą np na jakiś router też brałbym 3.2 + stabilny-grsec + imq,
może dałoby się na to jajo też L7 wyczesać.

Ostatnio edytowany przez Jacekalex (2014-02-01 04:11:07)

morfik · 2014-01-31 18:07:38

Na linux-3.12.9 ze strony kernela też weszło, w sumie to chciałbym to zrobić na tym kernelu z debiana tylko nie mam pojęcia gdzie szukać tego '__unused' , bo piszą, że to można ręcznie dostosować i dlatego się pluje, bo te patche debianowe to wykorzystują.

Póki co skonfigurowałem to jako tako i się kompiluje, za parę godzin skończy xD

Jacekalex · 2014-02-01 00:15:58

Z ta całą zabawą z IMQ - tc trochę sobie walisz w stopę z granatnika :D

Powód jest taki, że w jaju 3.13 jest nowy model podsystemu sieciowego - nftables.
A ten ma integrować w jednym interfejsie firewalla, routing, zarządzanie pasmem i priorytetami pakietów.

Więc ta cala zabawa za kilka wersji jajka może być potrzebna psu na budę. ;)

Sznurki:
http://en.wikipedia.org/wiki/Nftables
http://netfilter.org/projects/nftables/
http://lwn.net/Articles/570921/

I oczywiście wiki Archa:
https://wiki.archlinux.org/index.php/Nftables

Ostatnio edytowany przez Jacekalex (2014-02-01 01:06:11)

morfik · 2014-02-01 01:58:36

Zanim debian przejdzie na to nowe wszystko, to minie z 5 lat. xD

Jacekalex · 2014-02-01 04:04:32

Najwyżej 2 albo tylko jeden.
Stabilny Jessie będzie na jakim jaju będzie?
Ma wyjść jesienią tego roku.
Nowe jajo masz raz na dwa tygodnie, zmiana numerka w drugim polu to kwestia dwóch miesięcy.
Czyli jajo 3.15 - 3.17 i nowy podsystem sieciowy NFtables.
I być może wreszcie stabilny Wayland, niedawno wyszła 1.4, stabilny ma być 2.0, kolejne wersje średnio co miesiąc.

Debian też powoli leczy się z czasów naftalinowatego, a w dodatku nie siedzisz na stabilnym, tylko na testingu albo sidzie, czyli jajo 3.13 się kłania w tej chwili.
Pozostaje pytanie, ile wersji będzie miało 2 firewalle na raz.
Moim zdaniem najwyżej 5, choć nie wykluczone, że iptables odfrunie dopiero w Linuxie-4.0, a kiedy wyjdzie ta wersja? Podobno, jak Linusowi się skończą palce do liczenia tej wersji, czyli 3.21. :D
Ale równie dobrze to może być 3.16.

Moim zdaniem Iptables ma przed sobą najwyżej rok.

Lepiej pobaw się systemem ip netns - torrenta wywalisz na osobny podsystem sieciowy, będzie miał własny IP, i pięknie go obetniesz w obu kierunkach adresem IP, co da się zrobić na IFB, bez firewalla obecnie.

Kompilacja jajek w Debianie zbyt wygodna nie jest, a jak zaczniesz się bawić łatkami IMQ i L7, to szybko Ci przejdzie, tak samo, jak mnie kiedyś. ;P

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-02-01 04:07:41)

mati75 · 2014-02-01 09:12:03

Jacekalex napisał(-a):
Stabilny Jessie będzie na jakim jaju będzie?
Ma wyjść jesienią tego roku.

3.14. Ma być mrożony w listopadzie, więc wydany gdzieś będzie w marcu przyszłego roku.

Jacekalex · 2014-02-01 10:02:46

3.14 w listopadzie?
Wtedy aktualne jajo, to będzie co najmniej 3.15 lub 3.16, nowej jajka wychodzą co jakieś 10-12 tygodni na oko.
A mamy właśnie 1 luty, więc jeszcze do 1 listopada już tylko 9 miechów zostało.
Ewentualnie już w ~lipcu zaczną robić backporty do Jessie, tak jak Wheezy poprzednio, grubo ponad miesiąc przed premierą, patrzę, już jest repo wheezy-backports. :DDD

W tej premierze Jessiego Nftables i Wayland mogą nieźle zamieszać. ;)

Zdecydowali się już w końcu w zakresie Systemd|OpenRC|Upstart,
czy to dopiero w czasie premiery stabilnego Sida się okaże? :D

Ostatnio edytowany przez Jacekalex (2014-02-01 12:47:27)

mati75 · 2014-02-01 10:08:37

Jak wiadomo jądra z parzystymi numerkami są stabilne, więc prawdopodobnie będzie jak w przypadku wheezy, czyli dadzą najbardziej przetestowaną wersję.

Jacekalex tak poza tym nie załapałeś. 5 listopada zostanie zamrożone repozytorium testowe, czyli nie będą trafiać nowe wersję pakiety, tylko ewentualne poprawki do wersji aktualnie dostępnych. Wróżąc na podstawie ilości RC bugs to się spodziewać nowego wydania w marcu/kwietniu 2015. Repozytoria gdzieś w lutym zaczną się tworzyć.

Zdecydowali się już w zakresie Systemd|OpenRC|Upstart, czy to dopiero w Sidzie się okaże?

Trwa głosowanie.

Jacekalex · 2014-02-01 12:36:35

Chyba raczej parzyste były stabilne w czasach linii 2.x
2.4
2.6 - stabilne.
2.3
2.5 - testowe.

Obecnie Latest Stable Kernel nosi numerek 3.13.1.

Jacekalex napisał(-a):
Zdecydowali się już w końcu w zakresie Systemd|OpenRC|Upstart,
czy to dopiero w czasie premiery stabilnego Sida się okaże? :D

Czyli w stabilnym Sidzie już będzie pewne na 100% :DDDDD

mati75 napisał(-a):
Jacekalex tak poza tym nie załapałeś. 5 listopada zostanie......

Od pierwszego lutego do pierwszego listopada moim zdaniem jest równiutkie 9 miesięcy, czyli jak dziś spłodzisz conieco.... :D
A nowy numer jajka 3.xx jest co max 2-3 miechy, także 3.16 spodziewam się w październiku, o ile L.T. nie walnie wcześniej wersji 4.0, bo już conieco się o tym mówi.
Zwłaszcza, jakby np w 3.15 wywalili iptables - i zostałby tylko nftables + iptables=>nftables rules translator, to ekipa Debiana będzie miała uśmiech od ucha do ucha. ;)

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-02-01 12:45:54)

morfik · 2014-02-01 16:22:59

No ja nie siedzę na stabilnym ale cała rzesza ludzi siedzi, bo się boją testinga. :]

Lepiej pobaw się systemem ip netns - torrenta wywalisz na osobny podsystem sieciowy, będzie miał własny IP, i pięknie go obetniesz w obu kierunkach adresem IP, co da się zrobić na IFB, bez firewalla obecnie.

Się pobawię, jak tylko ogarnę miljart rzeczy, które ... wymagają ogarnięcia i dowiem się co to "ip netns". xD Spokojnie, nie wszystko naraz. Tak czy inaczej mi ta kontrola ruchu zostanie, nieważne co by się zmieniło, to się tylko dostosuje później.

Ostatnio edytowany przez morfik (2014-02-01 16:23:44)

gindek · 2014-02-01 16:58:29

Jacekalex napisał(-a):
Sznurki:
http://en.wikipedia.org/wiki/Nftables
http://netfilter.org/projects/nftables/
http://lwn.net/Articles/570921/

I oczywiście wiki Archa:
https://wiki.archlinux.org/index.php/Nftables

dobre info, nie wiedzialem o tym.

linuxbox · 2014-05-23 22:59:17

Witam czy już ktoś z Was bawił się nftables bo mam w sumie dwa pytania:
Czy w stosowanych regułach rule idzie stosować invert tak jak to jest w iptables czyli ! bo nie potrafię w helpie tego wyczytać.
A drugie pytanie to chodzi o nftables set
Tworzę nowy zbiór set nft add set filter auth { type \;} i teraz co trzeba podać po type bo tez przekopałem cały net i jedynie na co natrafiłem to ta strona

https://home.regit.org/netfilter-en/nftables-quick-howto/

nft add set filter ipv4_ad { type ipv4_address\;} tylko że to nie działa.

Jacekalex · 2014-07-10 08:50:43

Tu jest oficjalna dokumentacja:
http://people.netfilter.org/wiki-nftables/index.php/Main_Page

A tutaj o setach:
http://people.netfilter.org/wiki-nftables/index.php/Sets

Przy czym Nftables w dalszym ciągu ma może z 30% funkcjonalności Iptables, np w setach Nftables nie widzę timeout, poza tym nie widać tam hashlimita i connlimita.

Także Nftables, to raczej przyszłość, chociaż już wyraźnie widoczna na horyzoncie.

grzmot · 2014-08-04 10:32:30

Witam serdecznie,

Mam problem z nałożeniem patch imq na jądro z www.kernel.org, na jądrze z debian też nie siada. Nowych poprawek do imq nie ma w git. Ktoś ma jakiś pomysł ja ruszyc temat? Jądro musi być w miarę nowe żeby działało irqbalance.

root@debian:/usr/src/linux-3.12.26# patch -p1 < ../linux-3.12.4-imq.diff
patching file drivers/net/Kconfig
patching file drivers/net/Makefile
patching file drivers/net/imq.c
patching file include/linux/imq.h
patching file include/linux/netfilter/xt_IMQ.h
patching file include/linux/netfilter_ipv4/ipt_IMQ.h
patching file include/linux/netfilter_ipv6/ip6t_IMQ.h
patching file include/linux/skbuff.h
Hunk #6 succeeded at 2660 (offset 7 lines).
patching file include/net/netfilter/nf_queue.h
patching file include/uapi/linux/netfilter.h
patching file net/core/dev.c
Hunk #2 succeeded at 2604 (offset 6 lines).
patching file net/core/skbuff.c
Hunk #1 succeeded at 75 with fuzz 2 (offset 2 lines).
Hunk #2 succeeded at 3377 with fuzz 2 (offset 3282 lines).
Hunk #3 FAILED at 656.
Hunk #4 FAILED at 788.
Hunk #5 FAILED at 3191.
3 out of 5 hunks FAILED -- saving rejects to file net/core/skbuff.c.rej
patching file net/ipv6/ip6_output.c
patching file net/netfilter/Kconfig
patching file net/netfilter/Makefile
patching file net/netfilter/core.c
patching file net/netfilter/nf_internals.h
patching file net/netfilter/nf_queue.c
patching file net/netfilter/xt_IMQ.c

Jacekalex · 2014-08-04 10:43:36

Może obejdzie się bez IMQ w przyszłości.

Próbował ktoś tej latki?
https://github.com/mirrors/openwrt/blob/master/targ … onnmark.patch

Jest na jajo 3.14 nas razie, trzeba też łatać iproute, ale wygląda nawet ciekawiej, niż iMQ.
Zastanawiam się, jak zapukać na LKML, żeby ten drobiazg trafił do vaniliowego kernela, moim zdaniem już dawno powinien tam być.

morfik · 2014-08-04 11:07:42

grzmot -- na debianowe jajo się nie da założyć tego patcha z imq, bo koliduje on z jakimiś tam innymi patchami, które devy debiana założyły. A na tego z kernel.org, to musisz mieć te same numerki.

grzmot · 2014-08-04 11:38:54

To na tą chwilę pozostaje tylko eksperymentowanie z https://github.com/mirrors/openwrt/blob/master/targ … onnmark.patch czy ma ktoś inny pomysł jeszcze? A tak będzie trzeba się bawić z przerabianiem skryptów no i nie wiadomo czy zadziała.

Jest coś takiego jak ifb (sukcesor IMQ)? Testował ktoś to zamiast IMQ?

Ostatnio edytowany przez grzmot (2014-08-04 13:36:31)

morfik · 2014-08-04 17:38:23

Ja używam ifb ale to ma jedną wadę -- ruch przychodzący na interfejsie ifb pojawia się zanim iptables zdąży go złapać, czyli najpierw pakiety trafiają do ifb a potem do iptables i co za tym idzie, nie da rady przy pomocy iptables zarządzać ruchem przychodzącym do maszyny (oznaczać pakietów), tak jak to ma miejsce w przypadku ruchu wychodzącego i trzeba korzystać z tych selektorów u8 u16 i u32, które są dostępne w tc. Rzuć se okiem na ten mój text http://dug.net.pl/tekst/270/ .

Jacekalex · 2014-08-04 23:56:34

Z IFB jest ten problem, że pakiety nie trafiają do IFB wcześniej, niż do Firewalla, kłopot jest w tym, że w tablicy mangle-PREROUTING nie ma żadnego uchwytu funkcji, który dałby szansę na zakwalifikowanie pakietu do odpowiedniej kolejki na IFB.

Zobaczcie tą łatkę, która dodaje filtr w TC bazujący na CONNMARK.
On właśnie dotyczy tego problemu - kolejek dla pakietów przychodzących w oparciu o tablicę śledzenia połączeń netfiltera.
W sumie dość logiczne rozwiązanie, unikalny CONNMARK dla procesu można ustalić przy pomocy Cgroup net_cls na FW.

morfik · 2014-08-05 15:01:40

Ja wgrałem sobie te łatę 621-sched_act_connmark.patch na kernela debianowego -- weszła bez problemu, kernel się zbudował, moduł jest:

Kod:

$ cat /boot/config-3.14.13-ifb | grep -i connmark
CONFIG_NETFILTER_XT_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NET_ACT_CONNMARK=m

Ładuje się również:

Kod:

morfik:~$ lsmod | grep -i connmark
act_connmark           12566  0
xt_connmark            12637  2
nf_conntrack           83183  11 xt_CT,act_connmark,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,xt_connmark,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6
x_tables               23008  23 ip6table_filter,xt_mark,xt_CT,ip6table_mangle,xt_comment,xt_recent,ip_tables,xt_tcpudp,xt_limit,xt_owner,xt_conntrack,xt_LOG,xt_nat,xt_set,xt_multiport,iptable_filter,ip6table_raw,xt_connmark,ipt_REJECT,iptable_mangle,ip6_tables,iptable_raw,ip6t_REJECT

Reguły w iptables mam poniższe:

Kod:

    iptables -t mangle -N control_out

    iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
    iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT

    iptables -t mangle -A POSTROUTING -j CONNMARK --restore-mark
    iptables -t mangle -A POSTROUTING -m mark ! --mark 0 -j ACCEPT
    iptables -t mangle -A POSTROUTING -j control_out
    iptables -t mangle -A control_out -s 192.168.1.0/24 -d 192.168.1.0/24 -j MARK --set-mark 10
    iptables -t mangle -A control_out -s 192.168.1.0/24 -d 192.168.1.0/24 -j RETURN
    iptables -t mangle -A control_out -m owner --gid-owner p2p -j MARK --set-mark 3
    iptables -t mangle -A control_out -m owner --gid-owner p2p -j RETURN
    iptables -t mangle -A control_out -m owner --gid-owner morfik -j MARK --set-mark 4
    iptables -t mangle -A control_out -m owner --gid-owner morfik -j RETURN
    iptables -t mangle -A control_out -m owner --gid-owner root -j MARK --set-mark 5
    iptables -t mangle -A control_out -m owner --gid-owner root -j RETURN
    iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

I przekierowanie w tc mam przy pomocy poniższych linijek:

Kod:

    tc filter add dev ifb0 protocol ip parent 1:0 prio 5 handle 2 fw classid 1:200
    tc filter add dev ifb0 protocol ip parent 1:0 prio 90 handle 3 fw classid 1:300
    tc filter add dev ifb0 protocol ip parent 1:0 prio 20 handle 4 fw classid 1:400
    tc filter add dev ifb0 protocol ip parent 1:0 prio 10 handle 5 fw classid 1:500
    tc filter add dev ifb0 protocol ip parent 1:0 prio 100 handle 10 fw classid 1:1000

    tc filter add dev ifb1 protocol ip parent 2:0 prio 5 handle 2 fw classid 2:200
    tc filter add dev ifb1 protocol ip parent 2:0 prio 90 handle 3 fw classid 2:300
    tc filter add dev ifb1 protocol ip parent 2:0 prio 20 handle 4 fw classid 2:400
    tc filter add dev ifb1 protocol ip parent 2:0 prio 10 handle 5 fw classid 2:500
    tc filter add dev ifb1 protocol ip parent 2:0 prio 100 handle 10 fw classid 2:1000

I nie chce przekierować tych pakietów przychodzących do odpowiednich kolejek. Wychodzące zaś trafiają gdzie powinny. Coś jeszcze trzeba dopisać gdzieś?

Forum Debian Users Gang

Ogłoszenie

#1 2014-01-31 11:01:24

morfik - Cenzor wirtualnego świata

Błąd przy nakładaniu patcha IMQ

Kod:

#2 2014-01-31 11:10:51

enether - wiecznie niewyspany

Re: Błąd przy nakładaniu patcha IMQ

#3 2014-01-31 11:17:17

morfik - Cenzor wirtualnego świata

Re: Błąd przy nakładaniu patcha IMQ

#4 2014-01-31 11:54:05

enether - wiecznie niewyspany

Re: Błąd przy nakładaniu patcha IMQ

#5 2014-01-31 13:02:18

Piotr3ks - Też człowiek :-)

Re: Błąd przy nakładaniu patcha IMQ

#6 2014-01-31 16:28:34

Jacekalex - Podobno człowiek...;)

Re: Błąd przy nakładaniu patcha IMQ

#7 2014-01-31 18:07:38

morfik - Cenzor wirtualnego świata

Re: Błąd przy nakładaniu patcha IMQ

#8 2014-02-01 00:15:58

Jacekalex - Podobno człowiek...;)

Re: Błąd przy nakładaniu patcha IMQ

#9 2014-02-01 01:58:36

morfik - Cenzor wirtualnego świata

Re: Błąd przy nakładaniu patcha IMQ

#10 2014-02-01 04:04:32

Jacekalex - Podobno człowiek...;)

Re: Błąd przy nakładaniu patcha IMQ

#11 2014-02-01 09:12:03

mati75 - Psuj

Re: Błąd przy nakładaniu patcha IMQ

Jacekalex napisał(-a):

#12 2014-02-01 10:02:46

Jacekalex - Podobno człowiek...;)

Re: Błąd przy nakładaniu patcha IMQ

#13 2014-02-01 10:08:37

mati75 - Psuj

Re: Błąd przy nakładaniu patcha IMQ

#14 2014-02-01 12:36:35

Jacekalex - Podobno człowiek...;)

Re: Błąd przy nakładaniu patcha IMQ

Jacekalex napisał(-a):

mati75 napisał(-a):

#15 2014-02-01 16:22:59

morfik - Cenzor wirtualnego świata

Re: Błąd przy nakładaniu patcha IMQ

#16 2014-02-01 16:58:29

gindek - Zubr, bydle na etacie.

Re: Błąd przy nakładaniu patcha IMQ

Jacekalex napisał(-a):

#17 2014-05-23 22:59:17

linuxbox - Użytkownik

Re: Błąd przy nakładaniu patcha IMQ

#18 2014-07-10 08:50:43

Jacekalex - Podobno człowiek...;)

Re: Błąd przy nakładaniu patcha IMQ

#19 2014-08-04 10:32:30

grzmot - Nowy użytkownik

Re: Błąd przy nakładaniu patcha IMQ

#20 2014-08-04 10:43:36

Jacekalex - Podobno człowiek...;)

Re: Błąd przy nakładaniu patcha IMQ

#21 2014-08-04 11:07:42

morfik - Cenzor wirtualnego świata

Re: Błąd przy nakładaniu patcha IMQ

#22 2014-08-04 11:38:54

grzmot - Nowy użytkownik

Re: Błąd przy nakładaniu patcha IMQ

#23 2014-08-04 17:38:23

morfik - Cenzor wirtualnego świata

Re: Błąd przy nakładaniu patcha IMQ

#24 2014-08-04 23:56:34

Jacekalex - Podobno człowiek...;)

Re: Błąd przy nakładaniu patcha IMQ

#25 2014-08-05 15:01:40