не е чудо невиждано да ти цъфне пакет с грешно CRC (на етернет ниво). някои контролери нямат хардуерна сметалка и процеса се скипва заради скорост.

с фрагментираните пакети е по-сложно. зависи от къде е минал пакета, какво още върви през въпросния рутер, кога е дялкан фърмуера, щото излизат нови RFC-та, вкарват повече математика в управлението на опашките и т.н. QoS (сега DSCP) битовете може и да им се обърне внимание, може и да не им се обърне внимание, дори е разрешено да се пренапишат и следващия рутер съсвем да осере пейзажа. същото е и с Don't Fragment (DF) флага. рутера, ако трябва да фрагментира (през него върви телефония или видео, примерно), може или да дропне такъв пакет или да го фрагментира, независимо че е забранено. а ако някой почне да точи и джъмбо фреймове, какъв пакет и кога ще дойде до тебе е божа работа вече. и е съвсем нормално, фрагментирани пакети през натоварен рутер да се доберат при тебе рабъркани. а пък и последния рутер преди тебе може да така добричък и да ти го сглоби наново. на всичкото отгоре поведението на алгорирмите зависи от скоростта на физикалния порт - едно е за 10/100, друго за 1000.

не че имаш печеливш сценарии във въшка с 4К памет. просто ти обръщам внимание за нормално случващи се неща, ако не си на същия суич, а минаваш през повече рутери на различни производители.

хмм.. мисля, че lwIP е наясно с тия проблеми. Поне се надявам, щото покрай eCos-a уж го поизчистиха, но като почна да дебъгвам ще го разгледам пак

Въпросът е, че ST от някъде са взели тоя MAC и той като цяло изглежда прилично. Проверява и детектва един куп неща. Но софтуерът им е друга бира. Значи за джелязото пише, че ако открие грешка в първите 16 байта директно изхвърля пакета. Ако е след това, DMA-то вече е зацепило и метнало някакви байтове един, два-три, неизвестно колко, но при грешка просто го спират докъдето е и в статуса на дескриптора отбелязват че пакета е кофти.
Тия обаче без да проверяват направо го мятат към стека. А той колкото и да е добър няма как се оправи, защото се конфигурира да не проверява CRC-та, няма информация колко са реално получените байтове, демек и дължината да иска не може да провери. Просто едно парче памет с неясно съдържание, писано-недописано... В най-добрия случай нещо по хедърите няма да излезе и ще го игнорира, ама не се знае знае ли се...

А отделно колко лесно може да се омаже не е истина просто. Аз затова питах някой ползвал ли го е, щото то при един куп ситуации остава в небитието. Освен да имат някое скрито куче да ги ресетва от време на време. Щото без куче аз не виждам как ще работи тва нещо.

16? ъъъ?

най-късия смислен хедър е 20 байта

64

aaa, тва е друго нещо. аз реших, че още чул-недочул дали е за него (дестинейшъна съвпада), DMA-то почва да вади пакета.

а буфера вижда ли се?
проверявай първо дали изобщо ти харесва протокола и чак тогава пали DMA-то да извадиш пакетя.
МАС-а може ли да смята CRC-та на по-високо ниво (TCP, UDP...)?

абе то е направено само да пере, чисти и готви

Има филтрации, смята няколко crc-та, проверява дължини и разни такива. Но идеята е всичко да прави само и да не се налага намеса на проца... Даваш му кръгов списък с дескриптори и то не спира докато не ги свърши.
Процът като има време и той се върти по кръга и гледа да догони. Всеки дескриптор има битче "мой-твой". Аз чакам DMA-то да смени битчето и тогава гледам какво е получено, съответно като свърша с гледането вдигам обратно битчето, за да знае DMA-то че може пак да ползва буферчето.

Хитро е направено (явно не от ST), няма почти никакъв овърхед да пускам/спирам DMA-та. Само едно битче и толкоз. Всъщност още едно профилакточно писане на един регистър се прави с произволна стойност. Тва в случай че DMA вече е спряло да тръгне пак по кръга.

нещо съм оплел жиците... пфи-то не ще да си вдигне линк статуса, утре ще го гледам що.
Поне си приказвам с него, регистрите му връщат коректни стойности... Може и аз нещо да не съм му конфигурирал, макар че като му гледал регистрите трябва да си тръгне директно. Ще видим

А и иначе ST имат код и за MII и RMII но очевАдно второто никога не са го тествали щото определено има бъгчета.

линка го вдигнах, ама съвсем се оплетох...

Платката ми беше с REF CLK да го прави STM-a. E правеше го, ама.... пакети до 60 байта (разни броадкасти) ги получавах без проблем, по-големи от тоя размер задължително с грешно CRC. Като пращах (DHCP заявки от по 350 байта) веднъж или два пъти най-много да ги видях с wireshrk-a.

Ta реших да оправя клоците, сложих 25MHz кристал на phy-то, то прави 50MHz REF CLK и него ползвам за RMII. След тая революция пращането проработи на 100%, няма пропуск всички пакети дето пращам ги снифвам с акулката. Получаването обаче ми изчезна на 100%. Ни един пакет. Пфи-то мига ламбата за трафик като побъркано. Има там някакъв регистър за грешно получени пакети - върти се като финтилатор. Някаква простотия ще да е, ама нямам идея каква? Сто пъти огледах платката нещо да не съм осрал, няма...

Звучи все едно да получава колизии. Не съм много навътре на физическо ниво на сигналите, но когато се засече колизия се генерира сигнал, който е по-силен от този който ползва да предава данните, все едно PHY -то интерпретира данните като колизии. ЪЪЪ пробвай да размениш местата на входните жици или пробвай да сложиш някакви резистори. Имаш трансформатор нали?


Edit: Добавих снимка от PDF-то.
Тази част от схемата си я изпълнил 1 към 1 нали?
Резисторите трябва да са точни.
Размени RXP и RXN от трансформатора към PHY -то.
Пробвай между RXP и трансформатора, както и RXN и трансформатора да сложиш резистори 27 ... 50 ома.
Чесно да си призная на момента гадая. Да няма проблем със синхронизацията между контролера и PHY -то при приемане?

В общия случай като има колизия се чака някакво време(случайно) и се прави друг опит (CSMA/CD).

... като има колизия се чака някакво време(случайно) и се прави друг опит (CSMA/CD). - да приеме пакет ли?

приемането е хубаво да се клочи от PHY, а предаването от МАС. изобщо - който говори, той клочи.
за целта трябва да сетнеш съответните двойки регисти в МАС и PHY.

за приемането обяснението е, че клока е добре да се възстановява от жицата и понеже може да има джитер с клока на МАС, по-лесно е да се клочи направо МАС-а от данните. при предаване е обратното - МАС-а никой не го знае кога ще натопорчи данните и какъв диалект ще говори, затова най-добре е PHY-то да го слушка и да папка (данни).

срещал съм и някакви разсъждения за това клока на МАС и PHY да са еднакви или с 2 кварца. аз слагам по 2 независими.

За това става дума - при колизия няма как да се генерира какъвто и да било сигнал - само ще се влоши положението. Предавателите чакат известно време и пробват пак.

при медия усукана двойка няма как да възникне колизия, ако е вързана към нормален суич.
брояча на тези пакети си седи на нула, дори при десетки гигабайти трафик. аз дори не го връзвам тела COL

Ми не. Когато засекато колизия, предавателите започват да генерират jam signal за да са сигурни, че получения пакет е прецакан - няма значение ти как го чустваш - те си го генерират и не им пука.
Освен това, не знам къде намеси предавателите, при условие че, miro_atc каза: "След тая революция пращането проработи на 100%", "Получаването обаче ми изчезна на 100%. Ни един пакет. Пфи-то мига ламбата за трафик като побъркано. Има там някакъв регистър за грешно получени пакети - върти се като финтилатор."
Единия вариант да ПОЛУЧАВА грешки вместо пакети, е PHY да засича нормалните пакети, като колизии. Тук въобще не говорим за предавателя, който си работи на 100%.


Това не е вярно. Може да се получи колизия, ако усуканата двойка е свързана към ненормален суич(хъб) или ако нормален суич е нафлуден с MAC адреси и тогава почва да се държи, като хъб.