litwack@dccs.upenn.edu (Mark Litwack) (09/21/90)
It's taken me a while to finally figure this out, but
it seems that Ungermann-Bass PC-NIU/ex cards occasionally
send out an ICMP host unreachable message to a host that's
sending too much TCP data to another host on the local
ethernet. This has the effect of severing the TCP connection
between the two innocent hosts. I have captured the culprit
packets and the PC is cleary in the wrong. So far, it's only
happened on PCs which are running Novell and U-B NetNone TCP
at the same time.
I also found that while Ultrix systems cause the TCP application
to bomb out when it receives the packet, Suns are not affected.
I guess they have some kind of sanity check for ICMP messages.
Has anyone ever seen this? I'm really annoyed at U-B. Their
technical support line didn't know what ICMP was and they wanted
to know how many stop bits I was using so that they could re-create
the problem in their lab.
-mark
For those who are interested, here is a sample packet for
entertainment value. kiwi.dining is a PC, scotty.dccs is
a DECstation 3100, remote.dccs is a uVax II. Scotty.dccs
is sending data to the TCP sink socket on remote.dccs.
Frame Length: 74 Slice Length: 70
Errors: None
Recv Channels: tcpip
ethr: Station 00 DD 01 02 DD 98 ----> scotty
Type IP
ip: ICMP 128 91 16 59 -> 128 91 254 4
(kiwi.dining) (scotty.dccs)
Data:
0000 03 01 7C C1 00 00 00 00 45 00 04 28 C1 A9 00 00 ..|A....E..(A)..
| |
| -- Code (host unreachable)
|
-- Type (ICMP)
0010 3C 06 B8 5E 80 5B FE 04 80 5B 02 0D 11 95 00 09 <.8^.[~..[......
|-source--| |--dest---|
128.91.254.4 128.91.2.13
(scotty.dccs) (remote.dccs)
0020 0A 9E 64 01 ..d.mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (09/21/90)
In article <29878@netnews.upenn.edu> litwack@dccs.upenn.edu (Mark Litwack) writes: >It's taken me a while to finally figure this out, but >it seems that Ungermann-Bass PC-NIU/ex cards occasionally >send out an ICMP host unreachable message to a host that's >sending too much TCP data to another host on the local >ethernet. This has the effect of severing the TCP connection >between the two innocent hosts. This is a bug in 4.x BSD TCP. It causes all blocked open(), read(), and write() calls to fail with an error when an ICMP Destination Host (or Network) Unreachable is received. A quick fix is to patch out the entries at inetctlerrmap+8. The right fix is to fix it so only open()'s are nailed. >I also found that while Ultrix systems cause the TCP application >to bomb out when it receives the packet, Suns are not affected. >I guess they have some kind of sanity check for ICMP messages. I suspect SUNs have this or a similar bugfix. So do NeXT's. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Gaijin ja nai. /|\ | |/\| _______ / \ MRC@CAC.Washington.EDU Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.