Tohle SW neudělá - protože CRC spočítá přímo MAC. Podobné problémy ladím běžně, HUB Vám ani moc nepomůže, protože většina běžných séťovek paket s vadným CRC nepustí. Problém bude HW nebo semi-HW.
Ne problem je vazne nekde v SW. Posledne to bylo v chybne vlozene 802.1Q hlavicce. A ohledne CRC mate skoro pravdu. Nastesti jde sitovka donutit prijimat i pakety bez overeni CRC a protoze je to v linuxu, neni problem k tomu presvedcit i driver. Dost HW ma moznost to resit pomoci SW, ale v praxi se to moc nedela, protoze mame pro procesor uzitecnejsi traveni casu nez vypocet CRC, ktery muze delat a overovat HW.
Tohle mě potenciálně zajímá. Zatím jsem narazil na položku
rx-fcs a
rx-all ve výpisu
ethtool -k , a dále na #defines E1000_RCTL_SECRC (patrně odpovídá rx-fcs) a E1000_RCTL_SBP (store bad packets - natvrdo vypnuto - k čemu to je?) v kódu ovladače Intel igb (pro i210/i350 a další). A na i210 vidím ethtoolem rx-fcs off [fixed], ale rx-all je patrně možné povolit...
tady je k tomu nějaký komentář, jinak to dokumentované moc není. Zdá se, že
rx-fcs on znamená "FCS neořezávej, ale předej vyšším softwarovým vrstvám" a
rx-all on znamená "nezahazuj rámce s vadným checksumem, předávej softwaru všechno". Pokud si dneska koupíte na odposlech gigovou intelku, velmi pravděpodobně se bude jednat o i210 nebo i350 (obě obsluhovány driverem igb.ko). Pokud se týče stovkových optických síťovek, viděl jsem je s čipy Broadcom nebo Realtek, nevylučuji ani další výrobce. Mám tady namátkou jednoho stovkového optického realteka (8139too) a ethtool hlásí rx-fcs i rx-all sice oboje off, ale nikoli fixed - a skutečně jdou povolit.