rick@Seismo.ARPA (04/17/84)
From: Rick Adams <rick@Seismo.ARPA> Here's the situation: C--------D | | A--------B C & D are on the milnet (sharing the same imp). C & B are on an ethernet. A & B are connected with a serial line. A, B & C are on the same Class-B network. D is a vax running 4.2bsd. B & C are vaxes running 4.1C with the networking code of 4.2 (The 4.1C was extremely hacked before we got 4.2, so I "lifted" the 4.2 networking code). A is a 68000 running a System III compatible unix with TCP/IP based loosely on 3Comms UNET. A, C and D can all talk to each other in both directions (C as both a milnet number and the class-B network number). Here's where it starts to get strange. B can talk to A or C with the Class-B number. However, it can NOT talk to D or C as a Milnet number. (Before you say routing, remember A can talk to everyone and everyone can talk to A). The really wierd part is that when B is trying to talk to C or D, the destination machines (C/D) get TCP CHECKSUM ERRORS! The ip packets are ok. Destination Class-B Milnet Source A B C C D A ok ok ok ok ok B ok ok ok NO NO C ok ok ok ok ok D ok ok ok ok ok Any ideas on why I am getting TCP checksum errors in this one case would be greatly appreciated. ---rick
brescia@Bbn-Unix.ARPA (04/17/84)
From: Mike Brescia <brescia@Bbn-Unix.ARPA> Rick, My first reaction is to suspect IP source routing. Are you using SR to get through to nets that are not known to the world? The feature of the TCP checksum that enters in here is that it is invariant as source routing is followed. The TCP pseudoheader used in the checksum has the ultimate destination rather than the first IP destination in it. Mike
ron@Brl-Tgr.ARPA (04/17/84)
From: Ron Natalie <ron@Brl-Tgr.ARPA> All I can suggest is to make sure that you are using the correct address in the TCP pseudo header while computing and checking checksums. -Ron