🚀 go-pugleaf

  We have a large network, a small part of which looks like this:

	bootp --- AGS+ --- oavax
		   |
		   |
		 bob-pc

  "bootp" (a unix host set up as a bootp server) is in 132.241.200.0, oavax
is in 132.241.80.0, and bob-pc is in 132.241.16.0.  The router interfaces
for these subnets are 132.241.200.1, 132.241.16.1, and 132.241.80.3.  The
oavax's IP # is 132.241.80.95, and bootp's is 132.241.200.10.  bob-pc is
trying to find his out.  Ethernet interfaces for bootp, oavax and bob-pc
are 1, 0, and 7 respectivly.

  The router has been set up for the following (chopped down for display):

	ip forward-protocol udp
	...
	interface Ethernet 7
	ip address 132.241.16.1 255.255.255.0
	ip address 132.241.64.1 255.255.255.0 secondary
	ip address 132.241.81.1 255.255.255.0 secondary
	ip helper-address 132.241.200.10
	ip helper-address 132.241.80.95
	appletalk cable-range 12083-12083 12083.1
	appletalk zone CHI_Campus
	appletalk zone CHI_Butte
	appletalk send-rtmp
	no appletalk discovery
	novell network 3
	no novell route-cache
	no shutdown

  Now, at one point, a setup like this worked.  At some point, something we
did in our subnetting seems to have upset it.  At least everyone is looking
in my direction.  (:

  When using ip-udp debugging, you can see bob-pc sending bootp packets.  The
router forwards them along to the helpers and you can see the replies coming
back.  On bootp's side of the router, I captured two packets and portions of
those are tacked onto the end of this article.  Everything seems to be
working as far as I can tell, except bob-pc isn't getting them.

  Now, I've traced the packets from bob-pc to .16.1, seen them forwarded to
.200.10 and .80.95, and seen the results going back to .16.1.  I haven't been
able to see them coming back from .16.1, but maybe I'm looking for the wrong
thing.

  The following two packets were spit out by EtherPeek (a macintosh program).
I'm no expert on UDP internals, so bear with me.  The hardware address of
bob-pc is 0207:0108:6be4.  While I don't see that in the header anywhere,
it's clearly in the UDP data area.

  At this point, I'm assuming that the bootp data is making it to the router
and from there it's being sat on somehow.  I'd really like to see the bootp
data coming back out of .16.1 and capture it to my satisfaction.  I can
capture based on IP, name and hardware addresses so this shouldn't be a
problem.  Suggestions?

  We're running 9.1(1.5) ROMs in the router.


  ***  Nasty details follow  ***  (:{

  The packet going from the router to bootp has this for a header:

!	  Flags:        0x00
!	  Status:       0x00
!	  Packet Length:346
!	  Timestamp:    13:35:44.365
!	Ethernet Header
!	  Destination:  08:00:09:03:d8:70
!	  Source:       00:00:0c:00:ce:c7
!	  Protocol Type:0x0800  DoD IP
!	IP Header - Internet Protocol Datagram
!	  Version:              4
!	  Header Length:        5
!	  Precedence:           0
!	  Type of Service:      %000
!	  Unused:               %00
!	  Total Length:         328
!	  Identifier:           1
!	  Fragmentation Flags:  %000
!	  Fragment Offset:      0
!	  Time To Live:         99
!	  IP Type:              0x11  UDP
!	  Header Checksum:      0x74b6
!	  Source IP Address:    132.241.16.1
!	  Dest. IP Address:     132.241.200.10
!	  No Internet Datagram Options
!	UDP - User Datagram Protocol
!	  Source Port:          68  Bootstrap Protocol Client
!	  Destination Port:     67  Bootstrap Protocol Server
!	  Length:               308
!	  Checksum:             0xc6e1
!	  UDP Data Area:
!	  PPPPPPI@PPPPPPPP   01 01 06 00 00 00 49 40 00 08 00 00 00 00 00 00
!	  PPPPPPPP^DPPPPPPP   00 00 00 00 00 00 00 00 84 f1 10 01 02 07 01 08
!	  kPPPPPPPPPPPPPPP   6b e4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
!	  PPPPPPPPPPPPPPPP   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
!	  ...
!	Frame Check Sequence:  0x1b62fca9


  The packet going from bootp to the router has this for a header:

!	  Flags:        0x00
!	  Status:       0x00
!	  Packet Length:346
!	  Timestamp:    13:35:44.379
!	Ethernet Header
!	  Destination:  00:00:0c:00:ce:c7
!	  Source:       08:00:09:03:d8:70
!	  Protocol Type:0x0800  DoD IP
!	IP Header - Internet Protocol Datagram
!	  Version:              4
!	  Header Length:        5
!	  Precedence:           0
!	  Type of Service:      %000
!	  Unused:               %00
!	  Total Length:         328
!	  Identifier:           55513
!	  Fragmentation Flags:  %000
!	  Fragment Offset:      0
!	  Time To Live:         30
!	  IP Type:              0x11  UDP
!	  Header Checksum:      0xe0dd
!	  Source IP Address:    132.241.200.10
!	  Dest. IP Address:     132.241.16.1
!	  No Internet Datagram Options
!	UDP - User Datagram Protocol
!	  Source Port:          67  Bootstrap Protocol Server
!	  Destination Port:     67  Bootstrap Protocol Server
!	  Length:               308
!	  Checksum:             0xc524
!	  UDP Data Area:
!	  PPPPPPI@PPPPPPPP   02 01 06 00 00 00 49 40 00 08 00 00 00 00 00 00
!	  ^DPPP^DPHP^DPPPPPPP   84 f1 50 0b 84 f1 c8 0a 84 f1 10 01 02 07 01 08
!	  kPPPPPPPPPPPPPPP   6b e4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
!	  PPPPPPPPPPPPPPPP   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
!	  ...
!	  PPPPPPPPPPPPc^BSc   00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63
!	  PPPPbpPPPPPPPP^DP   02 04 00 00 62 70 01 04 ff ff 00 00 03 04 84 f1
!	  PPPP^DPPP^DPP<PP^DP   50 50 06 08 84 f1 50 01 84 f1 01 3c 04 04 84 f1
!	  PPPPPPPPPPPPPPPP   01 02 ff 00 00 00 00 00 00 00 00 00 00 00 00 00
!	  PPPPPPPPPPPP       00 00 00 00 00 00 00 00 00 00 00 00
!	Frame Check Sequence:  0x6d62f97c
-- 
p'ch'zarni'chiwkov:  the nasty little sound of a sword being unsheathed right
behind one at just the point when one thought one had disposed of one's enemies.