| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
Crossposted in hub_mngmt and fddi.
After installing the Hubwatch software I'm not able to ping the hub. It
appears the ARP fails. The hubs IP addr is 128.116.2.100 the XL590's is
128.116.2.99, mask 255.255.0.0. I have Iris traces included of a
failed ARP and a Good ARP done by connecting the XL590 through a
Ethernet card to a tx port.
The bad ARP packet appears correct except it is padded with garbage in order
to acheive the required 60 byte min ethernet packet size. I can't tell
whether the packet had the garbage on the FDDI or not. I would assume
not since the packet size on the FDDI side has no minimum size.
Could these extra bytes not being zeroed cause ARP not to respond from the HUB.
Config:
----------
The customer has a XLServer 590 with a DEFPA FDDIUTP card he wants to
use for his Hubwatch station. The XL590 is connected to a 900MX
concentrator in a DECHUB 900. The 900 config looks like this.
Slot Module
1 empty
2 DECBridge90
3 empty
4 empty
5 empty
6 900TX
7 900TX
8 900MX
The hub has two lans the thinwire and one FDDI whitch the 2 900tx's and
the 900mx connect to. port 3 of the slot 6 900TX is connected to the
thinwire lan, all other ports are directed out the front.
Bad Trace
--------------
IRIS capture data
Page 1
Bad ARP 07/24/95 10:30:05
** Summary for frame 1 **
1 +25s Broadcast<- 4.100 ARP Request Target=128.116.2.100
** Detail for frame 1 **
ARP:
ARP: - - - - - Address Resolution Protocol - - - - -
ARP:
ARP: Hardware Address Space = 1
ARP: Protocol Address Space = 08-00
ARP: Length of hardware address = 6
ARP: Length of protocol address = 4
ARP: Opcode = 1 (Request)
ARP: Sender's Hardware Addr = AA-00-04-00-64-10
ARP: Sender's Protocol Addr = 128.116.2.99
ARP: Target Hardware Addr = 00-00-00-00-00-00
ARP: Target Protocol Addr = 128.116.2.100
** Hex for frame 1 **
0000: FF FF FF FF FF FF AA 00 04 00 64 10 08 06 00 01 ..........d.....
0010: 08 00 06 04 00 01 AA 00 04 00 64 10 80 74 02 63 ..........d..t.c
0020: 00 00 00 00 00 00 80 74 02 64 CA 68 19 ED 43 56 .......t.d.h..CV
0030: A0 00 31 31 31 31 30 30 30 30 2F 2F ..11110000//
IRIS capture data
Page 2
Bad ARP 07/24/95 10:30:05
** Summary for frame 2 **
2 +2s Broadcast<- 4.100 ARP Request Target=128.116.2.100
** Detail for frame 2 **
ARP:
ARP: - - - - - Address Resolution Protocol - - - - -
ARP:
ARP: Hardware Address Space = 1
ARP: Protocol Address Space = 08-00
ARP: Length of hardware address = 6
ARP: Length of protocol address = 4
ARP: Opcode = 1 (Request)
ARP: Sender's Hardware Addr = AA-00-04-00-64-10
ARP: Sender's Protocol Addr = 128.116.2.99
ARP: Target Hardware Addr = 00-00-00-00-00-00
ARP: Target Protocol Addr = 128.116.2.100
** Hex for frame 2 **
0000: FF FF FF FF FF FF AA 00 04 00 64 10 08 06 00 01 ..........d.....
0010: 08 00 06 04 00 01 AA 00 04 00 64 10 80 74 02 63 ..........d..t.c
0020: 00 00 00 00 00 00 80 74 02 64 CA 68 19 ED 50 10 .......t.d.h..P.
0030: 24 E6 5A 50 00 00 00 08 02 33 00 26 $.ZP.....3.&
GOOD ARP
-------------
IRIS capture data
Page 1
Good ARP 07/24/95 10:30:47
** Summary for frame 0 **
0 Broadcast<-00C095EC2DC7 ARP Request Target=128.116.2.100
** Detail for frame 0 **
ARP:
ARP: - - - - - Address Resolution Protocol - - - - -
ARP:
ARP: Hardware Address Space = 1
ARP: Protocol Address Space = 08-00
ARP: Length of hardware address = 6
ARP: Length of protocol address = 4
ARP: Opcode = 1 (Request)
ARP: Sender's Hardware Addr = 00-C0-95-EC-2D-C7
ARP: Sender's Protocol Addr = 128.116.2.99
ARP: Target Hardware Addr = 00-00-00-00-00-00
ARP: Target Protocol Addr = 128.116.2.100
** Hex for frame 0 **
0000: FF FF FF FF FF FF 00 C0 95 EC 2D C7 08 06 00 01 ..........-.....
0010: 08 00 06 04 00 01 00 C0 95 EC 2D C7 80 74 02 63 ..........-..t.c
0020: 00 00 00 00 00 00 80 74 02 64 00 00 00 00 00 00 .......t.d......
0030: 00 00 00 00 00 00 00 00 00 00 00 00 ............
--------------------------------------------------------------------------------
IRIS capture data
Page 2
Good ARP 07/24/95 10:30:47
** Summary for frame 1 **
1 +.8m 00C095EC2DC7<-08002BB2CCE0 ARP Response
Target=128.116.2.100 Addr=128.116.2.99
** Detail for frame 1 **
ARP:
ARP: - - - - - Address Resolution Protocol - - - - -
ARP:
ARP: Hardware Address Space = 1
ARP: Protocol Address Space = 08-00
ARP: Length of hardware address = 6
ARP: Length of protocol address = 4
ARP: Opcode = 2 (Reply)
ARP: Sender's Hardware Addr = 08-00-2B-B2-CC-E0
ARP: Sender's Protocol Addr = 128.116.2.100
ARP: Target Hardware Addr = 00-C0-95-EC-2D-C7
ARP: Target Protocol Addr = 128.116.2.99
** Hex for frame 1 **
0000: 00 C0 95 EC 2D C7 08 00 2B B2 CC E0 08 06 00 01 ....-...+.......
0010: 08 00 06 04 00 02 08 00 2B B2 CC E0 80 74 02 64 ........+....t.d
0020: 00 C0 95 EC 2D C7 80 74 02 63 00 00 00 00 00 00 ....-..t.c......
0030: 00 00 00 00 00 00 00 00 00 00 00 00 ............
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1759.1 | NETCAD::STEFANI | Machines to humanize | Tue Jul 25 1995 07:18 | 26 | |
>>The bad ARP packet appears correct except it is padded with garbage in order
>>to acheive the required 60 byte min ethernet packet size. I can't tell
>>whether the packet had the garbage on the FDDI or not. I would assume
>>not since the packet size on the FDDI side has no minimum size.
This padding does not occur on the FDDI side. If you used an FDDI
LAN analyzer you would see the unpadded packet.
>>The customer has a XLServer 590 with a DEFPA FDDIUTP card he wants to
>>use for his Hubwatch station. The XL590 is connected to a 900MX
>>concentrator in a DECHUB 900. The 900 config looks like this.
Can you provide more info on what the end node setup is with the DEFPA?
What operating system/network operating system is being used? Which
DEFPA driver? There have been driver updates since the initial DEFPA
release (latest kit on KALI::PCDRIVERS:[DEFPA.INTERIM]FPKIT242.ZIP) so
the customer should make sure they're up to date.
Also, if the customer is running PATHWORKS for Windows NT 3.5 over DEFPA
and is using both DECnet and TCP/IP, they *MUST* install a newer
TCPIP.SYS protocol stack from Microsoft. The stack is included with
PATHWORKS. The original stack (even the one from Service Pack 2) has a
bug in checking for the multicast address bit on source addresses of
incoming packets.
- Larry
| |||||
| 1759.2 | 31224::LEE_CA | Tue Jul 25 1995 12:36 | 17 | ||
The Customer is running the latest driver 242 from KALI::. We are
running dos 6.22 windows 3.1. I have tried the Pathworks v5.0 IP stack
that comes with Hubwatch and the PW 5.1 stack that I installed as a
test. The 5.1 stack is the one in use for these traces that why the MAC
addr for the DEFPA is aa-00-...
If the packet is unpadded on the FDDI side as I suspected also the next
real question for me is where whithin the hub900 am I really trying to
talk to. To rephrase that is the hub seeing the padded packet or the
unpadded packet.
Also worth noting is that the 900MX is the designated management slot
for the hub. I'll ask these question in HUBMNGT as well.
Thanks,
Carey
| |||||
| 1759.3 | 31224::LEE_CA | Fri Jul 28 1995 20:29 | 14 | ||
After further testing it appears that the problem is with the DEFPA. I
installed a DECRepeater900 and made it the management slot so I could
see the ARP incoming and response.
The trace showed the ARP request then reply then another ARP
request then reply. Convencing me the xl590 with the DEFPA is not
listening to the reply.
If any DEFPA driver developers are out there I'd like to hear your
comments.
Carey Lee
| |||||
| 1759.4 | NETCAD::STEFANI | Machines to humanize | Fri Jul 28 1995 22:07 | 6 | |
Can you post your CONFIG.SYS and AUTOEXEC.BAT files as well as your
PATHWORKS STARTNET.BAT file? Also, please include the file date and
timestamp for the DEFPA.DOS driver (which I'm assuming you're using).
Thanks,
Larry
| |||||
| 1759.5 | NPSS::LIZOTTE | Network Product Support | Tue Aug 01 1995 13:42 | 3 | |
This issue is being worked as an IPMT CFS.30567.
| |||||
| 1759.6 | DEFPA driver V1.14 fixes it | NPSS::LIZOTTE | Network Product Support | Tue Aug 08 1995 09:35 | 5 |
This issue was resolved by using the latest DEFPA driver V1.14
dated 7/17/95. Previous versions had a problem with IRQs set
below 10.
| |||||