Virtual Outpost

Software Development and Support for iPhone, iPod Touch, iPad, Macintosh, WordPress, FileMaker

Posts Tagged Network

Mac OS X Server 10.5.8 Problem

Aug 19

Posted by Walt Sellers in Mac OS X Server | No Comments

Here’s an interesting problem.  It makes you kind of wonder how many different things you need to test for when working on software.

Today I got a call about an XServe having problems serving files.  People had been getting errors that said no more connections could be made to the file server.  Well that didn’t make sense.  The server had an unlimited client license.  But a quick check showed that this was the error being received and that 10 clients were currently connected.

Eventually, it occurred to me that 10 clients was the limit for developer or demo licenses (set by the serial number)  so I went to check the number to see if something had gone wrong.  Selecting the server itself in the list on the left, then “Overview” from the toolbar, I see red text that says “Invalid Serial Number“. Selecting the “Settings” icon in the toolbar, then the “General” tab that appears (because I already know where to look for the serial number), I see:  “Invalid Serial Number: duplicate serial number“.

Now my  favorite tool, Google, does well for me now that I know what to ask for. I quickly find this discussion on an Apple forum about this very problem. It reveals that the problem occurs on Mac OS X Servers that have more than one connection to the network on the same subnet, like this one.

Since the double-network setup was to get more network performance for FileMaker and file services, its good to note that the discussion points out Apple articles on suggested methods for combining ethernet ports and link aggregation. I haven’t had time to fully figure out how these suggestions will work with off-the shelf switches, so it looks like I’ll have another entry soon.

So, open suggestion to Apple, Inc:  It would be nice to have a major error like an invalidated serial number presented to the user or admin a bit more prominently.  Perhaps an automatic email about such a change in status, or a notification from the Server Admin application?

Tags: , ,

FileMaker Server Won’t Start

Aug 10

Posted by Walt Sellers in FileMaker | No Comments

Another day, another story.  This time I got a call about a FileMaker Server on a PowerMac G5 that won’t restart after a power failure.

While a lot of thoughts leap to mind about what the problem might be, none of them were behind this.  All the usual stuff of fixing permissions and checking the Console application for messages turned up nothing.  The FileMaker Admin Console let me login, then told me that the server is not available and all I can look at is the overview.  Attempts to start the server in the console failed.  Surprisingly, the attempts just did nothing.  No error message, no change in status, nothing at all happened. Read the rest of this entry »

Tags: , ,

Sleep is Bad for FileMaker Server Connections

Aug 5

Posted by Walt Sellers in FileMaker | No Comments

Lately, a customer of mine has had problems with a single person’s Macintosh in the office being disconnected from FileMaker server several times a day.  It was pretty much looking like this would be one for the books as they had already tried a huge number of things to fix the problem, including:

- different computers at this person’s desk (including the IT guy’s own laptop)
- different IP addresses on the computers
- different ports in the switch
- different ethernet cables
- different power sources for the computers
- different UPS boxes for the different power sources
- deleting FileMaker Pro preference files on the workstation
- changes to the FileMaker Server settings

All of these things failed to stop the worker from being disconnected. Read the rest of this entry »

Tags: , , ,

Don’t Pull Your Hair Out (That’s What You Hire Me For.)

Apr 23

Posted by Walt Sellers in Mac OS X Server | No Comments

Well, a “fun” day with an Apple X-Server that bears repeating (well, writing down). If your server suddenly stops functioning with no real changes worth noting, you know its going to be an interesting day.

I got called in by a friend and fellow consultant. He told me that the X-Serve would be connected to the network for a short while and then stop. He could make it work by disconnecting the ethernet cable and re-connecting it. That made MacOS reset the connection and it would work for a short while.

After looking over endless settings, preference files, notes online, and a call to Apple support, we were left with the conclusion that we should re-install the OS (reluctantly). This is really something we did not want. (And felt that this was like surrendering, but, being the biggest stick we could hit it with, we thought this would fix it.)

WRONG! After re-installing and following all the instructions from documents, setup wizards and Apple’s instructions from the phone call, IT STILL DROPS OFF THE NETWORK.

In a moment of inspiration (desperation), I thought that the problem might be with the router (a current-model Apple Airport Extreme base station) or with some other equipment hooked up to it all. So it was time to start testing the network.

I started up a TCPDump job on the X-Serve to see if it showed something noticeably weird. There was quite a bit, but the only noticeable was the slowdown in packets once it dropped off the network. One thing that was strange; once the X-Serve could no longer load a web page and no desktop could connect to it, I could still successfully PING the X-Serve from my laptop. WHA?!

OK, at some point, I noticed that “arp -a” on the X-Serve would return a strange entry for x.x.x.255. (Something like ff:ff:ff:ff:ff if I recall.) This seemed symptomatic of the problem, but deleting it accomplished nothing. But AHA! the result of arp -a on my laptop showed that the X-Serve’s IP address was associated with an INCORRECT hardware address (M.A.C. address).

SO! There’s ARP poison coming from somewhere. (Or some kind of hiccup in the Airport.) So, in short order, we disconnected EVERY other device in the network except the DSL modem, Airport and X-Serve. But it STILL happens! We even replaced with the Airport with a brand-new spare of the same mode. (Which happened to be there for expansion plans.) It was STILL getting dropped! (Now we know its a good bug-hunt.)

The last bit needed to root it all out; that bad MAC address. It was always off by 1. The X-Serve has two ethernet connectors, and the information utilities show the two MAC addresses. In this case, they ended with :b0 and :b1. However, whenever the X-Serve dropped its connection, the arp entry on the laptop show the number, but ending with :b2. Resetting the X-Serve connection with the ethernet cable unplug/plug trick would immediately cause it to show as :b0 on the laptop until the next drop.

Well, one more quick call to Apple and we find out that the X-Serve has two EXTRA MAC addresses for the Lights-Out Management (LOM) system. And yes, they are :b2 and :b3 for this X-Serve. This was something I hadn’t realized because I hadn’t looked into using LOM before. In fact, when I went through the setup wizard after the re-install, I had specifically opted out of setting this up.

A quick trip to the Server Monitor program gave it all up. We set it to monitor the X-Serve, used the Server menu’s “Configure Local Machine” option to show LOM and yes, LOM ports 1 and 2 had been configured with the SAME IP address as the manual configuration we specified in the wizard.

So, whenever LOM would do something, the ARP table in the Airport (and any other computer listening) would be updated with the wrong MAC address. (Kind of like ARP poison I suppose.)

A quick change to the LOM settings and all was well. A minute or two later, and I had ARP entries for both the MAC addresses with their separate IP addresses. And the X-Serve has been happy ever since.

Its strangely nostalgic. I recall working on the same problem many years ago (circa 1990 when the MacTCP driver for MacOS 6 had a “dynamic addressing” option. It would create an ARP poison situation too. It had been driving my group nuts and when we found the reason we were able to just set manual addresses for all the computers and keep everyone working with no more dropouts.

Now for some rest. :-)

Tags: , ,