Oleg_IT
Oct 8 2013, 08:55
Продолжение работы, которая обсуждалась
здесьДемо плата SK-MLPC2478, приложение EMAC. Отдельный вход Ethernet для этой платы. Формирую ARP запрос, по WireShark вижу, что сообщение в PC приходит и формируется ответ, но прерывания в ARM-е, по приходу данных, нет, прерывания возникают только по отправке данных, данные отправлены, буфер пуст. Где, что посмотреть, проверить почему нет прерываний?
Golikov A.
Oct 8 2013, 09:14
мак адрес в емаке есть? задали? правильный?
Oleg_IT
Oct 8 2013, 11:14
Цитата(Golikov A. @ Oct 8 2013, 13:14)

мак адрес в емаке есть? задали? правильный?
А что значит правильный? Он у меня из примера остался.
В приложении скриншоты с WireShark
сарматъ
Oct 8 2013, 13:12
а айпи адреса правильно обрабатываются?маска сети какая?
Oleg_IT
Oct 9 2013, 05:09
Маска 255.255.0.0. Попробывал другие варианты прерываний нет.
сарматъ
Oct 9 2013, 05:29
для начала можно попробывать разрешить прием всех пакетов не зависимо от мак адреса и посмотреть вообще что то приходит или нет
Oleg_IT
Oct 9 2013, 06:43
Цитата(сарматъ @ Oct 9 2013, 09:29)

для начала можно попробывать разрешить прием всех пакетов не зависимо от мак адреса и посмотреть вообще что то приходит или нет
А я не запрещал. Где разрешить/запретить прописывается?
Я сейчас без библиотеки работаю, всё сам делаю, и пакеты генерю и на выход их посылаю.
сарматъ
Oct 9 2013, 07:05
для каждого процессора периферия настраивается по своему думаю в мануале по процессору должен быть описан порядок работы с мак-контроллером в частности правила фильтрации пакетов
ну и конечно сами прерывания должны быть разрешены явно а не просто "не запрещены"
еще такой момент вы подсоединяете плату чрез маршрутизатор? хорошо было бы убедиться что маршрутизатор отправляет пакеты на соотв порт
Oleg_IT
Oct 9 2013, 07:53
Цитата(сарматъ @ Oct 9 2013, 11:05)

для каждого процессора периферия настраивается по своему думаю в мануале по процессору должен быть описан порядок работы с мак-контроллером в частности правила фильтрации пакетов
ну и конечно сами прерывания должны быть разрешены явно а не просто "не запрещены"
еще такой момент вы подсоединяете плату чрез маршрутизатор? хорошо было бы убедиться что маршрутизатор отправляет пакеты на соотв порт
Нет, соединение точка-точка. Провода целые, не рваные, проверял.
По первым двум советам проверю.
Oleg_IT
Oct 9 2013, 11:40
Проблема банальна. При формировании запроса у меня один порядок байтов в MAC адресе был, а при инициализации MAC в PHY обратный.
Тогда другой вопрос. В PC одно направление байтов в SUN и в ARM другое. Как определяется из какой системы пришёл пакет?
Golikov A.
Oct 9 2013, 12:12
Цитата(Oleg_IT @ Oct 9 2013, 15:40)

Проблема банальна. При формировании запроса у меня один порядок байтов в MAC адресе был, а при инициализации MAC в PHY обратный.
Тогда другой вопрос. В PC одно направление байтов в SUN и в ARM другое. Как определяется из какой системы пришёл пакет?
езернет весь BIG Endian, что РС, что Юникс, что Макинтош...
а ARMы разные бывают, обычно Little Endian
Oleg_IT
Oct 11 2013, 04:14
При компиляции можно определить какая система BIG или Little Endian?
Golikov A.
Oct 11 2013, 07:47
скорее всего на этапе создания проекта. У некоторых сред и армов можно выбрать в свойствах проекта. В "софтварных" плисовых процессорах можно выбрать на уровне создания проца.
Только я бы не стал менять Little Endian процессор на Big, ибо для процессора удобнее и быстрее быть Little
сарматъ
Oct 11 2013, 07:48
Цитата(Golikov A. @ Oct 11 2013, 11:47)

для процессора удобнее и быстрее быть Little
а почему так?
Golikov A.
Oct 11 2013, 09:07
потому для чего этот формат придумали
к примеру
Код
logn int BigData = 128.
void *p = (void *)&BigData;
это все сработает правильно
Код
char ch_data = *p;
short int m_data = *p;
int mm_data = *p;
long int l_data = *p;
потому что в адресах памяти самый младший байт лежим первым, и взяв его в чаровский указатель вы получите верное 8 битное число.
Запихав в 16 бит, вы опять же получите верное 16 битное число и так далее...
То есть такой формат позволяет легко преобразовывать длинный тип в короткие, и обратно при некоторой сноровке
Код
short int Data = 232443;
void *p = (void *)&Data;
long int b_data = *p;
b_data &= 0x0000FFFF;
в формате Big Endian младшая часть числа всегда лежит на разном расстоянии от начала в зависимости от размерности числа, и чтобы получить правильное число из памяти надо знать и учитывать размерность числа записанного и приемника, это несколько осложняет процесс....
сарматъ
Oct 11 2013, 09:18
понял спасибо
Oleg_IT
Oct 11 2013, 09:25
Потому и нужны какие-то дефайны, по которым определяется нужно делать swap или нет.
Тут ещё сложность не только в порядке байт, но и в порядке бит в битовых полях.
Golikov A.
Oct 11 2013, 09:58
Цитата(Oleg_IT @ Oct 11 2013, 13:25)

Потому и нужны какие-то дефайны, по которым определяется нужно делать swap или нет.
Тут ещё сложность не только в порядке байт, но и в порядке бит в битовых полях.
нет... Big и Litlle меняет только порядок байт. Битовые поля не могу разворачиваться. Возможно среда ставить какой то дефайн при выборе байт ордера, только вопрос, а вам то оно зачем? Вы пишите универсальный модуль или просто все время забываете какой порядок вы используете

?
Если модуль универсальный - то сделайте свой дефайн, в случае которого вы переводите все в Big, а по умолчанию делайте в Little как более популярном...
П.С. повернутый порядок бит - это очень странно, у вас нет никаких рукописных UART на пути следования данных, потому что только они имеют тенденцию биты поворачивать. Если нет, остается проверить стандарты езернет, нет ли какого флажка в заголовках по этому поводу, но очень маловероятно, так как даже этот флажок фиг найдешь если он все время в разных местах... Вообщем про поворот порядка бит я озадачен...
Oleg_IT
Oct 11 2013, 10:29
Цитата(Golikov A. @ Oct 11 2013, 13:58)

нет... Big и Litlle меняет только порядок байт. Битовые поля не могу разворачиваться. Возможно среда ставить какой то дефайн при выборе байт ордера, только вопрос, а вам то оно зачем? Вы пишите универсальный модуль или просто все время забываете какой порядок вы используете

?
Если модуль универсальный - то сделайте свой дефайн, в случае которого вы переводите все в Big, а по умолчанию делайте в Little как более популярном...
П.С. повернутый порядок бит - это очень странно, у вас нет никаких рукописных UART на пути следования данных, потому что только они имеют тенденцию биты поворачивать. Если нет, остается проверить стандарты езернет, нет ли какого флажка в заголовках по этому поводу, но очень маловероятно, так как даже этот флажок фиг найдешь если он все время в разных местах... Вообщем про поворот порядка бит я озадачен...
Я теже озадачен, но по факту так
Код
typedef struct TCP_Head_tag {
uint16_t SRC_Port; // Порт отправителя
uint16_t DST_Port; // Порт получателя
uint32_t SeqNum; // Sequence Number
uint32_t AckNum; // Acknowledgment Number
union {
struct {
uint16_t FIN : 1; // No more data from sender
uint16_t SYN : 1; // Synchronize sequence numbers
uint16_t RST : 1; // Reset the connection
uint16_t PSH : 1; // Push Function
uint16_t ACK : 1; // Acknowledgment field significant
uint16_t URG : 1; // Urgent Pointer field significant
uint16_t Res1 : 6; //: 4; // Reserved - 0
uint16_t DOff : 4; // Data Offset - 5
};
uint16_t L1;
};
/*
union {
struct {
uint16_t DOff : 4; // Data Offset - 5
uint16_t Res1 : 6; //: 4; // Reserved - 0
uint16_t URG : 1; // Urgent Pointer field significant
uint16_t ACK : 1; // Acknowledgment field significant
uint16_t PSH : 1; // Push Function
uint16_t RST : 1; // Reset the connection
uint16_t SYN : 1; // Synchronize sequence numbers
uint16_t FIN : 1; // No more data from sender
};
uint16_t L1;
};
*/
uint16_t Window; // Window - -
uint16_t Checksum; // Checksum
uint16_t UrgPoint; // Urgent Pointer
} TCP_Head;
Закомментированное по стандарту, а рабочее, что бы на стороне PC все правильно воспринималось, не закомментированное. И ещё swap на L1 нужен. Может я в чём-то ошибаюсь. Поправьте.
Golikov A.
Oct 11 2013, 10:53
меня немного беспокоит слово заголовка в котором лежат флаги.
после 32 бит AckNum
должно идти 16 битное слово, в старших битах которого длина заголовка, а в младших биты - флаги. У вас наоборот. Может потому вам и надо инвертировать. То есть это просто совпадение. инвертированная длина попала в флаги, а инвертированные флаги в длину?
Опять же длина, L1 я так понимаю, не 16 бит.
6 бит флаги
6 бит пустое поле
остается 4 бита длинна вроде как...
Oleg_IT
Oct 11 2013, 11:11
По количеству бит там всё правильно 4 длина+6 пусто+6*1 флаги, итого 16.
А вот по порядку, правильно, по стандарту, закомментированный union ниже, а не правильный порядок оказывается правильным по факту. Я такие чудеса не понимаю, но в WireShark всё правильно отображается. Если swap на правильный по стандарту union сделать WireShark выдаёт ошибку.
Golikov A.
Oct 11 2013, 11:42
union {
struct {
uint16_t FIN : 1; // No more data from sender
uint16_t SYN : 1; // Synchronize sequence numbers
uint16_t RST : 1; // Reset the connection
uint16_t PSH : 1; // Push Function
uint16_t ACK : 1; // Acknowledgment field significant
uint16_t URG : 1; // Urgent Pointer field significant
uint16_t Res1 : 6; //: 4; // Reserved - 0
uint16_t DOff : 4; // Data Offset - 5
};
uint16_t L1;
};
Л1 - 16 бит это че? Сразу после флагов же окно идет uint16_t Window;
а у вас оно идет через какие то 16 бит Л1. Плюс еще вопрос как структура с 1 битными полями в памяти раскладывается... Выравнивание может сыграть злую шутку...
Цитата(Oleg_IT @ Oct 11 2013, 15:29)

Закомментированное по стандарту, а рабочее, что бы на стороне PC все правильно воспринималось, не закомментированное.
Расположение битовых полей в объединении определяется реализацией компилятора. Вы уверены, что ваш компилятор располагает битовые поля именно в порядке от старшего бита к младшему (как у Вас в закомментаренном фрагменте), а не наоборот (как в раскомментаренном)?
И, надеюсь, Вы понимаете, что из-за того что Вы закладываетесь на определенную реализацию компилятора, Ваш код становится непереносимым?
Oleg_IT
Oct 14 2013, 05:58
Цитата(alx2 @ Oct 12 2013, 15:05)

Расположение битовых полей в объединении определяется реализацией компилятора. Вы уверены, что ваш компилятор располагает битовые поля именно в порядке от старшего бита к младшему (как у Вас в закомментаренном фрагменте), а не наоборот (как в раскомментаренном)?
И, надеюсь, Вы понимаете, что из-за того что Вы закладываетесь на определенную реализацию компилятора, Ваш код становится непереносимым?
Догадываюсь, потому и хочу разграничить версии соответствующими дефайнами.
Цитата(Golikov A. @ Oct 11 2013, 15:42)

union {
struct {
uint16_t FIN : 1; // No more data from sender
uint16_t SYN : 1; // Synchronize sequence numbers
uint16_t RST : 1; // Reset the connection
uint16_t PSH : 1; // Push Function
uint16_t ACK : 1; // Acknowledgment field significant
uint16_t URG : 1; // Urgent Pointer field significant
uint16_t Res1 : 6; //: 4; // Reserved - 0
uint16_t DOff : 4; // Data Offset - 5
};
uint16_t L1;
};
Л1 - 16 бит это че? Сразу после флагов же окно идет uint16_t Window;
а у вас оно идет через какие то 16 бит Л1. Плюс еще вопрос как структура с 1 битными полями в памяти раскладывается... Выравнивание может сыграть злую шутку...
Так это же юнион, struct и L1 это два инени оного и того же куска пямяти размером два байта.
А про выравнивание я не сказал, пользуюсь
Код
#pragma push
#pragma pack(1)
……………………
#pragma pop
Golikov A.
Oct 14 2013, 18:43
ИМХО лучше сделать поле 16 бит,
и дефайны с флагами, чем структуру...
Цитата(Oleg_IT @ Oct 14 2013, 09:58)

Так это же юнион, struct и L1 это два инени оного и того же куска пямяти размером два байта.
да,... это я чего то объединение не разглядел....
Oleg_IT
Oct 15 2013, 04:41
Цитата(Golikov A. @ Oct 14 2013, 22:43)

ИМХО лучше сделать поле 16 бит,
и дефайны с флагами, чем структуру...
Так порядок бит, задаваемый этими дефайнами всё равно как-то учитывать нужно.
Golikov A.
Oct 15 2013, 06:24
да тут вроде как мы все ходим вокруг одного и того же.
порядок бит НЕ МЕНЯЕТСЯ, иначе во всем мире во всем интернете что на езернете построен был бы полный АД!
у вас все изменилось из-за представлений вашего компилятора о том как надо раскладывать битовые поля, потому и рекомендую избавится от зависимости компилятора, и не использовать потенциально опасные конструкции в виде битовых полей.
Oleg_IT
Oct 15 2013, 08:32
Я вас сходу по флажкам не понял. Переделал, работает.
Но вопрос нужен swap или нет остался. Может я опять простого решения не вижу
Golikov A.
Oct 15 2013, 11:16
во всех системах Big Enadian не нужен
во всех системах Litle Endian нужен.
потому делаете дефайн
Код
#define LITTLE_ENDIAN_MODE 1
и везде в вашем коде пишете
Код
#ifdef LITTLE_ENDIAN_MODE
swap
#elseif
not_swap
#endif
определять этот дефайн или нет оставляете тому кто пользуется написанным вами софтом, так как только этот человек знает какой у него режим работы...
причем этот дефайн можно тянуть не по всему тексту а сделать функцию swap_if_need, и в ней дефайн проверить, и сваповать если надо.
Oleg_IT
Oct 15 2013, 12:33
Самому определять это понятно, а в компиляторе такой информации нет?
mdmitry
Oct 15 2013, 13:29
Цитата(Oleg_IT @ Oct 15 2013, 16:33)

Самому определять это понятно, а в компиляторе такой информации нет?
Есть. Для GCC есть предопределенные макро, например, для arm-none-eabi-gcc (arm-none-eabi-g++)
Код
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_PDP_ENDIAN__ 3412
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
DmitryM
Oct 15 2013, 13:36
Цитата(Oleg_IT @ Oct 15 2013, 16:33)

Самому определять это понятно, а в компиляторе такой информации нет?
Цитата
The common predefined macros are GNU C extensions. They are available with the same meanings regardless of the machine or operating system on which you are using GNU C or GNU Fortran. Their names all start with double underscores
__BYTE_ORDER__
__ORDER_LITTLE_ENDIAN__
__ORDER_BIG_ENDIAN__
__ORDER_PDP_ENDIAN__
__BYTE_ORDER__ is defined to one of the values __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__, or __ORDER_PDP_ENDIAN__ to reflect the layout of multi-byte and multi-word quantities in memory. If __BYTE_ORDER__ is equal to __ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__, then multi-byte and multi-word quantities are laid out identically: the byte (word) at the lowest address is the least significant or most significant byte (word) of the quantity, respectively. If __BYTE_ORDER__ is equal to __ORDER_PDP_ENDIAN__, then bytes in 16-bit words are laid out in a little-endian fashion, whereas the 16-bit subwords of a 32-bit quantity are laid out in big-endian fashion.
You should use these macros for testing like this:
/* Test for a little-endian machine */
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
Common-Predefined-Macros.html
Oleg_IT
Oct 15 2013, 16:26
Спасибо
Oleg_IT
Oct 16 2013, 11:12
Цитата(Oleg_IT @ Oct 15 2013, 12:32)

Я вас сходу по флажкам не понял. Переделал, работает.
Поторопился я радоватся, что битовый массив, что
Код
#define FLAG_1 1
........................
Flags |= (1 << FLAG_1);
одно и тоже.
Dron_Gus
Oct 16 2013, 13:57
Oleg_IT
Oct 16 2013, 18:13
Цитата(Dron_Gus @ Oct 16 2013, 17:57)

Интересно. Спасибо за ссылочки.
Цитата(Oleg_IT @ Oct 16 2013, 16:12)

Поторопился я радоватся, что битовый массив,
Что такое "битовый массив"?
Цитата(Oleg_IT @ Oct 16 2013, 16:12)

что
Код
#define FLAG_1 1
........................
Flags |= (1 << FLAG_1);
одно и тоже.
Что "одно и то же"? Опишите подробнее, что, как Вам кажется, неправильно с приведенным вариантом.
Например, если у Вас в переменной Flags лежат флаги TCP, то приведенный Вами код установит флаг SYN. И этот код (в отличие от битовых полей в объединении) уже не зависит от реализации компилятора...
Oleg_IT
Oct 17 2013, 08:18
Цитата(alx2 @ Oct 17 2013, 11:25)

Что такое "битовый массив"?
Ошибся, битовое поле.
Цитата(alx2 @ Oct 17 2013, 11:25)

Что "одно и то же"? Опишите подробнее, что, как Вам кажется, неправильно с приведенным вариантом.
Например, если у Вас в переменной Flags лежат флаги TCP, то приведенный Вами код установит флаг SYN. И этот код (в отличие от битовых полей в объединении) уже не зависит от реализации компилятора...
Если я битовом поле
Код
union {
struct {
uint16_t FIN : 1; // No more data from sender
uint16_t SYN : 1; // Synchronize sequence numbers
uint16_t RST : 1; // Reset the connection
uint16_t PSH : 1; // Push Function
uint16_t ACK : 1; // Acknowledgment field significant
uint16_t URG : 1; // Urgent Pointer field significant
uint16_t Res1 : 6; //: 4; // Reserved - 0
uint16_t DOff : 4; // Data Offset - 5
};
uint16_t L1;
};
бит SYN, первый бит, ставлю в 1, то это будет тоже сомое, что
Код
L1 |= (1 << 1)
Проверено.
Golikov A.
Oct 17 2013, 17:42
Цитата(Oleg_IT @ Oct 17 2013, 12:18)

Проверено.
и что?
ну значит ваш компилятор переворачивает битовые поля в другой порядок.
Смысл то как раз избавить от этого и всю структуру битовых полей выкинут нафиг, заменить ее обычным 16 битным числом, куда честно ставить флаги, на те места где они должны быть, однозначно, независимо от компилятора...
Oleg_IT
Oct 18 2013, 05:20
Так ни битовые поля, ни работа с флагами задачу не решают. Функции по ссылке
http://www.opennet.ru/man.shtml?topic=hton...3&russian=0 только помогут, они специально для этого сделаны.
Golikov A.
Oct 18 2013, 06:34
что - то я видать не понимаю.
Я утверждаю что во всех сетях нашей планеты флаг сигнала SYN стоит в одном и том же месте 16 битного поля размера и флагов. Не зависимо от того на каком процессоре и каким компилятором сделана программа. Значит всегда можно сделать константу равную 1 в этом месте, и иметь четко определенный флаг в нужном месте на любой системе.
Что не так то?
Oleg_IT
Oct 18 2013, 06:56
По факту получается не так, и порядок байт и порядок бит разный. А ставить эти биты так или иначе не имеет значения ини будут на одном и том же места и это правильно и понятно.
Скорей всего мы друг друга недопонимаем
Golikov A.
Oct 18 2013, 10:18
да.
порядок байт в интернете биг ендиан.
порядок бит как у всех младший бит нулевой.
вашу структуру битовых полей перевернул компилятор от того вы считаете что порядок другой. Но взяв другой компилятор он может ее опять перевернуть, потому вам рекомендуют с этим не играть и сделать флаги а не битовые поля структуры.
порядок байт из за того что у вас АРМ наверняка Litle endian, и потому он тоже другой. Но сменив процессор на тот в котором Big, такие бывают... у вас опять все навернется от того вам советовали сделать дефайн...
Цитата(Oleg_IT @ Oct 18 2013, 10:20)

Так ни битовые поля, ни работа с флагами задачу не решают.
Вы по-моему не понимаете, что имеете дело с двумя разными проблемами:
1. Проблема порядка байт с ловах (Big/Little endianness). Она решается использованием стандартных функций htonl/ntohl/htons/ntohs.
2. Проблема порядка расплоложения битовых полей в структуре/объединении. Она решается отказом от использования битовых полей в данном случае.
Я говорил исключительно о второй проблеме. И обратил Ваше внимание на то, что код
Flags |= TCP_FLAG_SYN; переносим, а код
Flags.SYN = 1; - нет, так как порядок следования битовых полей может быть разным в разных компиляторах.
Цитата(Golikov A. @ Oct 18 2013, 15:18)

порядок байт из за того что у вас АРМ наверняка Litle endian, и потому он тоже другой. Но сменив процессор на тот в котором Big, такие бывают... у вас опять все навернется от того вам советовали сделать дефайн...
Вот поэтому и надо по возможности использовать htnl/nthl для преборазования из формата слов. Если хост little-endian, эти функции будут менять порядок байт в слове. Если хост big-endian - вернут свой аргумент в неизменном виде. Тогда при смене хоста ничего не навернется...
Oleg_IT
Oct 18 2013, 12:42
Кажется начинаю понимать обстановку. Без дефайнов не обойтись. Но всё равно не понятности остались, например в протоколе есть поле размером 13 бит, это байт и ещё немножко. Как в этом случае работает htnl/nthl?
Golikov A.
Oct 18 2013, 20:50
нет там такого поля 13 бит
есть поле 16 бит, и 3 бита в резерве....
дефайны наше все! Мы же работает на железном уровне, а не кнопки в бездушных программках рисуем%)
Цитата(alx2 @ Oct 18 2013, 15:40)

Вот поэтому и надо по возможности использовать htnl/nthl для преборазования из формата слов. Если хост little-endian, эти функции будут менять порядок байт в слове. Если хост big-endian - вернут свой аргумент в неизменном виде. Тогда при смене хоста ничего не навернется...
а как они кстати тип хоста узнают? все равно же какой то дефайн ест, или они при инициализации тест делают чтение - запись

?
Цитата(Golikov A. @ Oct 19 2013, 01:50)

а как они кстати тип хоста узнают? все равно же какой то дефайн ест, или они при инициализации тест делают чтение - запись

?
В случае нативной сборки (без кросс-компиляции) такие вещи можно узнать на этапе конфигурации (при выполнении скрипта configure). Например в autoconf есть макрос AC_C_BIGENDIAN, который при обнаружении big-endian хоста генерирует дефайн WORDS_BIGENDIAN.
В случае кросс-компиляции, наверное, для каждой target-архитектуры есть набор предопределенных дефайнов (если их не определяет сам компилятор). Можно, наверное, посмотреть, как это сделано, например, в glibc. Сам я специально этим не интересовался.
То есть да, какой-то дефайн наверняка все равно где-то есть, но главное, что это проблема библиотеки (и ее авторов), а не программиста, эту библиотеку использующего. Я как пользователь просто пишу в своем коде ntohl(), и могу не задумываться о том, как оно в коде библиотеки устроено, а могу сосредоточиться на своем собственном коде.
Конечно, если в библиотеке нет htonl/ntohl - тогда да, придется самому делать соответствующие дефайны и потом заботиться об их переопределении в случае смены целевой архитектуры...
Oleg_IT
Oct 19 2013, 18:22
Цитата(Golikov A. @ Oct 19 2013, 00:50)

нет там такого поля 13 бит
Не правда Ваша,
по ссылке пункт 3.1 "Fragment Offset"
Golikov A.
Oct 20 2013, 05:06
Цитата(Oleg_IT @ Oct 19 2013, 22:22)

Не правда Ваша,
по ссылке пункт 3.1 "Fragment Offset"
моя правда
это 13 бит от общего служебного поля
Флаги + офсет, в сумме которое 16 бит.
надеюсь версию вы не считает 4 битным полем?
http://securos.org.ua/potencialno-uyazvimy...rotokole-tcpip/Думаю самое правильное воспринимать заголовки
как 32 или 2 по 16, либо комбинация 2 по 8 и 16 бит.
Все более мелкие разделения должны входить в эти группы.
Oleg_IT
Oct 20 2013, 09:14
Цитата(Golikov A. @ Oct 20 2013, 09:06)

Думаю самое правильное воспринимать заголовки
как 32 или 2 по 16, либо комбинация 2 по 8 и 16 бит.
Все более мелкие разделения должны входить в эти группы.
С этим спорить не буду, там более, что заголовки так и задумывались как 32 битные. Думаю, что к заголовкам вообще ни какие свапы применять нельзя, они, заголовки, должны изначально строится под конкретную архитектуру, пусть с дефайнами. А htonl/ntohl и пр... применимы только к данным.
По поводу данных. Кто мне помешает ради экономии памяти сделать поля 13 и 3 бита а 16 битном слове. Как в этом случае быть с htonl/ntohl?
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.