Вышла предварительная версия TN NET TCP/IP stack Опции

[yuri_t]

TN NET TCP/IP написан для процессоров с размером RAM >= 32 KBytes и с размером FLASH >= 128 KBytes ( NXP © LPC23xx/LPC17XX, Atmel © AT91SAM7X, Luminary Micro © LM3S6xx/LM3S8xx/LM3S9xx, Freescale © MCF5223X и других аналогичных MCU).

TN NET TCP/IP stack базируется на industry-standard BSD TCP/IP stack. В качестве API используются BSD sockets. TN NET TCP/IP stack использует TNKernel ОСРВ для обеспечения действительно мультизадачной и реентерантной работы.

B предварительную версию (0.8) не включены TCP и DHCP протоколы.

www.tnkernel.com

[zltigo]

TN NET TCP/IP stack базируется на industry-standard BSD TCP/IP stack.

О! Т.е. Действительно максимально портировали BSD исходники? Или просто, типа, в приглядку писали?

[Rst7]

Вышла предварительная версия TN NET TCP/IP stack

B предварительную версию (0.8) не включены TCP и DHCP протоколы.

[yuri_t]

- по поводу портирования BSD

Идея была использовать BSD stack по максимуму, добавляя/изменяя только те части, которые не помещаются в 32kbyte RAM/128 kbyte ROM.

В частности, весь TCP/UDP/IP/ARP взят с минимальными изменениями из BSD Lite 4.4/OpenBSD/NetBSD. Изменения коснулись тех мест, которые не требуются и/или не помещаются в MCU типа LPCxx (например, не требуется перехода из kernel space в user space и обратно)

BTW, TCP stack будет выложен в ближайшее время.

IMHO, написать stack c нуля (начитавшись разнообразных RFC) конечно можно, но такой продукт, во-первых, будет
ничем не лучше BSD, во-вторых, потребует многолетнего тестирования для выявления всяких obscure bugs. Кстати,
такими проблемами страдают многие коммерческие реализации TCP/IP именно из-за ограниченной для маленьких
компаний возможности тестирования.

С другой стороны, если не устраивать революций в BSD Lite 4.4 TCP/IP, a изменить только незначительные/
второстепенные части, то можно всего за несколько итераций получить надежно работающий stack. Так поступила,
например, компания InterNiche в своем продукте NicheLite (и Microsoft (!) в WinSock2)

[zltigo]

IMHO, написать stack c нуля (начитавшись разнообразных RFC) конечно можно, но....

Ну я к этому и не призывал .

С другой стороны, если не устраивать революций в BSD Lite 4.4 TCP/IP, a....

Вот именно этот путь мне очень привлекателен.

[yuri_t]

TN NET обновилась до версии 0.8.3.

TN NET TCP IP/ stack версии 0.8.3 включает TCP/UDP/IP/ICMP/ARP протоколы.

www.tnkernel.com

[zltigo]

TN NET TCP IP/ stack версии 0.8.3 включает TCP/UDP/IP/ICMP/ARP протоколы.

Отлично! Правда я так и не нашел времени вдумчиво посмотреть

[yuri_t]

TN NET TCP/IP stack обновился до версии 0.8.5.

Добавлен пример "Embedded Web server".

TN NET TCP/IP stack версии 0.8.5 представляется достаточно зрелым для использования/тестирования
в реальных проектах.

[yuri_t]

Вышла версии 0.9 TN NET TCP/IP stack.

Добавлен DHCP client.

Просьба ко всем, кто использует (пробует) TN NET TCP/IP stack - присылайте,
пожалуйста, ваши замечания и предложения на yuri@tnkernel.com.

[sim732]

Вышла версии 0.9 TN NET TCP/IP stack.

Добавлен DHCP client.

Просьба ко всем, кто использует (пробует) TN NET TCP/IP stack - присылайте,
пожалуйста, ваши замечания и предложения на yuri@tnkernel.com.

Здравствуйте Юрий. Пытаюсь использовать Ваш TCP/IP stack с TN kernel в одном проекте
и столкнулся с такой проблемой. Есть задача, которая с одной стороны работает с клиентом
на host PC по tcp/ip, а сдругой стороны с двумя очередями. Если задача читает сокет, то она
естественно засыпает при отсутствии сообщений от клиента. Но тогда она может прозевать
сообщение из очереди. Есть ли в Вашей реализации стека что-либо такое (типа select), что
может сообщать о событии появления сообщения через сокет до вызова функции s_recv ?

Сообщение отредактировал sim732 - Mar 28 2010, 19:24

[sim732]

Почитал tn-net-sockets.pdf. Оказывается в Вашей реализации сокет можно перевести
в неблокирующий режим. Не очень хорошее решение моей проблемы (напрасно будет тратится
процессорное время), но все же лучше, чем ничего. Использую предоставленную функцию s_ioctl().
Сокет переводиться в неблокирующий режим не хочет. Смотрю исходные тексты и вижу, что
в функции tcp_s_recv() проверка состояния so->so_state на SS_NBIO вообще отсутствует. Т.е. в этой
версии tcp/ip стека(0.9) перевести открытый сокет в неблокирующее состояние нельзя.

[yuri_t]

Ф-ция 'select' создавалась для классических аппликаций - где нет multithreading и все происходит
внутри одной ф-ции main(). Для малоформатных RTOS типа TNKernel 'select' "тяжеловат", да и в
общем-то и не нужен (IMHO).

В случае TNKernel/TN NET и использовании TCP sockets, task, в которой производится s_recv(), должна
только принимать по s_recv() и не в коем случае не ждать какие-то другие события, очереди etc.
Другие события, очереди etc. дожны ждать ДРУГИЕ task(s).
Результат приема должен посылаться в ДРУГУЮ task (c помощью tn_queue например).
При этом блокирующий прием работает естественным образом, а неблокирующий прием
не нужен вообще (поэтому он и не реализован).

Код

void task_rx_socket_A_func(void * par)
{

   for(;;)
   {
      rc = s_recv(g_s, (unsigned char*)g_rx_buf, RX_BUF_SIZE, 0);
      if(rc < 0) //-- SOCKET_ERROR
      {
      }
      else if(rc == 0) // closed by peer
      {
      }
      else //-- got some data
      {
          //--processing data, obtained by the s_recv(), or send it to another task
      }
    //-----
   }
}

[sim732]

В случае TNKernel/TN NET и использовании TCP sockets, task, в которой производится s_recv(), должна
только принимать по s_recv() и не в коем случае не ждать какие-то другие события, очереди etc.
Другие события, очереди etc. дожны ждать ДРУГИЕ task(s).
Результат приема должен посылаться в ДРУГУЮ task (c помощью tn_queue например).
При этом блокирующий прием работает естественным образом, а неблокирующий прием
не нужен вообще (поэтому он и не реализован).

Спасибо Юрий за комментарий. Я так и поступил. Хотя и добавил пару строк в
tn_tcp_send.c для того, чтобы было соответствие с документацией.

Код

      if(m)
         break;
      else
      {
        if(so->so_state & SS_NBIO)
        {
           splx(tnet, sm);
           return -EWOULDBLOCK;
        }
        else
        {
           splx(tnet, sm);
           tn_net_wait(&so->so_rcv.sb_sem);
        }
      }

Спасибо еще раз за Вашу работу. Отличная RTOS и стиль написания очень
ясный.

[LightElf]

Изучаю сорцы. Возникли несколько вопросов:
1) Можно ли вызывать s_send и s_recv одновременно из разных потоков для одного и того же сокета? То есть один поток ждет прихода данных из сокета, а второй - в сокет пишет.
2) Может в силу лености ума не очень понимаю взаимодействие стека с ethernet контроллером. Нет ли какого-нибудь porting guide или это с моей стороны совсем уж наглость ?
3) Правильно ли я понимаю, что в порте TNKernel под Coldfire прерывания обрабатываются на стеке текущего процесса?

[yuri_t]

Изучаю сорцы. Возникли несколько вопросов:
1) Можно ли вызывать s_send и s_recv одновременно из разных потоков для одного и того же сокета? То есть один поток ждет прихода данных из сокета, а второй - в сокет пишет.

Можно

2) Может в силу лености ума не очень понимаю взаимодействие стека с ethernet контроллером. Нет ли какого-нибудь porting guide или это с моей стороны совсем уж наглость ?

На какой процессор собрались портировать ?

[LightElf]

Можно

Здоровско!

На какой процессор собрались портировать ?

Два процессора - LM3S6965 и MCF52236.

[shista]

Во время разработки своего проекта столкнулся со следующей проблемой:
На одном сокете UDP происходит приём запроса через s_recvfrom, а затем отправка ответа через s_sendto. Так вот, после получения запроса данные в полях sin_addr.s__addr и sin_port структуры sockaddr__in указывающей на отправителя запроса содержатся в перевёрнутом виде (в intel формате). Перед отправкой данных порядок байтов данных полей приходится переворачивать.
В для устранения данной ситуации недрах стека в функции udp_s_recvfrom модифицировал код:

Код

//       sin->sin_port         = ntohs(ui->ui_sport);
//       sin->sin_addr.s__addr = ntohl(ui->ui_src.s__addr);
         sin->sin_port         = ui->ui_sport;
         sin->sin_addr.s__addr = ui->ui_src.s__addr;

Всё заработало.

Вопрос: корректна ли данная модификация или необходимо лезть глубже? Или вообще ничего модифицировать не надо, а так и должно быть?
Контроллер lpc2368.

Сильно не пинайте - это мои первые потуги в сетевом программировании, сетевым программированием я раньше не занимался, а на изучение исходного кода к сожалению нет времени.

[grinux]

Добрый день.
Есть устройство, работающее по TCP с Win хостом.
Проблема в следующем: при активном подключении, если на устройстве сделать аппаратный RESET, оно как и положено в оставшийся открытым с точки зрения Win хоста сокет шлет RST. Но Win при этом продолжает делать посылки\перепослыки не воспринимая RST и не сообщая на верх об ошибке. Это приводит к тому, что реальное отключение приложения от сокета происходит только через минуту, что в моем случае неприемлемо. Есть ли какие нибудь варианты решить эту проблему? На устройстве стек TN_NET. На картинке суть проблемы.
Всем заранее спасибо.

Сообщение отредактировал grinux - Sep 17 2010, 15:23

Эскизы прикрепленных изображений

 

[grinux]

Сравнил работу устройства с Wiznet(правое окно), такой проблемы не обнаружил. Отличия только в дополнительном ARP запросе со стороны TN_NET, а также в том, что в пакете от Wiznet ack number отличен от нуля. Пробовал и в TN_NET вставлять ненулевой ack, но безрезультатно. Возможно дело в предварительном ARP запросе, но чтобы это отключить, нужно порядком поковыряться в исходниках.

Сообщение отредактировал grinux - Sep 20 2010, 17:10

Эскизы прикрепленных изображений

 

[grinux]

С Linux ситуация аналогичная, RST не воспринимает.

[Rst7]

Перенес в топик посты из соседней темы по просьбе топикстартера.

[grinux]

Перенес в топик посты из соседней темы по просьбе топикстартера.

По совету Rst7 выкладываю фалы дампов.
Дампы иллюстрируют следующую последовательность действий: установить телнет сессию, перезагрузить устройство, послать символ с клавиатуры в окно терминала установленной до перезагрузки устрйоства телнет сессии.

Прикрепленные файлы

 rst_dump.zip ( 4.56 килобайт ) Кол-во скачиваний: 25

 

[Rst7]

Секундочку, а почему контрольная сумма TCP для пакетов c RST некорректна?

В стеке забыли вызвать считатель контрольной суммы при отсылке пакета с RST?

[grinux]

Секундочку, а почему контрольная сумма TCP для пакетов c RST некорректна?

В стеке забыли вызвать считатель контрольной суммы при отсылке пакета с RST?

Стек не трогал, только экспериментировал с ненулевым ack в пакете с RST.
Проверка КС для TCP была отключена в настройках WS, сейчас включил и увидел это у себя
Сейчас буду смотреть, что там с подсчетом КС.

Ошибка в функции tcp_respond(). Калькуляция КС TCP делалась по всему IP пакету (закомментировано), скопировал правильный вызов из tcp_output(). Все заработало.

Код

   //th->th_sum = in_cksum(m, tlen);
   th->th_sum = in4_cksum(m,
                          IPPROTO_TCP,  //-- to force calc TCP pseudo header
                          sizeof(struct ip),   //-- off; see above
                          m->m_tlen - sizeof(struct ip)); //-- len = TCP header + data

Спасибо Дмитрию.

Сообщение отредактировал grinux - Sep 21 2010, 14:59

[Rst7]

Ошибка в функции tcp_respond()

Если это у авторов стека, напишите им гневное письмо с люлЯми багрепорт

[yuri_t]

Большое спасибо Григорию, Дмитрию и вообше всем пользователям TN NET
за найденные (и, главное, исправленные) ошибки !!!
К сожалению, мои возможности тестирования (и, следовательно, улучшения) TN NET очень ограничены.
Поэтому большая просьба ко всем пользователям TN NET - пишите, пожалуйста, обо всех проблемах и
найденных багах(в любой форме - через e-mail конференции, на e-mail yuri at tnkernel.com, задавая вопросы в конференции etc.) .

[grinux]

Юрий, вы не планируете в ближайшее время расширения функционала TN_NET? Например в части PPP протокола.
Что, на ваш взгляд можно взять как заготовку, как вы взяли BSD стек, для последующей интеграции с TN_NET\TnKernel?
Из открытых исходников я просматривал PPP для lwIP, который сделан на основе pppd из Linux, а также реализацию из Ethernut. Последняя весьма стройна и использует похожую идеологию пулов памяти.

[yuri_t]

Что бы написать PPP, нужен соответствующий реальный (в смысле не учебно-выдуманный) проект, например,
взаимодействие с каким нибудь wireless модемом. Пока такого проекта у меня не предвидится.
В планах - перенос TN NET на процессоры STM32 и Luminary, но пока, к сожалению, нет на это времени.

[_NB]

Большое спасибо Григорию, Дмитрию и вообше всем пользователям TN NET
за найденные (и, главное, исправленные) ошибки !!!
К сожалению, мои возможности тестирования (и, следовательно, улучшения) TN NET очень ограничены.

Есть небольшое пожелание - обновите, с учетом исправленых ошибок, версию на сайте.

[Bender]

... Поэтому большая просьба ко всем пользователям TN NET - пишите, пожалуйста, обо всех проблемах и
найденных багах(в любой форме - через e-mail конференции, на e-mail yuri at tnkernel.com, задавая вопросы в конференции etc.) .

Заметил, что ARP запросы идут со случайным МАС отправителя. Так и должно быть?
Поправить просто:
в функции arp_request() добавить строку

CODE

eh = mtod(mb, struct ether_header *);
ea = (struct ether_arp *)(mb->m_data + sizeof(struct ether_header));

bzero((unsigned char *)ea, sizeof (*ea));
bcopy((unsigned char *)etherbroadcastaddr, (unsigned char *)eh->ether_dhost, MAC_SIZE);
bcopy((unsigned char *)&ni->hw_addr, (unsigned char *)eh->ether_shost, MAC_SIZE); //add

Результат:

[Bender]

Ф-ция 'select' создавалась для классических аппликаций - где нет multithreading и все происходит
внутри одной ф-ции main(). Для малоформатных RTOS типа TNKernel 'select' "тяжеловат", да и в
общем-то и не нужен (IMHO).

В случае TNKernel/TN NET и использовании TCP sockets, task, в которой производится s_recv(), должна
только принимать по s_recv() и не в коем случае не ждать какие-то другие события, очереди etc.
Другие события, очереди etc. дожны ждать ДРУГИЕ task(s).
Результат приема должен посылаться в ДРУГУЮ task (c помощью tn_queue например).
При этом блокирующий прием работает естественным образом, а неблокирующий прием
не нужен вообще (поэтому он и не реализован).

Мне нужно принимать данные по TCP от нескольких устройств (>10), интервалы посылок разные. Придется создавать задачи по количеству устройств, выделять буфера и стеки под них - некрасиво. ИМХО применив неблокирющий прием можно обойтись одной задачей.

[grinux]

Мне нужно принимать данные по TCP от нескольких устройств (>10), интервалы посылок разные. Придется создавать задачи по количеству устройств, выделять буфера и стеки под них - некрасиво. ИМХО применив неблокирющий прием можно обойтись одной задачей.

Спрашивал у автора на эту тему в прошлом году, т.к. это позволяло в моем случае сэкономить пару задач и соответственно бесценной ОЗУ.
Думаю, не сложно это самостоятельно реализовать.

Сообщение отредактировал grinux - Oct 13 2010, 10:56

[yuri_t]

Работа с >10 одновременно открытых TCP connections - это, IMHO, в любом случае многовато для CPU с памятью ~32KB

[LightElf]

Работа с >10 одновременно открытых TCP connections - это, IMHO, в любом случае многовато для CPU с памятью ~32KB

Хм. А как связано количество одновременных соединений с объемом ОЗУ? Я почему-то думал, что вопрос скорее в объеме данных (и соответственно в размере и количестве буферов). Если изредка (раз в минуту например) передается по 10-20 байт, то почему бы и нет? ИМХО вполне типичная задача для всяческих датчиков и т.п.

[Bender]

Хм. А как связано количество одновременных соединений с объемом ОЗУ? Я почему-то думал, что вопрос скорее в объеме данных (и соответственно в размере и количестве буферов). Если изредка (раз в минуту например) передается по 10-20 байт, то почему бы и нет? ИМХО вполне типичная задача для всяческих датчиков и т.п.

Да-да, именно так и есть, небольшие порции данных раз за 1-10 секунд

[LightElf]

Да-да, именно так и есть, небольшие порции данных раз за 1-10 секунд

BTW, часто от изучения сорцов разных "мелких" TCP/IP стеков остается ощущение, что стеки оные заточены в первую голову на всякие HTTP и FTP серверы, а не на реальные применения. Типо "бутлодер с поддержкой HTTP PUT для обновления прошивки". Убил бы
Даже uIP на что мелкий, и то к делу приспособить не удалось из-за проблем с delayed acknowledge.

[yuri_t]

Каждое ТСР соединение требует приличного (опять-таки, для прс с малым кол-вом ОЗУ) объема ОЗУ для внутренних
нужд.

Если надо принимать/передавать малые объемы данных и не часто, то ТСР не нужен - UDP прекрасно справится.

[VslavX]

Каждое ТСР соединение требует приличного (опять-таки, для прс с малым кол-вом ОЗУ) объема ОЗУ для внутренних
нужд.

Порядка 200 байт на саму структуру TCP сокета (по-максимуму - с поддержкой keepalive, адаптивном MTU и селективным ACK) + собственно буфера данных на прием и передачу (от 1 байта каждый) + буфера out-of-order сегментов (на что можно забить) + буфера сборщика фрагментов (при использовании TCP также можно на них забить). ИМХО - вполне скромненько.

[grinux]

Подскажите, как использовать новый MAC адрес без полной переинициализации стека?
C IP и прочим разобрался, - закрываю все сокеты, далее net_iface1_set_addresses().
Если там же менять MAC (ni->hw_adr) то ICMP и ARP продолжает работать, а все остальное нет.

[Bender]

Хорошо, еще такой вопрос - прибор "отвалился" - что делать, ведь выйти по таймауту невозможно? вечное ожидание?

Сообщение отредактировал Bender - Oct 14 2010, 18:18

[yuri_t]

Подскажите, как использовать новый MAC адрес без полной переинициализации стека?
C IP и прочим разобрался, - закрываю все сокеты, далее net_iface1_set_addresses().
Если там же менять MAC (ni->hw_adr) то ICMP и ARP продолжает работать, а все остальное нет.

Честно говоря, никогда бы не подумал, что потребуется "на лету" менять MAC... Зачем это Вам нужно ?

Хорошо, еще такой вопрос - прибор "отвалился" - что делать, ведь выйти по таймауту невозможно? вечное ожидание?

Я не понял - Вы говорите о TCP соединении?

[Bender]

Я не понял - Вы говорите о TCP соединении?

да, о нем.
Я конечно пока "чайник", до этого пользовался только UDP.
Но вот что делать в случае, если все задачи уже ждут сообщений, и вот с одним из клиентом теряется связь. Нового клиента, вместо потерянного уже слушать некому.
Так?

[DL36]

Очень простая реализация только передачи по UDP, может кому то надо.

[grinux]

Честно говоря, никогда бы не подумал, что потребуется "на лету" менять MAC... Зачем это Вам нужно ?

Объективной необходимости нет, но меню настройки устройства построено по принципу Apply и отдельно Save. Чтобы можно было откатить неправильно сделанные настройки, сделав Reset.
Это конечно же нетрудно переделать, я же в основном хотел понять для себя, почему недостаточно на горячую заменить MAC адрес в ni->hw_adr и в SA регистрах? Он где то еще прописывается?

да, о нем.
Я конечно пока "чайник", до этого пользовался только UDP.
Но вот что делать в случае, если все задачи уже ждут сообщений, и вот с одним из клиентом теряется связь. Нового клиента, вместо потерянного уже слушать некому.
Так?

При потере связи s_recv возвратит ошибку (<0), поток разблокируется и позволит снова сконфигурироваться для повторного установления соединения.

Сообщение отредактировал grinux - Oct 15 2010, 07:14

[Bender]

При потере связи s_recv возвратит ошибку (<0), поток разблокируется и позволит снова сконфигурироваться для повторного установления соединения.

Точно так. только потребовалось установить флаг SO_KEEPALIVE, и s_recv возвращает ошибку (=0)

Сообщение отредактировал Bender - Oct 15 2010, 08:03

[LightElf]

Каждое ТСР соединение требует приличного (опять-таки, для прс с малым кол-вом ОЗУ) объема ОЗУ для внутренних
нужд.

Как здесь справедливо заметили - не так уж и много нужно. В 32к таких мелких сокетов можно изрядно наплодить.

Если надо принимать/передавать малые объемы данных и не часто, то ТСР не нужен - UDP прекрасно справится.

Именно так и думал. Но админы всяких VPN/проксей/файрволлов/и т.д. думают иначе, в результате чего UDP трафик цинично рубят на корню.

Сообщение отредактировал LightElf - Oct 15 2010, 11:18

[YAM]

BTW, часто от изучения сорцов разных "мелких" TCP/IP стеков остается ощущение, что стеки оные заточены в первую голову на всякие HTTP и FTP серверы, а не на реальные применения. Типо "бутлодер с поддержкой HTTP PUT для обновления прошивки". Убил бы
Даже uIP на что мелкий, и то к делу приспособить не удалось из-за проблем с delayed acknowledge.

А для uIP есть спец. фишка. Для ускорения работы передавать два одинаковых пакета при ненулевом размере данных. Не знаю как у кого , но у меня WEB сервер на этом просто летает по сравнению с обычной передачей (LPC1768 стоит в связке с KSZ8721BL).

[yuri_t]

Чтобы иметь возможность неблокирующего приема в TN NET TCP, достаточно в файле tn_tcp_sockets.c (TN NET v.0.9) добавить после
линии 566 следующее выражение

Код

       if(so->so_state & SS_NBIO) //-- For non-blocking socket - exit
            return -EWOULDBLOCK;

Было:

Код

      if(m)
         break;
      else
      {
         splx(tnet, sm);
         tn_net_wait(&so->so_rcv.sb_sem);
      }

Стало:

Код

     if(m)
         break;
      else
      {
         splx(tnet, sm);

         if(so->so_state & SS_NBIO) //-- For non-blocking socket - exit
            return -EWOULDBLOCK;

         tn_net_wait(&so->so_rcv.sb_sem);
      }

Все другие части TCP(в том числе и tcp_s_send() )
уже готовы для работы в неблокирующем режиме SS_NBIO.

[AntonPV]

Прошу прощения,может есть такие,у кого есть опыт использования DP83848 в качестве PHY в TN NET?

Сообщение отредактировал AntonPV - Nov 16 2010, 16:05

[Pavel V.]

Я попытался портировать стек на процессор LPC1768, но до конца он так и не заработал. Может быть у кого-нибудь был подобный опыт?

Свой проект выложил в соседней ветке: http://electronix.ru/forum/index.php?showtopic=84637

Наверняка мелочь какая-нибудь осталась, но сил больше нет

[prgjz]

Да, выложил в указанном топике. В tn_net_cfg.h
#define USE_PHY_KS8721 или
#define USE_PHY_DP83848C выбрать.

[spf]

Ошибочка обнаружена в проверке на multicast, не работали адреса xx.xx.xx.224 - xx.xx.xx.239 (пинг проходит, а соединение не устанавливается)

Код

Index: tn_tcp_input.c
   ===================================================================
   @@ -309,7 +309,7 @@
       th   = (struct tcphdr *)(((unsigned char *)m->m_data) + iphlen);
       tlen = m->m_tlen - iphlen;         //-- TCP header + data
    
   -   if(IN_MULTICAST(ip->ip_dst.s__addr) || in_broadcast(ip->ip_dst, ni))
   +   if(IN_MULTICAST(ntohl(ip->ip_dst.s__addr)) || in_broadcast(ip->ip_dst, ni))
          goto drop;
    
       if(in4_cksum(m, IPPROTO_TCP, iphlen, tlen))
   @@ -492,7 +492,7 @@
             //--  packet with M_BCAST not set.
    
             if(m->m_flags & (M_BCAST|M_MCAST) ||
   -                                    IN_MULTICAST(ip->ip_dst.s__addr))
   +                                    IN_MULTICAST(ntohl(ip->ip_dst.s__addr)))
                goto drop;
    
           //---- Digest of the in_pcbconnect() for tcp_input()
   @@ -1205,7 +1205,7 @@
       //-- Don't bother to respond if destination was broadcast/multicast.
    
       if((tiflags & TH_RST) || m->m_flags & (M_BCAST|M_MCAST) ||
   -                                  IN_MULTICAST(ip->ip_dst.s__addr))
   +                                  IN_MULTICAST(ntohl(ip->ip_dst.s__addr)))
          goto drop;
    
       if(tiflags & TH_ACK)

Прикрепленные файлы

 tn_tcp_input.txt ( 1.23 килобайт ) Кол-во скачиваний: 97

 

[yuri_t]

Ошибочка обнаружена в проверке на multicast, не работали адреса xx.xx.xx.224 - xx.xx.xx.239 (пинг проходит, а соединение не устанавливается)

Спасибо!

[spf]

Когда ожидается вариант со всеми доработками?

PS:
При наличии системы ведения версий было бы крайне просто актуализировать доработки.
Можно было бы вообще обойтись без архивов релизов.

[megajohn]

Когда ожидается вариант со всеми доработками?

Кстати, какие замечены косяки ?
я нашел только про
tcp_respond CRC

Сам же я напоролся на следующий косяк, в функции arp_request не инициализируется MAC отправителя
нужно после bcopy((unsigned char *)etherbroadcastaddr, (unsigned char *)eh->ether_dhost, MAC_SIZE);
добавить
bcopy((unsigned char *)ni->hw_addr, (unsigned char *)eh->ether_shost, MAC_SIZE);

ну и еще мелочь:автор задал такой вид конфигурирования #define TN_DHCP 1 подразумевая что выключатся будет через #define TN_DHCP 0 то в местах применения писать не #ifdef TN_DHCP а #if TN_DHCP == 1

[megajohn]

Сам же я напоролся на следующий косяк, в функции arp_request не инициализируется MAC отправителя

Оказывается, об этом было известно еще три года назад, и напоролся на это Bender.
Извиняюсь на непреднамеренный плагиат, то вчера весь день убил на поиск этой траблы
Я то думал, что скачивал самую последнюю версию с сайта с фиксами. А оказалось что казалось.

[megajohn]

Поэтому большая просьба ко всем пользователям TN NET - пишите, пожалуйста, обо всех проблемах и
найденных багах(в любой форме - через e-mail конференции, на e-mail yuri at tnkernel.com, задавая вопросы в конференции etc.) .

№1
IAR ARM 6.6 ругается на невыровненное обращение Warning[Pa039]: use of address of unaligned structure member I:\projects\_lib\protocol\ip\tn_net\in4_cksum.c 123
u.ipov.ih_src = mtod(m, struct ip *)->ip_src;
u.ipov.ih_dst = mtod(m, struct ip *)->ip_dst;

№2
в функции udp_s_recvfrom не особо нравится поведение, если пришло данных больше чем запрашивалось.
к примеру нужно только 16 байт, а пришло 128. Записать только 16 и вернуть результат 16. ( по крайней мере в NDK для TI SYS/BIOS вроде так )

№3
udp_s_sendto блокирующая отправка работает если только нет пулов памяти. А пулов больше чем передающих дескрипторов, а в очередь передачи отправка размещается с полингом. а не блокировкой.
Получается что задача которая все время отправялет UDP не дает процессорного времени всем более низкоприоритетным задачам. А лучше бы на момент отправки и реальной передачи блокировалась задача. Вроде так