AP9630 issue with FW6.0.6, reboot loop with TCP/IP stack failure?

[Anonymous user]

I have a Smart-UPS 1500 LCD with an AP9630 fitted, spotting that FW6.0.6 was available for the management I downloaded and installed it.  The install completed fine according to the software.

However, now the card is in a reboot loop, it either comes back and says there is an application error, or following a cold boot it lets me in but reboots showing the following in the event log...

TCP/IP stack failure. Module: tfDnsGetMailHost-assertion error line 1266, file(.\treck\source\trresolv.c)

I've tried another upgrade through the software and manually via FTP, cold booting the UPS and AP9630, it seems to work briefly then get into this loop.  I've reset everything to default via the software and button in the back of the card, all to no avail. 

I have put the card back onto 5.1.7 and things are back to normal, bar putting all the configs back in and re-attaching the Macs via PCNS.

Anyone seen this before?

HW Details

Model:  Smart-UPS 1500

Serial Number:  AS1031120***

Firmware Revision:  UPS 07.1 / MCU 05.0 / UBL 7.20 / MBL 05.0 (ID17)

Manufacture Date: 07/27/2010

Model Number: AP9630

Serial Number: ZA1033040***

Hardware Revision: 05

Manufacture Date: 08/14/2010

[BillP]

Next week barring no problems. I will provide a copy here as soon as I get it.

Can I ask - the people that have these issues and cannot use any of the workarounds, what is the barrier to having the MX record cached on the DNS server? Or just an issue with remote/recipient's mail servers? Nobody has ever really let me know why that cannot be done or is it a limitation on access to the DNS server?

[Anonymous user]

Honestly, I don't even know what APC means by caching the MX record in my DNS server and I asked two other email admins as well. We have Windows servers acting as internal DNS and then OpenDNS as our outside source.

So between not knowing what I even need to do, and not feeling that it should be necessary to make any change when everything else in our environment works, I'm just anxious to get it fixed correctly rather than patch it up.

[BillP · Accepted solution]

We're using the ISP's DNS servers and sometimes Google DNS (8.8.8.8, 8.8.4.4) and don't have control over either of them.

Setting up a our own caching DNS just for the purpose of working around a firmware bug is too much hassle.