Day 306, Server fail, dive dive dive

Schnell!  Schnell!  Kartoffelkopf.

Here we have a server that decided to give up the ghost, almost certainly issuing itself the German command above.

Quickly!  Quickly!  Potatohead.

If you are of an analytical bent, or have some curiosity aligned with the right bits of knowledge, then you might have spotted something.

In this instance the server has given up the ghost due to a problem encountered in AFPTCP.NLM.

What's that all about then?

Ok, let's dispense with the suffix NLM first.  That stands for Netware Loadable Module, these are effectively executable files in the Netware operating system.

The server Operating System here is Netware 6.5 SP8, the last in the long line of versions of Novell Netware.  Netware was once the top of the tree of network operating systems used for file sharing, printing, and other things that we don't need to mention.

This OS goes end of life on December 31 2015, unless it gets yet another stay of execution.  The replacement for it now runs a version of the Netware kernel under Suse Linux Enterprise Server.

However, that's not the point, what about the rest of this AFPTCP bit then?

The AFPTCP part stands for Apple File Protocol Transmission Control Protocol.  The module runs on the Netware server to provide connectivity for Apple Macs running Apple File Protocol.

The problem highlighted in the screen shown is that the server side can't deal very well with unexpected results received in a packet sent by AFP from a Mac.  It also suggests that something has been sent by the Mac that was not clearly defined in the AFP specification and the implementation has not remained consistent between Mac updates.

It would be preferable if the server was robust enough to deal with this and just discard the packet, but no, it tries to deal with it and gets itself in a tangle, for shame.  It would also be preferable if the company designing the protocol implemented it consistently, but, they are in charge of the specification...

Anyway, Apple are deprecating AFP and will be standardising on the Windows file sharing protocol, CIFS/SMB.

This server side problem was not only caused by AFP.  As the server in this case was also running CIFS there would be times when a poor implementation of that protocol on a non-Windows device or gadget could trigger a similar server response.

So in each case the poor implementation of a protocol on a device interacts with the poor implementation on the server, and so unpleasantness ensues.  However in both cases the server should really have handled it in a much better manner.

None of these problems arose when using the native protocol of the server operating system to connect, Netware Core Protocol.  But people often object to installing a piece of software or 'client' on their desktop to add this functionality - an in built 'client' such as AFP or SMB/CIFS is never really recognised as being such as it is there natively, and indeed that is much less invasive from the point of view of you the human.

As we move away from delivering file services via this method, and to a more seamless, robust, and native SMB/CIFS on the server side too, then these type of problems really should be ancient history.  Just as 12:30:48 am BST on 4 October 2012 now seems like ancient history to me.

Of course, in the world of systems stability, your mileage may vary...

For official/internal use only:
7575

0-9