Me pripada, ze flowcontrol na obou stranach je dost nezavisla vec.
Si musim sam sebe opravit - nekde jsem cast toho standardu vystrachal.
Informace o podpore flow-control je soucasti negociace (zrejne NWAY)
spojeni, takze karta by mela vedet, zda protistrana podporuje.
Coz automaticky vede k jinemu zaveru - tak jako je nekdy problem s
negociaci duplexu a/nebo rychlosti nebot' nepresnou implementaci si
karty v negociaci dobre nerozumi, muze byt nepochybne problem i s
negociaci tohohle.
Ale zbytek toho, co jsem napsal, plati - pokud karta implementuje
moznost povolit/zakazat dohodu o flow-control, tak to bude specifickou
komunikaci s hardwarem (u Realteku je to napriklad nastavenim ENFCTRL
bitu na jedna). Ale vubec tam schopnost zapinat/vypinat byt nemusi. A
stejne tak proprietarni (a mozna nepritomny) muze byt nechamismus pro
zjisteni v jakem vyslednem stavu karta nakonec je.
Jeste me tak napada - XOFF/XON flow-control signal je ve skutecnosti
celkem obycejny paket typu ETHERTYPE_FLOWCONTROL zasilany na
multicastovou adresu 01:80:C2:00:00:01 - v promiskuitnim modu karty by
prichod toho paketu mohl byt videt. Ale nemusel - je dost dobr emozny, z
enektere karty ho nahoru nepredaji - obzvlast pokud bude zrovna
flow-control aktivni. Takze - pokud paket uvidis, vis, ze protistrana
flow-control podporuje, pokdu ho neuvidis, nevis nic ...
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
