[viakon 0]

LWIP фрагментированные пакеты собирает только если используется операционка? Использую standalone режим из примеров, при передаче пакета 2059 приходят два 1460 и 599. Как их правильно собрать в один? В инете пугают что они могут придти наборот вначале 599 байт.

 

STM32F107, LWIP 1.4.1, соединение TCP/IP.

Изменено 10 августа, 2015 пользователем viakon

[doom13 0]

Пробуйте посмотреть в направлении опции IP_REASSEMBLY. С приёмом не пробовал, но при отправке (IP_FRAG) фрагментация работала.

[viakon 0]

Пробуйте посмотреть в направлении опции IP_REASSEMBLY.

Включено в opt.h.

[doom13 0]

Запускал пример от TI, там к проекту подтянут ещё lwipopts.h, где IP_REASSEEMBLY = 0. Может у Вас есть что-то похожее?

 

[viakon 0]

Запускал пример от TI, там к проекту подтянут ещё lwipopts.h, где IP_REASSEEMBLY = 0. Может у Вас есть что-то похожее?

В lwipopts.h нет такого параметра.

[alx2 0]

при передаче пакета 2059 приходят два 1460 и 599.

 

соединение TCP/IP.

А разве в вашем пакете не установлен флаг "Don't fragment"?

Вообще-то при использовании TCP пакетам запрещают фрагментирование, и, если где-то в пути пакет превысил MTU, обратно отправляется icmp fragmentation needed...

[scifi 1]

... при передаче пакета 2059 приходят два 1460 и 599. Как их правильно собрать в один?

... соединение TCP/IP.

Уточните, что имеете в виду.

"Соединение TCP/IP" - имеется в виду соединение TCP? Если так, то при чём тут пакеты? Соединение TCP на высоком уровне - это поток байтов без разбивки на пакеты. В режиме raw API при отправке данных разбивка на пакеты происходит автоматически. При приёме автоматически упорядочиваются принятые пакеты и передаются на верхний уровень в виде цепочки буферов. Да, вам надо работать с этими буферами один за одним. Если у вас там есть кусок данных, размазанный по нескольким буферам, то вам придётся самому собирать его вместе (если это необходимо). Вы должны быть готовы к тому, что данные будут приходить в виде цепочки буферов размером 1 байт каждый.

[kolobok0 0]

..при использовании TCP пакетам запрещают фрагментирование...

 

1) говоря о TCP не корректно говорить о пакетах. это ПОТОКОВЫЙ протокол..

2) Если Вы имеете ввиду IP пакеты, то выставление флага фрагментации не зависит от уровня более верхнего протокола.

 

 

LWIP фрагментированные пакеты...при передаче пакета 2059 приходят два 1460 и 599....они могут придти наборот вначале 599 байт....соединение TCP/IP.

 

у Вас полная каша.

1) как уже прозвучало выше TCP потоковый протокол, там ФИЗИЧЕСКИ НЕТ пакетов. Когда ведут разговор про TCP протокол, то подразумевают

именно то что декларировано RFC. Если ведёте речь о более низких протоколах стэка - то так и пишите IP, EthFrame

2) TCP ГАРАНТИРУЕТ последовательную передачу потока данных. Т.е. всевозможные "наоборот", для данного потока - враньё по определению.

 

 

при работе с данным протоколом Вы можете запихать на передатчике 1460+599 и получить 10+300+1740+9, а можете получить сразу 2059

одним присестом - в зависимости от многих условий... Но данные ГАРАНТИРОВАННО придут именно в той последовательности в которой

были переданы...

 

[alx2 0]

1) говоря о TCP не корректно говорить о пакетах. это ПОТОКОВЫЙ протокол..

Хорошо. А через какой транспорт передается этот поток? У автора написано "TCP/IP". Говоря об IP корректно говорить о пакетах?

 

2) Если Вы имеете ввиду IP пакеты, то выставление флага фрагментации не зависит от уровня более верхнего протокола.

То есть Вы считаете нормальным, когда IP пакет, несущий данные TCP, не имеет флага Don't fragment?

По-моему это ненормально, о чем я и написал viakon.

[scifi 1]

Хорошо. А через какой транспорт передается этот поток? У автора написано "TCP/IP". Говоря об IP корректно говорить о пакетах?

Вы, наверное, не в курсе, что такое TCP/IP. Почитайте тут.

Это набор разных протоколов, многие из которых не имеют отношения к TCP, например ARP, ICMP, UDP.

Короче, TCP/IP - это слишком общий термин. Мы догадываемся, что автор имел в виду TCP, но вдруг ошибаемся?

 

То есть Вы считаете нормальным, когда IP пакет, несущий данные TCP, не имеет флага Don't fragment?

По-моему это ненормально, о чем я и написал viakon.

Вот тут есть вполне чеканный ответ на этот вопрос.

Если в двух словах, то по-разному бывает.

[alx2 0]

Короче, TCP/IP - это слишком общий термин. Мы догадываемся, что автор имел в виду TCP, но вдруг ошибаемся?

Давайте не будем гадать, а попросим viakon уточнить, о каком именно пакете размером 2059 байт он говорил. Мне почему-то кажется, что это не ARP. :)

 

Если в двух словах, то по-разному бывает.

Вопрос не в том, как бывает. Я допускаю, что TCP без DF возможно. Но вот нормально ли это? По вашей ссылке описана ситуация, когда сначала кто-то ломает в сети PMTUD, а потом в результате этого приходится убирать DF. Но когда сломано PMTUD - это уже ненормально...

 

Когда-то много лет назад в какой-то фидошной эхе спорили на эту тему (фрагментация IP пакетов). Я не поленился и поставил на одном из интернет-маршрутизаторов счетчики. Как оказалось, в реальной жизни ни одного (из многих миллионов) пакета (чтобы не было вопросов и догадок - я имею в виду пакета IP с кодом 6 в поле protocol) без флага DF не встретилось (за исключением TCP RST, которые большими не бывают). Это я к тому, как бывает в реальной жизни...

 

Поэтому, повторю, если у viakon пакет с данными передается без флага DF, ему, как минимум, надо обратить на это внимание и задуматься, почему так. Если, как в примере по ссылке, у него PMTUD сломано, так наверное лучше починить сломанное, чем бороться со следствиями...

[scifi 1]

Давайте не будем гадать, а попросим viakon уточнить

Он, похоже, потерял интерес к этой теме :laughing:

Это всё интересно, конечно, про фрагментацию IP пакетов. Но мне-то кажется, что он просто ожидал отправить по TCP пачку данных размером около 2 КБ и принять такую же пачку на другой стороне. А оказалось, что lwip разбил эту пачку на кусочки (потому что сильно сомневаюсь, что MSS больше 2 КБ). Я просто обратил его внимание, что в режиме raw API по-другому и не будет, вот и всё. И фрагментация на уровне IP здесь ни при чём.

[Quasar 18]

А вот вопрос, по практике. У меня на одной железке, начались проблемы со сборкой фрагментированных IP пакетов. В LwIP IP_REASSEEMBLY = 1, и иногда, при приеме например ICMP размером 30Кбайт, стеку не хватает памяти (malloc возвращает NULL), и обмен подвисает, пока стек не очистит очередь IP фрагментов, ожидающих сборки, я взял и отключил IP_REASSEEMBLY, теперь стек не задумывается, но вопрос, чем это не грозит?

[viakon 0]

Он, похоже, потерял интерес к этой теме :laughing:

Это всё интересно, конечно, про фрагментацию IP пакетов. Но мне-то кажется, что он просто ожидал отправить по TCP пачку данных размером около 2 КБ и принять такую же пачку на другой стороне. А оказалось, что lwip разбил эту пачку на кусочки (потому что сильно сомневаюсь, что MSS больше 2 КБ). Я просто обратил его внимание, что в режиме raw API по-другому и не будет, вот и всё. И фрагментация на уровне IP здесь ни при чём.

Интерес не пропал, на данный момент я решил проблему уменьшением размера пакета до 1к, потому как времени на эксперименты уже не было.

Я думаю что все дело в том, что мне приходится пользоваться практически raw ip без участия операционки.

И тут прослеживается следующая логическая цепочка. На компе после содинения TCP послылаются в сокет данные 2059 байт, естественно они разбиваются на 2 пакета. Первый пакет длиной в 1460 полезных байт принимается мироконтроллером, вырабатывается прерывание и вызов LwIP_Pkt_Handle(), вызывает tcp_echoserver_recv (торопился, потому не стал даже переименовывать названия фнкций в примере), где я и получаю эти 1460 байт. Думаю что если подождать с обработкой LwIP_Pkt_Handle() то после прихода второго пакета я получу свои данные но все равно с разбивкой на 2 части в структуре pbuf.

FreeRTOS не хочу использовать мало ОЗУ. А ради эксперимента прикручивать FreeRTOS лениво.

Изменено 17 августа, 2015 пользователем viakon

[scifi 1]

Думаю что если подождать с обработкой LwIP_Pkt_Handle() то после прихода второго пакета я получу свои данные но все равно с разбивкой на 2 части в структуре pbuf.

Именно так оно и работает.

И ещё раз повторяю: нужно быть готовым к тому, что эти 2 килобайта придут в виде 2048 пакетов по 1 байту каждый. Экзотика, да, но вполне законно. В этом случае просто подождать не получится - память закончится. Поэтому нужно в отдельном буфере накапливать данные по мере их поступления, не откладывая. И освобождать ненужные буферы сразу.