[haker_fox 61]

Здравствуйте, уважаемые коллеги!

Могу ли использовать для контроля целостности принятых пакетов только CRC32 фрейма Ethernet? Я имею ввиду, не контролировать напосредственно контрольные суммы IP, UDP?

Спасибо!

[follow_me 0]

Здравствуйте, уважаемые коллеги!

Могу ли использовать для контроля целостности принятых пакетов только CRC32 фрейма Ethernet? Я имею ввиду, не контролировать напосредственно контрольные суммы IP, UDP?

Спасибо!

а почему нет ? в данном случае вы рискуете получить битый пакет только в случае когда ошибка возникла во время упаковки TCP/UDP пакета в Ethernet фрейм , что довольно маловероятно потому можно пренебречь контрольной суммой упакованного пакета

[haker_fox 61]

а почему нет ? в данном случае вы рискуете получить битый пакет только в случае когда ошибка возникла во время упаковки TCP/UDP пакета в Ethernet фрейм , что довольно маловероятно потому можно пренебречь контрольной суммой упакованного пакета

А разве при инкапсуляции пакета, эта КС не пересчитывается?

 

Да, и, похоже, такой способ пройдет, когда данные передаются как минимум по витой пары (не знаю про оптику, про радиоканал). Если же данные передаются через последовательный порт, то там уже необходимо контролировать КС самих протоколов. Я прав?)

[aaarrr 69]

Нет, не пересчитывается. Вероятность получить битый IP-пакет с нормальной FCS все же существует, поэтому игнорировать контрольную сумму можно только в крайнем случае.

[haker_fox 61]

Нет, не пересчитывается. Вероятность получить битый IP-пакет с нормальной FCS все же существует, поэтому игнорировать контрольную сумму можно только в крайнем случае.

Гм, тогда я чего-то не понимаю :rolleyes: Я думал, что КС аппаратно пересчитывается для каждого передаваемого фрейба, байт за байтом. Не знаю, кто это делает PHY или MAC, но не суть важно...

[follow_me 0]

А разве при инкапсуляции пакета, эта КС не пересчитывается?

 

Да, и, похоже, такой способ пройдет, когда данные передаются как минимум по витой пары (не знаю про оптику, про радиоканал). Если же данные передаются через последовательный порт, то там уже необходимо контролировать КС самих протоколов. Я прав?)

 

в данном случае, необходимость контроля не зависит от канала передачи, ошибка протокола может появится исключительно до того как данные будут переданы по каналу (т.е. вы контролируете целостность протокола канального уровня вроде Ethernet а не tcp/udp). Если говорить точнее эта ошибка может появиться в буффере NIC до того как он запакует пакет. Вообще говоря ошибка быть может , но вероятность появления ошибке по вине памяти например , на маленьких буфферах (~1mb) составляет 3 ошибки в год при работе в 24/7/365 (недавно гугл делал исследования) - потому смотрите сами , насколько критично вам такое количество ошибок

 

Нет, не пересчитывается. Вероятность получить битый IP-пакет с нормальной FCS все же существует, поэтому игнорировать контрольную сумму можно только в крайнем случае.

 

Гм, тогда я чего-то не понимаю Я думал, что КС аппаратно пересчитывается для каждого передаваемого фрейба, байт за байтом. Не знаю, кто это делает PHY или MAC, но не суть важно...

 

Уважаемый aaarrr имел ввиду что контрольная сумма протокола более высокого уровня (tcp,udp, etc ... ) при подсчете контрольной суммы протокола канального уровня (Ethernet) не пересчитывается, но считается по новому для фрейма - выходит двойная защита данных

 

Почему я и говорю что можно пренебречь - потому как при ошибках FCS вы откидываете этот пакет потому как он повредился в каналах данных

если FCS верная то вероятность получить контрольную сумму вышестоящего протокола довольно низкая (ну разве что у вас совсем уж неадекватное передающее железо)

[haker_fox 61]

Чтож, будем считать "вложенные КС", благо это не сложно)

Всем большое спасибо!

[kolobok0 0]

Чтож, будем считать "вложенные КС", благо это не сложно)...

 

с вои 5 копеек:

 

ещё не сбрасывайте со счетов дефрагментацию на IP уровне на промежуточных хопах. Т.е. изернет вам придёт нормальный, а вот пакет может оказаться битым (например многие свитчи "едут" при повышении нагрузки или не стандартных ситуациях). тут слово "едут" подразумевает не столь явно багу, а то что алгоритм начинает работать не совсем так как ожидалось от него. например слать не в той последовательности фрагменты и т.п. вещи...

 

(круглый)

 

[haker_fox 61]

с вои 5 копеек:

 

ещё не сбрасывайте со счетов дефрагментацию на IP уровне на промежуточных хопах. Т.е. изернет вам придёт нормальный, а вот пакет может оказаться битым (например многие свитчи "едут" при повышении нагрузки или не стандартных ситуациях). тут слово "едут" подразумевает не столь явно багу, а то что алгоритм начинает работать не совсем так как ожидалось от него. например слать не в той последовательности фрагменты и т.п. вещи...

 

(круглый)

Честно говоря, я даже не рассматриваю фрагментированные пакеты.

Мне нужен только "самый простой" UDP.

Поэтому решил урезанный стек написать сам, ну от части в академических целях)

 

Под свитчами вы подразумеваете те, которые работаю на канальном уровне, потому что других не ожидается...

 

[kolobok0 0]

...Мне нужен только "самый простой" UDP....

 

эээээээээ собственно это выше чем IP - посему можем(по протоколу) его фрагментировать, если не лезет или заняты...

т.е. другими словами - на приёме UDP пакета Вы должны отрабатывать дефрагментацию. очень часто люди говорят - я не посылаю более чем.....1500... Это то да... Но кто сказал что оно всегда так будет и от нагрузки не зависит?

 

 

(круглый)

 

[BSACPLD 15]

эээээээээ собственно это выше чем IP - посему можем(по протоколу) его фрагментировать, если не лезет или заняты...

т.е. другими словами - на приёме UDP пакета Вы должны отрабатывать дефрагментацию. очень часто люди говорят - я не посылаю более чем.....1500... Это то да... Но кто сказал что оно всегда так будет и от нагрузки не зависит?

Так ведь можно заставить систему посылать пакеты с флагом IP_DONTFRAGMENT.

 

BOOL dontfragment = TRUE ;

setsockopt (sckt, IPPROTO_IP, IP_DONTFRAGMENT, (char*)&dontfragment, sizeof(dontfragment)) ;

[haker_fox 61]

Так ведь можно заставить систему посылать пакеты с флагом IP_DONTFRAGMENT.

 

BOOL dontfragment = TRUE ;

setsockopt (sckt, IPPROTO_IP, IP_DONTFRAGMENT, (char*)&dontfragment, sizeof(dontfragment)) ;

Вот и отличненько, поскольку этим стеком будет пользоваться только мое личное ПО, а частота использования будет очень мала (обновление прошивки), то это мне подходит)

Спасибо!

[kolobok0 0]

...посылать пакеты с флагом IP_DONTFRAGMENT..

 

угумс. можно. но при загрузах на промежуточных хопах этот пакет может быть смело удалён (разбить нельзя, пропихнуть нельзя).

 

т.е. тут надо для себя решить чего важнее и как часто...

 

удачи вам

(круглый)

[haker_fox 61]

Гм, поигрался с сетью немного. Решил, что по возможности, наверно, следует применять готовые, отлаженныи и опробированные решения.

Какие качественных открытые стеки кроме uIP и с tnkernel.com может порекомендовать уважаемое сообщество?

На данным момент нужен только UDP, ну и ICMP (приятно видеть пинг от железки))) )

Может быть есть стеки, где можно выбирать, какие компоненты использовать? По типу коммерческого стека из RL-ARM (Keil)?

[kolobok0 0]

... и ICMP (приятно видеть пинг от железки)..

 

тогда ышо +ARP

:)

 

да и DHCP не помешает.

и то и то реализация копеешные.

 

(круглый)

ЗЫ

буду упрям :) (ржу) дефрагментацию стоит поддержать :)))