форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Помогите с libipq"
Сообщение от havester on 26-Май-03, 11:47  (MSK)
Значит решил я зантся перехватом пакетов с помощью ip_queue. Скачал последний iptables 1.2.8 поставил. Подключил include <libipq.h> И скопировал прогу из man libipq. Результате Kdevelop сообщает - на все функции libipq - unknoun referens for this funktion. Я конечно новичок в программировании под Линукс, но вот прям сразу такая ошибка :(
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Помогите с libipq"
Сообщение от Olej on 26-Май-03, 15:20  (MSK)
>Значит решил я зантся перехватом пакетов с помощью ip_queue. >Скачал последний iptables 1.2.8 поставил. >Подключил include <libipq.h> >И скопировал прогу из man libipq. >Результате Kdevelop сообщает - на все функции libipq - unknoun referens for >this funktion. > >Я конечно новичок в программировании под Линукс, но вот прям сразу такая >ошибка :( Какая "такая"? Скорее всего, gcc нужно ручками указать (ключ "-l"-эл) использовать библиотеку libipq... Попутный вопроса: а чего все (несколько раз уже видел на разных форумах) "вцепились" в эту libipq? Что в ней такого есть, чего нет, например, в libpcap и BPF (Bercley Packet Filter) - у этого tools-а, по крайней мере, есть уже приличная история улучшений и усовершенствований, да и по оценкам производительности ОНО намного выше пакетного сокета Linux и др. ... Так всё же?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Помогите с libipq"
	Сообщение от havester on 26-Май-03, 17:51  (MSK)
	>Какая "такая"? Скорее всего, gcc нужно ручками указать (ключ "-l"-эл) использовать библиотеку >libipq... >Попутный вопроса: а чего все (несколько раз уже видел на разных форумах) >"вцепились" в эту libipq? Что в ней такого есть, чего нет, >например, в libpcap и BPF (Bercley Packet Filter) - у этого >tools-а, по крайней мере, есть уже приличная история улучшений и усовершенствований, >да и по оценкам производительности ОНО намного выше пакетного сокета Linux >и др. ... > >Так всё же? Значит по форумам ходит мнение, что libpcap, как и другие сниферы - при большой нагрузки просто теряют пакеты. То есть пакеты то проходят через интерфейс, однако они не регистрируются libpcap. Вот этого то и лишена libipq. Без подтверждения со стороны libipq пакет просто не уйдет. Извини за глупость но что за параметр -l? Расскажи поподробнее?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Помогите с libipq"
	Сообщение от Olej on 26-Май-03, 18:21  (MSK)
	>Извини за глупость но что за параметр -l? Расскажи поподробнее? library, напр.: gcc ... -lsocket -Bstatic ... - собирать, статически прилинковавши libsocket.so
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Помогите с libipq"
	Сообщение от havester on 27-Май-03, 09:24  (MSK)
	Вроде запустил эту библу :) Однако удивлен получаемыми данными. - ссылкой на данные. Как из них выдернуть пакет в удобочитаемой форме. Хотнлось бы конечо чтобы сразу разбивал на TCP->http    ->ftp    ->pop3    ->и т.д. UDP ICMP и т.д. Есть ли такие библы?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Помогите с libipq"
	Сообщение от J on 27-Май-03, 12:29  (MSK)
	>Вроде запустил эту библу :) >Однако удивлен получаемыми данными. - ссылкой на данные. >Как из них выдернуть пакет в удобочитаемой форме. >Хотнлось бы конечо чтобы сразу разбивал на >TCP->http >   ->ftp >   ->pop3 >   ->и т.д. >UDP >ICMP >и т.д. > >Есть ли такие библы? все им на блюдечке с голубой каемочкой берете заголовок ip-пакета (или что там вытаскивает libipq) и разбираете его поля описание заголовка точно есть в каком-то из .h файлов в стандартном наборе инклюдов
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Помогите с libipq"
	Сообщение от havester on 27-Май-03, 15:54  (MSK)
	>все им на блюдечке с голубой каемочкой >берете заголовок ip-пакета (или что там вытаскивает libipq) и разбираете его поля > >описание заголовка точно есть в каком-то из .h файлов в стандартном наборе >инклюдов Да есть в ip.h есть tcp.h но нет http.h, udp.h,ftp.h и т.д. Но в них  только заголовки, а тело пакета?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Помогите с libipq"
	Сообщение от J on 27-Май-03, 16:45  (MSK)
	> >>все им на блюдечке с голубой каемочкой >>берете заголовок ip-пакета (или что там вытаскивает libipq) и разбираете его поля >> >>описание заголовка точно есть в каком-то из .h файлов в стандартном наборе >>инклюдов >Да есть в ip.h >есть tcp.h >но нет http.h, udp.h,ftp.h и т.д. >Но в них  только заголовки, а тело пакета? TCP, UDP, ICMP - разновидность IP-пакетов, внутри IP пакета находятся данные верхнего уровня модели OSI, внутри TCP-пакетов передаются данные ftp-сессий, например, и тд. Надо рассматривать все последовательно, разворачивая загоолвок за заголовком. Но на анализ контента, имхо, никаких ресурсов не хватит. /usr/include/linux/tcp.h /usr/include/netinet/tcp.h в tcp.h есть поле порта, а там вы уже сами сообразите, что sport или dport == 80 => http, ==25,110 => mail, == 21 => ftp (ftp работает и по более другим портам), 519 =>icq /usr/include/linux/udp.h /usr/include/netinet/udp.h 53 => squid все остальное нафиг не нужно icmp не содержит порта, содержит код, 7 - echo-request, например
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Помогите с libipq"
	Сообщение от havester on 27-Май-03, 17:09  (MSK)
	>TCP, UDP, ICMP - разновидность IP-пакетов, внутри IP пакета находятся данные верхнего >уровня модели OSI, внутри TCP-пакетов передаются данные ftp-сессий, например, и тд. >Надо рассматривать все последовательно, разворачивая загоолвок за заголовком. Но на анализ >контента, имхо, никаких ресурсов не хватит. > >/usr/include/linux/tcp.h >/usr/include/netinet/tcp.h >в tcp.h есть поле порта, а там вы уже сами сообразите, что sport или dport == 80 => http, ==25,110 => mail, == 21 => ftp (ftp работает и по более другим портам), 519 =>icq >/usr/include/linux/udp.h >/usr/include/netinet/udp.h >53 => squid >все остальное нафиг не нужно >icmp не содержит порта, содержит код, 7 - echo-request, например Спасибо. Остался один вопрос. Мне бы url из http и ftp?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "Помогите с libipq"
	Сообщение от Olej on 28-Май-03, 13:07  (MSK)
	>Остался один вопрос. Мне бы url из http и ftp? URL - не дам: самому искать надо, но вот ключевое слово ("заветное" ;-)) - пожалуйста: "RFC" - любой поисковик его знает... Это не в шутку, а всерьёз: единственный документ, заслуживающий доверия по любому из сетевых протоколов или механизмов - RFC (ну не Windows же HELP :D?). Читайте RFC! Там их, на сегодня, что-то около 3000 документов :-(, но есть средства отобрать по тематикам ... десятка полтора там будут и по HTTP/FTP.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "Помогите с libipq"
	Сообщение от Olej on 28-Май-03, 13:02  (MSK)
	>TCP, UDP, ICMP - разновидность IP-пакетов, внутри IP пакета находятся данные верхнего >уровня модели OSI, внутри TCP-пакетов передаются данные ftp-сессий, например, и тд. TCP, UDP, ICMP, IGMP etc. - это не "разновидности" - а автономные протоколы (например - они без изменения работают с IPv6) более высокого уровня транспортного протокола IP (у MS таким же образом над IP надстроено "одоробло" NETBEUI...). А TCP/IP - модели OSI не соответствует, раньше он создавался... и даже все искусственные попытки "натянуть" его на модель так и остались ... неадекватными ;-). >Надо рассматривать все последовательно, разворачивая загоолвок за заголовком. Но на анализ >контента, имхо, никаких ресурсов не хватит. Нет, ну точно: сейчас перепишут IP-стек... А что вы с пакетами MAC-уровня станете делать: ARP, RARP ... etc. - а их любой снифер (нормальный, см. BPF - libcap - tcpdump) также отлично перехватывает. Пацаны ... прекращайте чудить... "Спили мушку..." - как было сказано в одном умном месте...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	18. "Помогите с libipq"
	Сообщение от J on 29-Май-03, 12:14  (MSK)
	>>TCP, UDP, ICMP - разновидность IP-пакетов, внутри IP пакета находятся данные верхнего >>уровня модели OSI, внутри TCP-пакетов передаются данные ftp-сессий, например, и тд. > >TCP, UDP, ICMP, IGMP etc. - это не "разновидности" - а автономные >протоколы (например - они без изменения работают с IPv6) более высокого >уровня транспортного протокола IP (у MS таким же образом над IP >надстроено "одоробло" NETBEUI...). Я хотела сказать, что и TCP и UDP и ICMP и IGMP и GRE  и XTP и IPinIP - это все IP пакеты на более низком уровне, в отличие от ARP. > >А TCP/IP - модели OSI не соответствует, раньше он создавался... и даже >все искусственные попытки "натянуть" его на модель так и остались ... >неадекватными ;-). Соответствует, только не надо все принимать букваьлно. По крайней мере, он соответствует идеологии OSI, ее матрешечному принципу наслоения заголовков и работе с заголовками более высших уровней как с данными. >>Надо рассматривать все последовательно, разворачивая загоолвок за заголовком. Но на анализ >>контента, имхо, никаких ресурсов не хватит. > >Нет, ну точно: сейчас перепишут IP-стек... А вы пробовали? :-) Ну, хотя бы не глобально, а добавить поддержку нового вида протокола на основании имеющегося в линуксовом стеке протокола родственного типа? > >А что вы с пакетами MAC-уровня станете делать: ARP, RARP ... etc. >- а их любой снифер (нормальный, см. BPF - libcap - >tcpdump) также отлично перехватывает. Мне оно как бы ни к чему. Полезно только для диагностики хитрого девайса, который вечто забывает свой мак-адрес (но при это продолжает работать). Хинт - в tcpdump от слова tcp только название.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	20. "Помогите с libipq"
	Сообщение от Olej on 02-Июн-03, 13:33  (MSK)
	>Я хотела сказать, что и TCP и UDP и ICMP и IGMP >и GRE  и XTP и IPinIP - это все IP >пакеты на более низком уровне, в отличие от ARP. Если уж совсем точно, то не "низком", а "более высоком" (вплоть до прикладного, напр. HTTP)... но это уже дело вкуса ;-) >>А TCP/IP - модели OSI не соответствует, раньше он создавался... и даже >>все искусственные попытки "натянуть" его на модель так и остались ... >>неадекватными ;-). > >Соответствует, только не надо все принимать букваьлно. По крайней мере, он соответствует >идеологии OSI, ее матрешечному принципу наслоения заголовков и работе с заголовками >более высших уровней как с данными. А вот тут - позвольте с вами серьёзно не согласиться: НЕ СООТВЕСТВУЕТ (ну ... максимум - "чем-то похож") - об этом много писалось, и глухое "притягивание" модели OSI к IP часто приводит к серьёзным искажениям представлений о последнем... >>Нет, ну точно: сейчас перепишут IP-стек... > >А вы пробовали? :-) >Ну, хотя бы не глобально, а добавить поддержку нового вида протокола на >основании имеющегося в линуксовом стеке протокола родственного типа? 1.Конечно пробовал, я этими штучками ... обмен данных, сетевые протоколы etc. занимаюсь года с 1980 - всего насмотрелся и напробовался... 2. ... а потом года с 1984-го, потому как некому было этим тогда заниматься, читал спецкурс об этом subj аспирантам - "товарищам учёным", которые сейчас и пишут об subj статьи и книжки. 3."Не плодите понятий больше, чем сущностей..." (с) кажется А.Пуанкаре - если нужно только перехватывать пакеты (в самых разных модификациях), и для этого есть море tools - не нужно делать "свои протоколы" etc., лучше направить эту энергетику в более созидательное русло. >>А что вы с пакетами MAC-уровня станете делать: ARP, RARP ... etc. >>- а их любой снифер (нормальный, см. BPF - libcap - >>tcpdump) также отлично перехватывает. > >Мне оно как бы ни к чему. Полезно только для диагностики хитрого >девайса, который вечто забывает свой мак-адрес (но при это продолжает работать). Разговор был о "снифере" - полноценный снифер должен уметь делать перехват на ВСЕХ уровнях.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	22. "Помогите с libipq"
	Сообщение от J on 02-Июн-03, 15:47  (MSK)
	>Разговор был о "снифере" - полноценный снифер должен уметь делать перехват на >ВСЕХ уровнях. Как говорилось в ru.unix.bsd: hub - свитч первого уровня, а squid - пятого :-)))))) (шутка) То есть, по-вашему, сниффер должен получать все пакеты, собирать их в единое целое вплоть до 5 уровня и приподносить юзеру? Интересно, какой вычислительный комплекс понадобится, чтоб обработать несколькомегабит в секунду....
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "Помогите с libipq"
	Сообщение от Olej on 28-Май-03, 12:53  (MSK)
	>берете заголовок ip-пакета (или что там вытаскивает libipq) и разбираете его поля > >описание заголовка точно есть в каком-то из .h файлов в стандартном наборе >инклюдов "Ну вы блин даёте..." (с) Вы так что - хотите весь IP-стек по-новой переписать, когда вам всего-навсего нужно снифер пакетов?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "Помогите с libipq"
	Сообщение от havester on 28-Май-03, 14:23  (MSK)
	> >"Ну вы блин даёте..." (с) >Вы так что - хотите весь IP-стек по-новой переписать, когда вам всего-навсего >нужно снифер пакетов? В том то и дело что не хочу, поэтому и спраштваю. Про libpcap я уже писал, почему неподходит. Хотя, наверно, там есть функции которые бы мне помогли?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "Помогите с libipq"
	Сообщение от Olej on 28-Май-03, 16:37  (MSK)
	>В том то и дело что не хочу, поэтому и спраштваю. >Про libpcap я уже писал, почему неподходит. Хотя, наверно, там есть функции >которые бы мне помогли? Это "неподходит" ... неподходит - неубедительно: там где-то, какой-то Вася Пупкин говорит.... У меня на заборе такое понаписано! - если бы я всему верил... BPF, и все его производные: libcap, tcpdump - это profesional tools, которые отрабатываются - улучшаются уже лет 8, и настоящими профиссионалами ... поэтому то, что говорят "юные писаки" доморощенных якобы-сниферов для меня - не аргумент... Аргументы - где!?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Помогите с libipq"
	Сообщение от Olej on 28-Май-03, 12:45  (MSK)
	>Как из них выдернуть пакет в удобочитаемой форме. >Хотнлось бы конечо чтобы сразу разбивал на >TCP->http >   ->ftp >   ->pop3 >   ->и т.д. >UDP >ICMP >и т.д. > >Есть ли такие библы? Есто: BPF + libcap :D :D :D
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "Помогите с libipq"
	Сообщение от havester on 28-Май-03, 17:00  (MSK)
	>>Как из них выдернуть пакет в удобочитаемой форме. >>Хотнлось бы конечо чтобы сразу разбивал на >>TCP->http >>   ->ftp >>   ->pop3 >>   ->и т.д. >>UDP >>ICMP >>и т.д. >> >>Есть ли такие библы? > >Есто: BPF + libcap :D :D :D Хорошо. Вот такая ситуация. В машине 3 100 мб сетевухи, демон ВПН. Все это разруливается. А машина скажем целерон 600. Ты моежешь со 100% уверенностью сказать, что ни один из пакетов не уйдет от логирования в базу?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	16. "Помогите с libipq"
	Сообщение от Olej on 28-Май-03, 18:17  (MSK)
	>Хорошо. Вот такая ситуация. В машине 3 100 мб сетевухи, демон ВПН. > >Все это разруливается. А машина скажем целерон 600. >Ты моежешь со 100% уверенностью сказать, что ни один из пакетов не >уйдет от логирования в базу? 100% гарантии даёт только одна инстанция - морг! Это не я сказал, т.е. (с) - только источника не помню. Я слабо понимаю то, что сказано выше - что такое "разруливается", я понимаю, когда говорят: ICMP, IGMP, NAT-трансляция ... и т.п. - т.е. есть однозначная техническая терминология - давайте ею пользоваться. Почему не должно быть гарантии в каком-то (многократно, множеством людей выверенном) пакете, например BPF - и она вдруг должна появиться в какой-то самопалке? И число мгц. здесь не при чём - на какой частоте стек IP принимает/отсылает пакеты - на той же частоте BPF их перехватывает... поставим 4Ghz - всё то-же останется, только масштаб изменится. А пропуск (пропадание) пакетов в любом tools-е никак не является функцией технических характеристик (Mhz, Mb, Mbod etc.) - а только зависит от степени кривизны рук, которыми эту tools-у делали... А вообще: "вообще нет программ не содержащих ошибки - отличается только частота, с которой они проявляются при использовании..." (с) Э.Дейкстра - классика.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	17. "Помогите с libipq"
	Сообщение от havester on 29-Май-03, 09:24  (MSK)
	>>Хорошо. Вот такая ситуация. В машине 3 100 мб сетевухи, демон ВПН. >> >>Все это разруливается. А машина скажем целерон 600. >>Ты моежешь со 100% уверенностью сказать, что ни один из пакетов не >>уйдет от логирования в базу? > >100% гарантии даёт только одна инстанция - морг! >Это не я сказал, т.е. (с) - только источника не помню. > >Я слабо понимаю то, что сказано выше - что такое "разруливается", я >понимаю, когда говорят: ICMP, IGMP, NAT-трансляция ... и т.п. - т.е. >есть однозначная техническая терминология - давайте ею пользоваться. NAT трансляция, фильтрация пакетов, перенаправления пакетов. >Почему не должно быть гарантии в каком-то (многократно, множеством людей выверенном) пакете, >например BPF - и она вдруг должна появиться в какой-то самопалке? >И число мгц. здесь не при чём - на какой частоте >стек IP принимает/отсылает пакеты - на той же частоте BPF их >перехватывает... поставим 4Ghz - всё то-же останется, только масштаб изменится. Еще раз повторяю. Может случится что повиснет libpcap? Может. Тогда весь трафик пройдет мимо админа. >А пропуск (пропадание) пакетов в любом tools-е никак не является функцией технических >характеристик (Mhz, Mb, Mbod etc.) - а только зависит от степени >кривизны рук, которыми эту tools-у делали... А вообще: "вообще нет программ >не содержащих ошибки - отличается только частота, с которой они проявляются >при использовании..." (с) Э.Дейкстра - классика. Да не является пока машина справляется. А если у нее и без перехвата при 60% загрузки сети - занято 80% ресурсов. Что будет если поднимится загрузка на 3 картах до хотя бы 80%. Я так думаю что ядро посылать то пакеты будет, а вот отсанется ли процессорного времени на снифер... Сам привети достоверные данные не могу... Ну разве что посчитать пропускную способность PCI, проца и памяти. Но прошу так же предоставить ваши достоверные данные, а не утверждения что работало 10 лет, за 10 лет многое поменялось.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	21. "Помогите с libipq"
	Сообщение от Olej on 02-Июн-03, 13:45  (MSK)
	>>Почему не должно быть гарантии в каком-то (многократно, множеством людей выверенном) пакете, >>например BPF - и она вдруг должна появиться в какой-то самопалке? >>И число мгц. здесь не при чём - на какой частоте >>стек IP принимает/отсылает пакеты - на той же частоте BPF их >>перехватывает... поставим 4Ghz - всё то-же останется, только масштаб изменится. >Еще раз повторяю. Может случится что повиснет libpcap? Может. Тогда весь трафик >пройдет мимо админа. Может и так случиться ;-). Только...: - если это у вас под ВЫНЬ (чего-то мне так показалось) - то эта самая ВЫНЬ (какая бы она не была "устойчивая" - NT, 2000, XP) - "упадёт" до этого события уже 1000 раз, так что в падении Libcap ничего такого страшного (непривычного :D) и не будет... - упасть может любая прога, но ... см. выше того же Э.Дейкстру, он там ещё что-то про "ручки" говорил - любой "быстренький самопальный" снифер упадёт со 100 раз большей вроятностью, учитывая проработанность и отработанность BPF + libcap. >Да не является пока машина справляется. >А если у нее и без перехвата при 60% загрузки сети - >занято 80% ресурсов. >Что будет если поднимится загрузка на 3 картах до хотя бы 80%. >Я так думаю что ядро посылать то пакеты будет, а вот >отсанется ли процессорного времени на снифер... А я думаю как-раз наоборот: BPF в UNIX работает в режиме ядра ... и, если уж кому не станет хватать процессорного времени, так это пользовательскому приложению на "отправлять-принимать". Но, как я помню по опыту работы с BPF + tcpdump - они добавляли столь мало существенную нагрузку к общей загрузке, что это мало что значило. >Но прошу так же предоставить ваши достоверные данные, а не утверждения что >работало 10 лет, за 10 лет многое поменялось. 1. "мои достоверные данные" - это то, что достаточно периодическое использование BPF не даёт повода сомневаться... А доказывать (или ссылаться на утверждения) нужно "глюкавость", а не её отсутствие - презумпция невиновности. Ещё более достоверные гарантии ... так это только у инстанции ... см. выше ... ;-) 2. не "работало 10 лет" - а постоянно развивается и вылизывается на протяжении почти 10-ти лет... Как говорят в Одессе: "жениться и обещать жениться - это две большие разные вещи".
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	23. "Помогите с libipq"
	Сообщение от havester on 02-Июн-03, 18:37  (MSK)
	Ладно скажем по другому. Нужно не тольео перехватывать пакеты, но и складывать их. ВСЕ. Без исключения. И это уже надо делать насколько я понимаю именно моими ручками, какими они бы у меня ни были. И тут уже не важно какой будет снифирящее АПИ. Если криво напишу,буду пропускать пакеты. Но в случае с libpq я хоть буду уверен, что они дальше не пройдут. И мне сразу юзвери алертнут - нет сети. Так есть какие доки, пусть даже англоязычные, но объясняющие принцип работы libpcap. Кстати работаю под Линухом, пока.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	19. "Помогите с libipq"
	Сообщение от havester on 30-Май-03, 09:17  (MSK)
	> >Есто: BPF + libcap :D :D :D Кстати посоветую хорошую описалову по libpcap?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	24. "Помогите с libipq"
	Сообщение от Alexander_B on 07-Июл-03, 12:42  (MSK)
	>Вроде запустил эту библу :) Имею сейчас те же проблемы с libipq, взял пример из мана компилирую с     -lipq, а он мне все равно unresolved reference... Все облазил, не знаю что делать, подскажите кто-нибудь, пожалуйста...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.