forum.opennet.ru - "pptp, tcpdump, анализ пакета" (12)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"pptp, tcpdump, анализ пакета"

Форум Открытые системы на сервере (Сеть. проблемы, диагностика)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"pptp, tcpdump, анализ пакета"	+/–
Сообщение от LSTemp (ok) on 26-Апр-11, 21:41
Помогите, Уважаемые. Что-то у меня лыжи уже 3-й день не едут с расшифровкой одного значения пакета, перехваченного tcpdump-ом. клиент подключается по VPN (Linux, poptop, шифрование не используетя). схема соединения: [CLIENT 192.168.0.2 (192.168.10.2)]<-> [192.168.0.1 (192.168.200.1) SERVER NAT]<-> [77.234.201.242 OPENNET.RU] в круглых скобках указанны адреса, используемые для текущего VPN-соединения. ловим пакет на ethernet-интерфейсе, ч/з который подключен VPN-клиент: tcpdump -t -n -e -i eth1 -X "dst host 192.168.0.2 and proto 47" 00:14:d1:52:78:e4 > 00:17:31:58:dc:fd, ethertype IPv4 (0x0800), length 317: IP 192.168.0.1 > 192.168.0.2: call 0 seq 2293 gre-ppp-payload 0x0000: 4500 012f be49 4000 402f fa02 c0a8 0001 E../.I@.@/...... 0x0010: c0a8 0002 3001 880b 010f 0000 0000 08f5 ....0........... 0x0020: 2145 0001 0e97 d140 0035 06ca 914d eac9 !E.....@.5...M.. 0x0030: f2c0 a80a 0200 509e 64e2 6f8c fd26 95ac ......P.d.o..&.. 0x0040: 0250 18ff ff90 cd00 0048 5454 502f 312e .P.......HTTP/1. 0x0050: 3120 1. анализируем: ----------------------------- IP ----------------------------- 0x0000: 45.. => - версия протокола 4 - длина заголовка 5-ть 32-х битных слов (т.е заголовок без опциональных полей). => данные заголовка: 0x0000: 4500 012f be49 4000 402f fa02 c0a8 0001 0x0010: c0a8 0002 как и ожидалось: инкапсуляция = 0x2f = 47 (GRE) IP src = 0xc0 a8 00 01 = 192.168.0.1 IP dst = 0xc0 a8 00 02 = 192.168.0.2 ----------------------------- GRE: ----------------------------- 0x0010: .... .... 3001 => SF = 0x30 >> 4 & 1 = 1 (+2 слова к заголовку) AF = 0x01 >> 7 & 1 = 0 (+0 слов к заголовку) => данные заголовка: 0x0010: .... .... 3001 880b 010f 0000 0000 08f5 версия GRE = 0x01 & 7 = 1 инкапсуляция = 0x880b = PPP ... ----------------------------- ВНИМАНИЕ - ВОПРОС!!! ----------------------------- 0x0020: 21.. сразу после заголовка GRE. уже тучу RFC перерыл и инета... собственно с расшифровкой этого значения и застопорился. что за 0x21, откуда оно берется, что значит и какому заголовку относится? по идее на этом месте должен быть PPP-заголовок? далее опять все понятно и ожидаемо... ----------------------------- IP ----------------------------- 0x0020: ..45 => - версия протокола 4 - длина заголовка 5-ть слов => данные заголовка: 0x0020: ..45 0001 0e97 d140 0035 06ca 914d eac9 0x0030: f2c0 a80a 02.. инкапсуляция = 0x06 = 6 (TCP) IP src = 0x4d ea c9 f2 = 77.234.201.242 IP dst = 0xc0 a8 0a 02 = 192.168.10.2 ----------------------------- TCP ----------------------------- src port = 0x0050 = 80 ... собственно вот этот байт 0x21 @ 0x0020 никуда приткнуть и не могу. остальные поля во всех заголовках нормально расшифровываются, хоть я их и не приводил. подскажите, где я лыжи не смазал?
Ответить \| Правка \| Cообщить модератору

Оглавление

pptp, tcpdump, анализ пакета, LSTemp, 04:44 , 03-Май-11, (1)

pptp, tcpdump, анализ пакета, JohnProfic, 10:13 , 03-Май-11, (2)

pptp, tcpdump, анализ пакета, Aleks305, 20:29 , 03-Май-11, (3)

pptp, tcpdump, анализ пакета, JohnProfic, 20:46 , 03-Май-11, (4)

pptp, tcpdump, анализ пакета, LSTemp, 00:07 , 12-Май-11, (7)

pptp, tcpdump, анализ пакета, RSG, 12:02 , 13-Май-11, (11)

pptp, tcpdump, анализ пакета, JohnProfic, 20:47 , 03-Май-11, (5)

pptp, tcpdump, анализ пакета, LSTemp, 23:38 , 11-Май-11, (6)

pptp, tcpdump, анализ пакета, JohnProfic, 00:54 , 12-Май-11, (8)

pptp, tcpdump, анализ пакета, LSTemp, 02:13 , 12-Май-11, (9)

pptp, tcpdump, анализ пакета, JohnProfic, 16:18 , 12-Май-11, (10)

pptp, tcpdump, анализ пакета, LSTemp, 01:36 , 15-Май-11, (12)

Сообщения по теме [Сортировка по времени | RSS]

1. "pptp, tcpdump, анализ пакета" +/–

Сообщение от LSTemp (ok) on 03-Май-11, 04:44

up.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "pptp, tcpdump, анализ пакета" +/–

Сообщение от JohnProfic (ok) on 03-Май-11, 10:13

http://www.faqs.org/rfcs/rfc1661.html
http://www.faqs.org/rfcs/rfc1332.html

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "pptp, tcpdump, анализ пакета" +/–

Сообщение от Aleks305 (ok) on 03-Май-11, 20:29

> http://www.faqs.org/rfcs/rfc1661.html
> http://www.faqs.org/rfcs/rfc1332.html
а зачем вы все это делаете???я вот вообще первый раз вижу, что кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные значения, что чему соответствует, где читали? интересно было бы почитать

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "pptp, tcpdump, анализ пакета" +/–

Сообщение от JohnProfic (ok) on 03-Май-11, 20:46

>> http://www.faqs.org/rfcs/rfc1661.html
>> http://www.faqs.org/rfcs/rfc1332.html
> а зачем вы все это делаете???я вот вообще первый раз вижу, что
> кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные
> значения, что чему соответствует, где читали? интересно было бы почитать
Для меня в данном конкретном случае -- спортивный интерес. А так иногда бывает, что какой-нибудь сервис не работает как нужно и в логи ничего толком не пишет (вспоминается Samba старых версий). И как назло в tcpdump/wireshark нет диссектора (или он неполон) для этого протокола.
Или это вообще не сетевой протокол, а какой-нибудь файл в специфическом формате (вспоминается xls/doc/dbf и т.п.) и библиотек под нужный ЯП либо нет, либо они не умеют делать, то что тебе нужно (такое правда у меня было давно).

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "pptp, tcpdump, анализ пакета" +/–

Сообщение от LSTemp (ok) on 12-Май-11, 00:07

>[оверквотинг удален]
>> кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные
>> значения, что чему соответствует, где читали? интересно было бы почитать
> Для меня в данном конкретном случае -- спортивный интерес. А так иногда
> бывает, что какой-нибудь сервис не работает как нужно и в логи
> ничего толком не пишет (вспоминается Samba старых версий). И как назло
> в tcpdump/wireshark нет диссектора (или он неполон) для этого протокола.
> Или это вообще не сетевой протокол, а какой-нибудь файл в специфическом формате
> (вспоминается xls/doc/dbf и т.п.) и библиотек под нужный ЯП либо нет,
> либо они не умеют делать, то что тебе нужно (такое правда
> у меня было давно).
для меня тоже больше спортивный в данном случае.
задача стояла настроить шейпинг poptop-клиентов, которые без шифрования подключаются. неиспользуемая ширина канала должна распределяться м/ду клиентами без использования imq (его просто нет - сервак старый, ядро старое и пересобирать все - себе дороже). поэтому ясное дело - единственный выход ставить фильтры на физический интерфейс. в принципе фильтра вида:
u32 match ip protocol 47 0xff match ip dst $LAN_DST/32
вполне достаточно для решения задачи. чем там клиент грузит выделенную ему полосу внутри туннеля - его дело.
просто ради интереса задумался о возможности анализа пакетов внутри этого туннеля (он ведь не шифрованный) для приоритезации определенных сервисов (HTTP например).
ИМХО в принципе задача решаема, но кучу фильтров ставить надо будет. еще следует учитывать, что заголовки пакетов могут иметь разную длину (теоритически. фактически - это скорее исключение в данной реализации), что либо еще фильтров добавит, либо просто некоторая (очень небольшая часть) нужного пройдет мимо фильтра. в общем даже такое извращение похоже можно реализовать...

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

11. "pptp, tcpdump, анализ пакета" +/–

Сообщение от RSG (ok) on 13-Май-11, 12:02

>Что-то у меня лыжи уже 3-й день не едут с расшифровкой одного значения пакета, перехваченного tcpdump-ом
>> для меня тоже больше спортивный в данном случае.
Люди, а не проще было бы сделать стенд (хоть на виртуалках), запустить снифер (вирешарк например), который все поля в соответствие с RFC сам разбирает и описывает их?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

5. "pptp, tcpdump, анализ пакета" +/–

Сообщение от JohnProfic (ok) on 03-Май-11, 20:47

>> http://www.faqs.org/rfcs/rfc1661.html
>> http://www.faqs.org/rfcs/rfc1332.html
> а зачем вы все это делаете???я вот вообще первый раз вижу, что
> кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные
> значения, что чему соответствует, где читали? интересно было бы почитать
А разбирать в основном описания протоколов и форматов либо открыты, либо в Сети можно найти их описание.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "pptp, tcpdump, анализ пакета" +/–

Сообщение от LSTemp (ok) on 11-Май-11, 23:38

> http://www.faqs.org/rfcs/rfc1661.html
> http://www.faqs.org/rfcs/rfc1332.html
спасибо конечно за ссылки), но я уже писал, что rfc читал (не один год их уже читаю) - этому свидетельство моя приведенная расшифровка пакета. к тому же, учитывая наличие GRE и его несколько специфичную реализацию в poptop, данных ссылок явно недостаточно для ответа.
вопрос уперся только в одно значение, которое я понять не могу. не надо ссылок - просто если знаете (или есть предположения), то просто скажите что это такое.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

8. "pptp, tcpdump, анализ пакета" +/–

Сообщение от JohnProfic (ok) on 12-Май-11, 00:54

>> http://www.faqs.org/rfcs/rfc1661.html
>> http://www.faqs.org/rfcs/rfc1332.html
> спасибо конечно за ссылки), но я уже писал, что rfc читал (не
> один год их уже читаю) - этому свидетельство моя приведенная расшифровка
> пакета. к тому же, учитывая наличие GRE и его несколько специфичную
> реализацию в poptop, данных ссылок явно недостаточно для ответа.
> вопрос уперся только в одно значение, которое я понять не могу. не
> надо ссылок - просто если знаете (или есть предположения), то просто
> скажите что это такое.
Из того, что я понял:
После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит из поля протокола, занимающего 1 или 2 байта и всякого мусора. Значение 0x21 для поля протокола: IP-пакет (вторая ссылка).

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "pptp, tcpdump, анализ пакета" +/–

Сообщение от LSTemp (ok) on 12-Май-11, 02:13

>[оверквотинг удален]
>> один год их уже читаю) - этому свидетельство моя приведенная расшифровка
>> пакета. к тому же, учитывая наличие GRE и его несколько специфичную
>> реализацию в poptop, данных ссылок явно недостаточно для ответа.
>> вопрос уперся только в одно значение, которое я понять не могу. не
>> надо ссылок - просто если знаете (или есть предположения), то просто
>> скажите что это такое.
> Из того, что я понял:
> После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит
> из поля протокола, занимающего 1 или 2 байта и всякого мусора.
> Значение 0x21 для поля протокола: IP-пакет (вторая ссылка).
подробней можно по 2-й ссылке (цитату) - у меня видимо лыжи не едут совсем на этот вопрос... глаз замылился. 0x21 - ОДИН байт (не 0x0021). где там оно в rfc?
хотя думаю, что скорее всего Вы правы. надо просто исходник poptop поглядеть (так не хотелось, но придется - дело принципа :)). наверное дело в реализации... спасибо.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "pptp, tcpdump, анализ пакета" +/–

Сообщение от JohnProfic (ok) on 12-Май-11, 16:18

>> Из того, что я понял:
>> После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит
>> из поля протокола, занимающего 1 или 2 байта и всякого мусора.
>> Значение 0x21 для поля протокола: IP-пакет (вторая ссылка).
> подробней можно по 2-й ссылке (цитату) - у меня видимо лыжи не
> едут совсем на этот вопрос... глаз замылился. 0x21 - ОДИН байт
> (не 0x0021). где там оно в rfc?
> хотя думаю, что скорее всего Вы правы. надо просто исходник poptop поглядеть
> (так не хотелось, но придется - дело принципа :)). наверное дело
> в реализации... спасибо.
Из 1-й ссылки про поле протокола:

      The Protocol field is one or two octets, and its value identifies
      the datagram encapsulated in the Information field of the packet.
      The field is transmitted and received most significant octet
      first.
      The structure of this field is consistent with the ISO 3309
      extension mechanism for address fields.  All Protocols MUST be
      odd; the least significant bit of the least significant octet MUST
      equal "1".  Also, all Protocols MUST be assigned such that the
      least significant bit of the most significant octet equals "0".
      Frames received which don't comply with these rules MUST be
      treated as having an unrecognized Protocol.

Из второго абзаца я понял, что первый байт из 0x0021 можно опускать, если он равен 0x00.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

12. "pptp, tcpdump, анализ пакета" +/–

Сообщение от LSTemp (ok) on 15-Май-11, 01:36

>[оверквотинг удален]
>       equal "1".  Also, all Protocols
> MUST be assigned such that the
>       least significant bit of the most
> significant octet equals "0".
>       Frames received which don't comply with
> these rules MUST be
>       treated as having an unrecognized Protocol.
>
> Из второго абзаца я понял, что первый байт из 0x0021 можно опускать,
> если он равен 0x00.
Мой земной поклон и благодарность. Глаз замылился/читал книгу - фидел фигу/итд ). Еще раз спасибо огромное.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "pptp, tcpdump, анализ пакета"	+/–
Сообщение от LSTemp (ok) on 03-Май-11, 04:44
up.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от JohnProfic (ok) on 03-Май-11, 10:13
	http://www.faqs.org/rfcs/rfc1661.html http://www.faqs.org/rfcs/rfc1332.html
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от Aleks305 (ok) on 03-Май-11, 20:29
	> http://www.faqs.org/rfcs/rfc1661.html > http://www.faqs.org/rfcs/rfc1332.html а зачем вы все это делаете???я вот вообще первый раз вижу, что кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные значения, что чему соответствует, где читали? интересно было бы почитать
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от JohnProfic (ok) on 03-Май-11, 20:46
	>> http://www.faqs.org/rfcs/rfc1661.html >> http://www.faqs.org/rfcs/rfc1332.html > а зачем вы все это делаете???я вот вообще первый раз вижу, что > кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные > значения, что чему соответствует, где читали? интересно было бы почитать Для меня в данном конкретном случае -- спортивный интерес. А так иногда бывает, что какой-нибудь сервис не работает как нужно и в логи ничего толком не пишет (вспоминается Samba старых версий). И как назло в tcpdump/wireshark нет диссектора (или он неполон) для этого протокола. Или это вообще не сетевой протокол, а какой-нибудь файл в специфическом формате (вспоминается xls/doc/dbf и т.п.) и библиотек под нужный ЯП либо нет, либо они не умеют делать, то что тебе нужно (такое правда у меня было давно).
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	7. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от LSTemp (ok) on 12-Май-11, 00:07
	>[оверквотинг удален] >> кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные >> значения, что чему соответствует, где читали? интересно было бы почитать > Для меня в данном конкретном случае -- спортивный интерес. А так иногда > бывает, что какой-нибудь сервис не работает как нужно и в логи > ничего толком не пишет (вспоминается Samba старых версий). И как назло > в tcpdump/wireshark нет диссектора (или он неполон) для этого протокола. > Или это вообще не сетевой протокол, а какой-нибудь файл в специфическом формате > (вспоминается xls/doc/dbf и т.п.) и библиотек под нужный ЯП либо нет, > либо они не умеют делать, то что тебе нужно (такое правда > у меня было давно). для меня тоже больше спортивный в данном случае. задача стояла настроить шейпинг poptop-клиентов, которые без шифрования подключаются. неиспользуемая ширина канала должна распределяться м/ду клиентами без использования imq (его просто нет - сервак старый, ядро старое и пересобирать все - себе дороже). поэтому ясное дело - единственный выход ставить фильтры на физический интерфейс. в принципе фильтра вида: u32 match ip protocol 47 0xff match ip dst $LAN_DST/32 вполне достаточно для решения задачи. чем там клиент грузит выделенную ему полосу внутри туннеля - его дело. просто ради интереса задумался о возможности анализа пакетов внутри этого туннеля (он ведь не шифрованный) для приоритезации определенных сервисов (HTTP например). ИМХО в принципе задача решаема, но кучу фильтров ставить надо будет. еще следует учитывать, что заголовки пакетов могут иметь разную длину (теоритически. фактически - это скорее исключение в данной реализации), что либо еще фильтров добавит, либо просто некоторая (очень небольшая часть) нужного пройдет мимо фильтра. в общем даже такое извращение похоже можно реализовать...
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	11. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от RSG (ok) on 13-Май-11, 12:02
	>Что-то у меня лыжи уже 3-й день не едут с расшифровкой одного значения пакета, перехваченного tcpdump-ом >> для меня тоже больше спортивный в данном случае. Люди, а не проще было бы сделать стенд (хоть на виртуалках), запустить снифер (вирешарк например), который все поля в соответствие с RFC сам разбирает и описывает их?
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	5. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от JohnProfic (ok) on 03-Май-11, 20:47
	>> http://www.faqs.org/rfcs/rfc1661.html >> http://www.faqs.org/rfcs/rfc1332.html > а зачем вы все это делаете???я вот вообще первый раз вижу, что > кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные > значения, что чему соответствует, где читали? интересно было бы почитать А разбирать в основном описания протоколов и форматов либо открыты, либо в Сети можно найти их описание.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от LSTemp (ok) on 11-Май-11, 23:38
	> http://www.faqs.org/rfcs/rfc1661.html > http://www.faqs.org/rfcs/rfc1332.html спасибо конечно за ссылки), но я уже писал, что rfc читал (не один год их уже читаю) - этому свидетельство моя приведенная расшифровка пакета. к тому же, учитывая наличие GRE и его несколько специфичную реализацию в poptop, данных ссылок явно недостаточно для ответа. вопрос уперся только в одно значение, которое я понять не могу. не надо ссылок - просто если знаете (или есть предположения), то просто скажите что это такое.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	8. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от JohnProfic (ok) on 12-Май-11, 00:54
	>> http://www.faqs.org/rfcs/rfc1661.html >> http://www.faqs.org/rfcs/rfc1332.html > спасибо конечно за ссылки), но я уже писал, что rfc читал (не > один год их уже читаю) - этому свидетельство моя приведенная расшифровка > пакета. к тому же, учитывая наличие GRE и его несколько специфичную > реализацию в poptop, данных ссылок явно недостаточно для ответа. > вопрос уперся только в одно значение, которое я понять не могу. не > надо ссылок - просто если знаете (или есть предположения), то просто > скажите что это такое. Из того, что я понял: После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит из поля протокола, занимающего 1 или 2 байта и всякого мусора. Значение 0x21 для поля протокола: IP-пакет (вторая ссылка).
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	9. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от LSTemp (ok) on 12-Май-11, 02:13
	>[оверквотинг удален] >> один год их уже читаю) - этому свидетельство моя приведенная расшифровка >> пакета. к тому же, учитывая наличие GRE и его несколько специфичную >> реализацию в poptop, данных ссылок явно недостаточно для ответа. >> вопрос уперся только в одно значение, которое я понять не могу. не >> надо ссылок - просто если знаете (или есть предположения), то просто >> скажите что это такое. > Из того, что я понял: > После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит > из поля протокола, занимающего 1 или 2 байта и всякого мусора. > Значение 0x21 для поля протокола: IP-пакет (вторая ссылка). подробней можно по 2-й ссылке (цитату) - у меня видимо лыжи не едут совсем на этот вопрос... глаз замылился. 0x21 - ОДИН байт (не 0x0021). где там оно в rfc? хотя думаю, что скорее всего Вы правы. надо просто исходник poptop поглядеть (так не хотелось, но придется - дело принципа :)). наверное дело в реализации... спасибо.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от JohnProfic (ok) on 12-Май-11, 16:18
	>> Из того, что я понял: >> После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит >> из поля протокола, занимающего 1 или 2 байта и всякого мусора. >> Значение 0x21 для поля протокола: IP-пакет (вторая ссылка). > подробней можно по 2-й ссылке (цитату) - у меня видимо лыжи не > едут совсем на этот вопрос... глаз замылился. 0x21 - ОДИН байт > (не 0x0021). где там оно в rfc? > хотя думаю, что скорее всего Вы правы. надо просто исходник poptop поглядеть > (так не хотелось, но придется - дело принципа :)). наверное дело > в реализации... спасибо. Из 1-й ссылки про поле протокола: The Protocol field is one or two octets, and its value identifies the datagram encapsulated in the Information field of the packet. The field is transmitted and received most significant octet first. The structure of this field is consistent with the ISO 3309 extension mechanism for address fields. All Protocols MUST be odd; the least significant bit of the least significant octet MUST equal "1". Also, all Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0". Frames received which don't comply with these rules MUST be treated as having an unrecognized Protocol. Из второго абзаца я понял, что первый байт из 0x0021 можно опускать, если он равен 0x00.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	12. "pptp, tcpdump, анализ пакета"	+/–
	Сообщение от LSTemp (ok) on 15-Май-11, 01:36
	>[оверквотинг удален] > equal "1". Also, all Protocols > MUST be assigned such that the > least significant bit of the most > significant octet equals "0". > Frames received which don't comply with > these rules MUST be > treated as having an unrecognized Protocol. > > Из второго абзаца я понял, что первый байт из 0x0021 можно опускать, > если он равен 0x00. Мой земной поклон и благодарность. Глаз замылился/читал книгу - фидел фигу/итд ). Еще раз спасибо огромное.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору