Daniel Dvořák napsal/wrote, On 11/27/07 13:25:
>>> A-->--C--><--B
>>> Postizeny router C nema firewall.
>>> echo reply dorazi z B na iface 2 routeru C, kde vsak take je naposledy
>>> spatren v tcpdumpu a na iface 1 routeru C je videt jen ten request.
> Predpokladas spravne, ze v tom rozhrani vedoucim k A na routeru C uz se
> ztrati i ten request z B. Nicmene co je zajimave Ccko Acku odpovida
> zpravou icmp ICMP time exceeded in-transit, kdyz se na B pinga z A nebo
> jeste z neceho jineho za Ackem treba Xko X..........A-->--C--><--B.
>>> FreeBSD 6.2-STABLE
>> Ponekud odvazna volba pro produkcni stroj.
>>
> No, sam si nekolikrat uz uvadel ze nekde bezis i current, tak to je
> jeste vetsi hazard nez ten stable ne ?
Si me pletes s Romanem, ale odpoustim ti ;-)
> Kdyz cron v 3 minutovem intervalu zavolal sysctl reload (mam fastforward
> na 1 v sysctl, nejak se mi nepodarilo to zapinat lepe nez takto, v
> default/rc.conf na to nic neni)
V default/rc,conf urcite ne, do toho bys sahat nemel.
Na tohle je /etc/sysctl.conf
> server C# netstat -s -p icmp
> icmp:
> Output histogram:
> echo reply: 3433
> destination unreachable: 4189105
> time exceeded: 230658
> Ja to ted vidim jako ze nevidime nic. :D
No, naslo se reseni - nebo - prinejmensim workaround. To neni zas tak
uplne na kocku.
ICMP_TIMXCEED je priznak vycerpani TTL. To by vedlo k podezreni, ze za
teto konkretni konfigurace dochazi k "forwardovani ve smycce" a paket se
v jadre toci tak dlouho, dokud neni TTL vycerpane.
Za to ale tezko muze fast-forward samostatne, to byde podmineno jeste
nejakymni dalsimi okolnostmi. Jakymi presne se ted neodvazuju hadat.
> Jak muze nejaka chyba v kismetu
Kismet neznam, takze nevim co dela.
Dan
--
Dan Lukes SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
