home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.misc:4153 comp.protocols.tcp-ip:5155 comp.lang.postscript:5509
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!haven.umd.edu!darwin.sura.net!wupost!uwm.edu!ogicse!news.tek.com!shaman!frip!andrew
- From: andrew@frip.WV.TEK.COM (Andrew Klossner)
- Newsgroups: comp.unix.misc,comp.protocols.tcp-ip,comp.lang.postscript
- Subject: Re: problems tfping to a rip
- Message-ID: <2156@shaman.wv.tek.com>
- Date: 14 Nov 92 01:22:42 GMT
- Article-I.D.: shaman.2156
- References: <2893@media03.UUCP>
- Sender: news@shaman.wv.tek.com
- Reply-To: andrew@frip.wv.tek.com
- Followup-To: comp.unix.misc
- Organization: Tektronix Color Printers, Wilsonville, Oregon
- Lines: 31
-
- []
-
- "The reason seems to be that the UDP checksum is wrong.
- normally this checksum is correct, but the troublesome packets
- always have 0xFFFF for checksum. if my calculations are correct
- it should be 0x0 instead."
-
- No, a UDP checksum is never 0. If the calculation yields 0, then
- 0xFFFF is stored instead. Perhaps the code in the RIP is flawed and
- does not include this provision. A 0 in the UDP checksum field means
- "no checksum was computed."
-
- From RFC768, the defining document for UDP:
-
- > If the computed checksum is zero, it is transmitted as all ones (the
- > equivalent in one's complement arithmetic). An all zero transmitted
- > checksum value means that the transmitter generated no checksum (for
- > debugging or for higher level protocols that don't care).
-
- "What is your solution"
-
- Convince the Intel machine not to generate UDP checksums. On the Suns,
- whether or not to UDP checksum is controlled by a variable in the
- kernel; you use adb or equivalent to patch it. Check with your Intel
- rep to see if they have something equivalent.
-
- In the long term, you should ask Linotype to fix their broken UDP
- implementation.
-
- -=- Andrew Klossner (andrew@frip.wv.tek.com)
- (uunet!tektronix!frip.WV.TEK!andrew)
-