Ping = (DUP!), Mystisk netværks problem

Tror ikke at din box er fejl konfigureret, jeg oplever samme fænomen fra indtil flere linux boxe med www.dr.dk, jeg har windåserne mistænkt for at være for dumme til at rapportere problemet.

Har læst at problemet kan forekomme hvis der er kludder i broadcast og gateway adressen på den site du pinger. Skulle kunne simuleres på linux ved at pinge sin egen broadcast adresse!

Det er korrekt, hvis jeg pinger min interne, (10.1.1.0), broadcast adresse får jeg svar fra nogle af de andre hosts der er på det interne net men der står så (DUP!) i adressen. Sjovt nok er det kun nogle af host\'ene der svarer. En Linux box mere og så vores printer server??

Kan det være sådan at Windoze maskinerne slet ikke svarer på det her?

Nå men tilbage til problemet. Vi har flere maskiner med public IP her i firmaet. Det sjove er at hvis jeg tager vores RedHat 7.1 som er på præcis samme eksterne net som StormLinux\'en og benytter samme GW er der ingen problemer. Her kan jeg både pinge, (uden DUP!), og browse www.tivoli.dk.
Det glemte jeg lige at nævne før, (sorry).
Men det er også herudfra at jeg udleder at det næsten må være noget opsætning på min Stormlinux.

Check broadcast adressern på GW for at se om der er sammenfald med IP\'en for StormLinux\'en

Broadcast adressen er god nok.
Vi har et net med 32 adresser startende fra 32, (netværks adressen).
Broadcast adressen hedder 63 på begge maskiner og det må jo være rigtigt nok. Maskinerne hedder henholdsvis 34 og 40.

Jeg prøvede lige at deaktivere det eksterne interface på min Stormlinux og sætte GW op til den anden maskine. Så forsvandt min (DUP!) píng problemer men jeg kan stadig ikke gå ind på visse sider. www.tivoli.dk og www.nvidia.com. Hvis jeg så sætter min konqueror op til at bruge proxy serveren på den anden maskine virker alle adresser perfekt. Pænt underligt????

Nå nu fandt jeg ud af. Det havde slet ikke noget med (DUP!) at gøre. Derimod var det at nogle routere ikke kan finde ud af at svare på pakker med ecn slået til. Forklaring følger:

Why does the 2.4 kernel report Connection refused when connecting to sites which work fine with earlier kernels?
(DW) The 2.4 kernel is designed to make your Internet Experience more pleasurable. One of the ways in which it does so is by implementing Explicit Congestion Notification - a new method defined in RFC 2481 for improving TCP performance in the the presence of congestion by allowing routers to provide an early warning of traffic flow problems.
Unfortunately, there are bugs in some firewall products which cause them to reject incoming packets with ECN enabled. If your own firewall is broken in this respect, you should check with your vendor for a fix.
If the site to which you cannot connect is not under your control, then after you have contacted the administrator of the offending site to let them know about their problem, you can disable ECN in the 2.4 kernel either by disabling the CONFIG_INET_ECN option and recompiling the kernel, or by executing the following command as root:
# echo 0 > /proc/sys/net/ipv4/tcp_ecn
(REG) Fixes are available from some router vendors, and have been since at least mid-2000. These are not \"feature patches\" (which may add new features and have new bugs), but purely bug fixes, and thus should be safe to use, even for the most paranoid. If you have problems connecting to a site, please contact their support. Note that some major sites are known to have lied about fixes from their router/firewall vendor, so if you hear the excuse \"we are waiting on a fix from our vendor\", be skeptical. While there is a workaround available (see above), it is important to encourage sites and ISPs to be ECN tolerant. This doesn\'t mean that these sites need to support ECN (although it\'s in their interests), but they need to fix buggy routers so that ECN-enabled systems can fall back to non-ECN mode, rather than having refused or timed out connections. The specific RFC that these buggy routers are violating is: RFC 793.