Path: utzoo!attcan!uunet!mcvax!cernvax!jmg From: jmg@cernvax.UUCP (jmg) Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP's & IP src addrs Message-ID: <836@cernvax.UUCP> Date: 26 Sep 88 16:44:02 GMT References:<8809221807.AA07284@ucbvax.Berkeley.EDU> Reply-To: jmg@cernvax.UUCP () Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 28 >>Now wait a minute....It's one thing to reply to the local IP broadcast >>address - it's another thing to use the Ethernet broadcast address as >>your source address! DEC Lanbridges don't look at anything higher than >>that. They should ignore multicast/broadcast addresses as a source >>address (although I don't really know if they do). >> >Doug Nelson >Michigan State University If you have LANBridges with version 2 of their software then it is true that they can be got into the state where no broadcasts go through (but multicasts are OK). This bug was not in version 1.0. Of course, both versions had bugs if you use RBMS to change costs of lines, bridges etc. The broadcast problem certainly is provoked if the LANBridge sees a packet whose source address is ffffffffffff. To clear it the bridge has to be reinitialised. The symptoms are obvious: new tcp/ip connections fail, but old connections, plus ones where the ethernet address is already in cache, continue to work, as does DECNET. Thus, all the people with Vaxstations do not want the Ethernet touched, for fear that their station will need rebooting, but all the TCP/IPersons want it fixed. How to become unpopular in one easy lesson! -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland