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

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

- по поводу портирования 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)

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

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

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

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

www.tnkernel.com

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

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

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

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

Вышла версии 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 ?

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

Ф-ция '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 например).
При этом блокирующий прием работает естественным образом, а неблокирующий прием
не нужен вообще (поэтому он и не реализован).

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

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

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

Можно



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

Здоровско!



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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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



Результат:
Нажмите для просмотра прикрепленного файла

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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




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

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

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


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

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

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



Было:



Стало:



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

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

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

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

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