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.