Today a number of group format errors were reported that have information that I think might be 802.2 or 802.3 frame fields. Here is a capture from a dump screen (name obfuscated to protect confidential infomration):

8(888(888p8888¦ë036040297LAST,FIRST NAME***¦03668C12¦4569811

83¦68¦010207²010207²0126¦2¦1¦04²²C²²02²²²²²²²²P16082301020745698

1183²1¦03²122206²I²I²02²²²033110976²6²²²0²P081338122206123456123

²3²N²4612619400¦01²072806²C²²02²²²²²²²1²P105521071006231623328²²

N²1714916300¦04²122206²I²²02²A²111²²²²²²B*²²N²0111177700²07²0362

8C10²8577¦03²091406²O²²02²A²102²²²²²²B*²²N²4114943000²01²03628C1

0²Z852¦02²072806²C²²02²A²053²²²²²²B*²²N²88TÆÉ888ùe£888E88_+µ@8~8

oy(P7(84!¢8+8î«8FD£OP8Dp¬888888OOO8888OOOOOOOO88888888$888OOO

Opè888ç88OOOOOOOOOOOO+8888888P+888ƒ88+Ç88`Å88h+888é88OOOOOOOO+P8

8OOOO8â¦OOOOO88OO888888OOOOOO8888OOOOOOOOOOOO8888$888éáV8OOOO¦OO

O888888OO¦OOO8888OOOOOOOOOOOO8888$8888â¦OOOOO88OOh88888OOOOOO888

8OOOOOOOO88888888$888OOOOpè888ç88OOOOOOOOOOOO+8888888P+888ƒ88+Ç8

8`Å88h+888é88OOOOOOOO+P88OOOO8â¦OOOOO88OOa88888OOOOOO8888OOOOOOO

OOOOO8888$888éáV8OOOO¦OOO888888OO¦OOO8888OOOOOOOOOOOO8888$8888â¦

OOOOO88OO@88888OOOOOO8888OOOOOOOO888888888TÆÉ888ùe£888E88(=¦@8~8

8\&¦)@8=d88PÆVPS8újcP8c÷+88888888n8¦+v8b/:¦¥ê+dbb]¯/v+|ºí ˜;8

Assuming this comes out, the omegas are FF characters. Does this look like frame data to you? Any words of wisdom to share? If this doesn't come out at all, just forget the post.

I'm tipping a dodgy network card - I once saw AREV key values (@ID) changed by a random BIT owing to a failing card. I guess line interference on a 802.3 network could do that. Packet sniffer dumps are usually way more coherent (get a copy of Traceplus Winsock if you want to see TCP/IP packets in action, for example - they are immaculate in most cases).

Usually buffers are much cleaner than the tail of that group suggests.

I *did* once have problems with Novell buffers being "dirty" when I was writing the Novell routines for AREV many moons ago (1990-95 or thereabouts), but only on *some* versions of the DOS Novell client. As a result I used to zero the buffers in code before use. If I recall, I the AREV RTP57A code doesn't clean its buffers before use, purely as a code effeciency measure. In any case, AREV wouldn't be able to detect the integrity of packets once they had left the client software, including a chunk of group data as you depicted.

I smell a failing network card.

A couple of the groups that had GFEs had "tails" that appeared to be random garbage where we would expect to see nulls. What I previously posted is not random, though. There are strings of FF's. Is it not true that a broadcast packet has all FF's in the destination address field? If so, could knowledge of this help to identify a possible ailing computer by getting the source address from other data in the block? I don't know enough about these protocols to know the answer to this, but I know enough to believe there might be some useful information in these GFEs. If there's a failing card, maybe the data points to it.

Or maybe that's just wishful thinking.

The broadcast address is all FF, but six of them. You do have some instances of FFFFFFFFFFFF in the data, but they are close enough to each other to be not this. In actuality, the data could be anything, and could have nothing to do with your network and all to do with your disk and a scrambled partition or a mangled cache system.

Does the contents of the data mean anything? Are these connected frames? Put all together, does the data mean anything?

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Every frame in the file should look approximately like the first seven lines of the frame I posted. Part way through the 7th line, there are unexpected characters. I assume data got corrupted somewhere along the line. A working theory right now is that there are router problems somewhere. A router was "upgraded" in mid-December, coincidentally when the problem started happening. It was replaced back, yet the problems continue. We have people from Novell, Cisco, and internal network folks running sniffer traces and analyzing packets.

This is a summary I received from one of our network guys:

"I was able to decipher the FS474's this time. I revived my old 486 and now have AREV running in order to look at the actual AREV files being transferred, this was to ensure we weren't seeing any data corruption. There was no data corruption on the 2 traces I've looked at so far. The AREV NLM running on the File Server and the AREV TSR running on the workstation speak to each other with IPX socket-to-socket communications and expect fairly good response times along with an orderly flow of the data. I didn't see any anomalies on the workstation side of the trace, however I did see a problem on the Server side of the trace. All data was being requested record by record from the workstation and acknowledged by the workstation until the problem occurred. The problem I speak of is a duplicate packet being sent to the Server that the workstation has already requested and acknowledged before, this was a duplicate packet, not a retry packet sent from the workstation. This confuses the Server and it responds to it however I did not see the actual data retransmitted, so the workstation goes into retry mode spreading them further and further apart until it reaches it's 50 retries which is the value set on the TSR. In the last trace this in turn caused the FS466 timeout."

I'm not sure this applies generically, because we frequently get FS474s without FS466s and vice versa.

Getting back to the frame, I can picture two scenarios. The first is where the record being saved to the AREV file is corrupted. In this case, the record should be saved normally, encapsulated properly with normal frame overhead. Another scenario is that the frame itself is corrupted. I think that is the situation we have here.

But the file server has mirrored disk drives, and we use the NLM, so how could this happen? It would seem to require corruption occurring somewhere in the pipeline between the NLM and the mirrored disks, right? Or is there any way such corruption could be introduced from a workstation (assuming TSRs properly loaded, REVPARAM files properly set up, etc.)?

My understanding was that communications between workstation and NLM involved record-level I/O, rather than frame level I/O. Am I wrong about this?

You are running ONLY 802.2 and forcing that frame type in all setup, right? If you run 802.3 (for any reason), you'll get frame into written into the files. That has been there as an issue for years (although it's been years since I've seen it, as we always force 802.2 when using IPX).

There are several thousand users on the system, and I'm not involved with that aspect of the setup, but I'll pass along the information. Thanks. By the way, that is why I asked in another thread whether it was possible to determine the frame time from within Arev.

View this thread on the forum...