🚀 go-pugleaf

In article <BILLB.92Nov20194414@kuwait.gdfwc3>, billb@gdfwc3 (Bill Baumann) writes:
> 
> My PowerSeries 310 is behaving strangely.  I'm hoping for some advice.
> 
> The SGI machine is resending FDDI MAC broadcast messages which have a
> destination IP address of that same machine.  Why would it forward messages
> destined for itself?  It resends the messages on to two Harris Nighthawks on
> the ring.  Why these two, and not others?  I have no idea...  It would seem
> that the SGI FDDI device driver has some potent AI, knowing that our
> Nighthawks
> would appreciate an extra copy of these messages.
> 
> I am trying to get an underdevelopment multibus II FDDI card working.
> Presently it is missing ARP.  So for now, all outgoing messages are broadcast.
> Thus the destination MAC is BROADCAST.  The destination IP is the SGI machine.
> Source IP, and MAC are of the MBII card.  The messages are UDP/IP, 2k bytes
> long.
> 
> A process waiting for these messages on the SGI never receives a thing from its
> "recvfrom".  My FDDI analyzer shows the messages being broadcasted, and then
> resent by the SGI.  The resent messages have the source MAC address of the SGI
> machine, and destination of the two Nighthawks.  Otherwise, the messages are
> identical to the original, with the destination IP address being that of the
> sending SGI machine.
> 
> msg1	src MAC		MB II card
> 	dest MAC	BROADCAST
> 	src IP		MB II card
> 	dest IP		SGI machine
> 
> msg2	src MAC		SGI machine
> 	dest MAC	Nighthawk#1
> 	src IP		MB II card
> 	dest IP		SGI machine
> 
> msg3	src MAC		SGI machine
> 	dest MAC	Nighthawk#2
> 	src IP		MB II card
> 	dest IP		SGI machine


If the destination address were not broadcast, the forwarding by the
4D/310 could be caused by badly configured IP network or netmask
numbers on one or more of the machines.

It would be interesting to check the routing tables (`netstat -r`) and
networks and netmasks on the 4D/310 (`ifconfig ipg0`).  `netstat -C`
can be used to see what forwarding other other strangeness is
happening.  It might be interesting to see what `arp -a` says,
especially about the Nighthawks.

However, I suspect something else is going.  Since IRIX 4.0 (or maybe
before, I forget) we have been following H.R. which says that you
should mark MAC broadcast or multicast packets in the driver and not
forward them.  Thus, even if the machine is a "router" by virtue of
having two interfaces and ipforwarding=1 in /usr/sysgen/master.d/bsd,
it will not forward packets that are broadcast or multicast.  (Well,
mrouted turns on some multicast stuff.)  It is obviously possible that
there are bugs in that code, from setting the mbuf header bit in the
driver to noticing it in the IP forwarding code, but I honestly doubt
it.

A couple of other possibilities suggest themselves.  One is that the
packets the MB II device is sending look like broadcast "bootp" or
RFC-951 packets, and if /usr/etc/inetd.conf has turned on forwarding
with -f, then the 4D/310 could be trying to help the MB II machine
boot.

If you have the SGI "netvis" product, I'd use the `netsnoop -i ipg0`
command to decode the FDDI packets.

If you are not running IRIX 4.0.5, then it would be wise to install
it.  It would also be wise to install FDDIXPress 3.0, because the IPG
FDDI code is much faster, and because we've bundled fddivis with it.

The mystery with the Harris machines suggests to me none of this is the
problem.  Then there is the mystery of the packets containing the SGI
destination IP address.

How do you know that the strange packets are coming from the SGI
machine?  Because of the source MAC address?  That, of course, is not
convincing evidence.

How big is your ring?  Could the MB II card be receiving its own
broadcasts and confusing its own higher IP layers?


Vernon Schryver,  vjs@sgi.com