Имам вървяща платка с микрочипски PIC с Ethernet. Стека е последния (4.18), компилатора е 3.15 мисля (последния).
Всичко върви (https2, telnet, tcp server demo) с изключение на клиентските TCP сокети. Когато опитам да отворя връзка към отдалечен хост, на който върви приложение с listen сокет, не става нищо. Гледам с wireshark пакетите, но не излизат заявки за отваряне или дори за ARP. TCP client demo-то също не изкарва нищо. Единственият начин да видя пакети за сързване е като задам TCPopen да използва директно IP адрес, но дори тогава зацикля - по sniffer-а виждам ARP запитване за MAC-а на сервера, идаващо от PIC-a, после се вижда ARP отговора на компютъра, и след това се появява пакет от PIC-a, TCP, със сетнати флагове за ACK и RST, т.е. PIC-a решава да отмени връзката. Около 5 мс по-късно идва същата последователност от 3 пакета, като разликата е, че последния (TCP) пакет е с друг source порт (увеличен с единица спрямо предишния цикъл). Така върти групи по 3 пакета безспирно до засиняване, като изрежда сорс портове от 1024 нагоре (което не знам дали е коректно - ако не е отворил връзката по 1024-ти сорс порт, защо ще избира 1025-и? ама това май е от имплементацията на микрочип). Дестинешън порта е очаквания от мен и отворен за listen на PC-то.
Опитах както с DHCP настойки, така и с фиксирани IP адреси. Всичко е въведено коректно и е валидно за дадената мрежа (gateway, DNS, маска).

Тъй като имам проблеми с ICD2-то с тази платка, не мога да се закача да дебъг-на и карам на проба и грешка.
Забелязах, че има проблеми с компилирането на последните версии на стека с последните компилатори, както и че има някой недокументирани промени. Не знам дали това може да е проблема, но ще опитам с по-стара версия.

Ако някой се е сбълсквал с този проблем, моля да помага!

Видях поста ти в Майкрочипския форум днес и очаквах jamodio да се намеси, но ...

Аз използвам точно неговата модификациs на стека (www.ljcv.com) и за разлика от оригиналната, тя е доста по-разбираема. Пуснах точно клиентското приложение. Само, че в стейт машината на GenericTCPexample забранявам инкрементирането на клиентския порт и зациклям в очакване на отговор от сървъра. Изглежда, че клиентското приложение е с твърде малък тайм-аут и решава, че сървъра не отговаря и затова опитва отново и отново. Имат значение и таймингите на сървъра. Друго преимущество на тази модификация на стека е, че лесно се коригира за съответния хардуер, а и е базирана на една от най-стабилните версии.
Утре ще погледна разбазикания сорс и какво точно съм разбазикал, защото и при мен първоначално не тръгна.
Успех!

Мерси за отговора.
И аз се бях насочил към таймаут, защото явно смята че не са му отговорили и опитва наново - все пак чака само 5мс, туй да не е real time ethernet. В други tcp/ip стекове име опция за port reuse и ако не е зает порта, ще опита отново през него да отвори, но в майкрочипския не немерих подобна възможност.
Да, и аз след известно четене реших, че ще е по-добре да ползвам версията на Jamodio, че без дебъг ще е трудно да търся проблеми, каквито явно не липсват в 4.18
Доколкото разбирам, си се сблъсквал със същия проблем, който описах? Това поне е нещо, явно има проблем в стека.
Ако намериш какво е променено в твоята версия, ще съм благодарен.
Аз ще драпам по проблема като остане време, ако намеря решение ще пиша.

Оказа се, че последно таймингите съм ги върнал към изходните. Сега си спомням, че това изобщо не помогна, но тогава забелязах, че в switch(GenericTCPExampleState) не всички състояния завършват с break, а се преминава директно към следващото състояние защото GenericTCPExampleState е вече инкриминтирана, което означава, че между състояниятя не се вика функцията StackTask(). Стори ми се, че това би могло да бъде причината и сложих break; в края на всеки case. След отваряне на сокета зациклям в състоянията SM_SOCKET_OBTAINED и SM_PROCESS_RESPONSE. Така не позволявам да се отиде към ресет и инкрементиране на порта, ако сървъра не отговори навреме. Разбира се, това не е завършено приложение, поне дава идея как да ти заработи клиентското приложение.

Намерих проблема - незнам дали е същия, но при мен липсваше повикване на TCPWasReset() след TCPOpen() - според коментара на функцията, първото повикване винаги връща true; добавих едно фиктивно викане след TCPOpen() и нещата заспаха.

Gicho, с какъв процесор си, че аз вече 2 дена се боря безуспешно със стека 4.18 и 18F66J65.

С 18f67J60.

Тъй и тъй съм почнал, поне да си напиша проблема че да не отварям нова тема. Та проблема е, че не получавам пакети. Гледам че светодиода на RX премигва и това би трябвало да значи, че пика приема някакви пакети. Гледам с дебъгера че EPKTCNT е винаги нула и MacGetHeader винаги връща FALSE, т.е. реално няма приети пакети, които да бъдат обработени. Пробвах да махна всички филтри, но без резултат. Гледам че пика праща ARP заявки за MAC адреса на getaway-а, за какъвто съм сложил компютъра си, компютъра връща отговор, но пика си продължава да си праща заявки, все едно няма отговор, т.е. пак нищо не получава. Вече не знам аз ли съм тъп или тоя стек е нещо бъгав или чипа е дефектен, защото стека 3.75 със ENC28J60 и PIC18F45J10 тръгна от първия път, а този вече 2 дена се дърпа...

Това, което си описал, при викане на connect ли става?

Не, въобще е така. Но се оказа че по някаква причина трябва да се разменят TPIN+ и TPIN- входовете. Съжалявам, че моя проблем не е за тази тема, но не ми се пускаше нова.