Atcom AT-530 firmware bug

v164 · 06-05-2009, 11:31 PM

I apologise that this is not directly related to VoXaLot.

There seems to be a bug in the firmware for the Atcom AT-530 IP phone. By describing what I've discovered, I hope it might help facilitate a fix and/or workaround.

(This is in addition to the previous problem, described in this earlier post ( http://forum.voxalot.com/voxalot-sup....html#post6823 ), however that problem is less significant)

I'm using the Atcom AT-530 IP phone, running the latest firmware:

Code:

Version: VOIP PHONE V1.6.25.21 Sep 14 2007 17:22:50

The AT-530 is sitting on a public IP address (a static IP). It's set up to use sip.pennytel.com via SIP. The AT-530 has a built-in NAT router, and I use this so that the Internet connection is "shared" with the rest of the computers on my LAN.

The problem is that, around two or three times per day, it becomes impossible for the computers on the LAN to get through to the internet (the AT-530 (or at least, the NAT router part of it)) appears to crash. It's then necessary to re-boot the AT-530 to restore connectivity. It is inconvenient having to constantly reboot the phone.

Even when the AT-530 appears to have "crashed" however, the rest of the phone continues to work normally. VoIP calls can be made and received. The phone's connection to the WAN (internet) continues, but the connection to the LAN is broken.

I even had a situation the other day where, while using the browser whilst talking to someone on the AT-530, the above problem occured, and I had to interrupt the call so I could re-boot the phone.

Initially, I thought that the problem must be a bug in the NAT router code. However, after thorough analysis, I've discovered the NAT router part continues to work, and that the problem can be boiled down to this:

The LAN interface "forgets" it's MAC address.

It stops accepting ethernet frames addressed to it's ethernet address. However, it will continue to accept ethernet frames from the LAN addressed to the broadcast address (ff-ff-ff-ff-ff-ff).

Here's a demonstration of the problem. In this situation, the LAN interface appears to have stopped working. From a computer on the LAN (at 192.168.11.32), I'm going to try to "ping" the AT-530 (at 192.168.11.1).

Pinging the Atcom AT-530 IP Phone LAN interface 00-09-45-53-xx-yy (192.168.11.1) from a Windows PC on the LAN (192.168.11.32).

Code:

C:\WINDOWS\Desktop>arp -a
No ARP Entries Found

This checks the computer's ARP cache. "No ARP Entries Found" means this computer does not currently know the MAC address for any IP addresses on the LAN.

Code:

C:\WINDOWS\Desktop>ping -n 1 192.168.11.1

Pinging 192.168.11.1 with 32 bytes of data:

Request timed out.

Ping statistics for 192.168.11.1:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

There is no response to pinging the AT-530 LAN interface. However, checking the ARP cache again...

Code:

C:\WINDOWS\Desktop>arp -a

Interface: 192.168.11.32 on Interface 0x1000002
  Internet Address      Physical Address      Type
  192.168.11.1          00-09-45-53-xx-yy     dynamic

This shows that the AT-530 did respond to my computer's broadcast query "Who has 192.168.11.1? Tell 192.168.11.32". It responded (correctly) with, "192.168.11.1 is at 00-09-45-53-xx-yy".

My computer then sent the ICMP "ping" packet to 00-09-45-53-xx-yy, however this packet was not accepted by the AT-530. The AT-530 rejected the ethernet frame addressed to it.

However, the AT-530 will accept ethernet frames addressed to the broadcast address, as shown by this next test.

Code:

C:\WINDOWS\Desktop>arp -s 192.168.11.1 ff-ff-ff-ff-ff-ff

C:\WINDOWS\Desktop>arp -a

Interface: 192.168.11.32 on Interface 0x1000002
  Internet Address      Physical Address      Type
  192.168.11.1          ff-ff-ff-ff-ff-ff     static

This manually assigns a "static" mapping. My computer will no longer ask "Who has 192.168.11.1?" but will use the MAC address stipulated by the above command.

With this setting, we once again try to ping the AT-530...

Code:

C:\WINDOWS\Desktop>ping -n 1 192.168.11.1

Pinging 192.168.11.1 with 32 bytes of data:

Reply from 192.168.11.1: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.11.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum =  2ms, Average =  2ms

C:\WINDOWS\Desktop>

The AT-530 accepted the ICMP "ping" packet in this case.

This shows that the AT-530 is accepting the ethernet frames directed at the
broadcast address (ff-ff-ff-ff-ff-ff), but does not accept the ethernet
frames directed at it's own address (00-09-45-53-xx-yy).

Further testing showed that, using the broadcast address (ff-ff-ff-ff-ff-ff), the following IP packets are accepted:
- ICMP
- UDP
- TCP for existing sessions only (so I can't get around this problem by simply using the broadcast MAC address for all packets)

This is a strange bug. Packets going out to the LAN from the AT-530 are completely unhindered, and everything else, including the NAT router software appears to be working fine. Since the WAN interface is unaffected, if I get a report of the AT-530 "crashing" when I'm not at home, I can even log into the WAN interface via the Internet and reboot it by remote control.

The only positive clue I have as to a probably cause, is that, during a four-week period when I disabled SIP registration, this problem never occured. This suggests that the problem is somehow related to the SIP or VoIP part of the AT-530. Further indicating this is that the problem seems to frequently occur after a missed incoming call.

It's been almost a year since I brought this problem to the attention of the manufacturer, however there has been no response.

The AT-530 is a nice phone otherwise, so it would be good if this problem could be fixed. Obviously, I would not be able to recommend this phone to friends and family while this problem persists.

v164 · 08-30-2009, 09:08 AM

Quote:

Originally Posted by v164

There seems to be a bug in the firmware for the Atcom AT-530 IP phone.
...
I'm using the Atcom AT-530 IP phone, running the latest firmware:

Code:

Version: VOIP PHONE V1.6.25.21 Sep 14 2007 17:22:50

Code:

Version: VOIP PHONE V1.7.267.269 Apr 27 2009 14:31:41

However, the problem described in the above post (AT530 "forgets" it's MAC address) is still persisting in the new firmware.

v164 · 06-16-2012, 09:22 AM

An update:

This problem appears to have been almost if not completely solved in this firmware:

Code:

Version: VOIP PHONE V1.7.343.331 Jan 4 2010 10:22:23

However, the problem has re-appeared in the most recent firmware:

Code:

Version: VOIP PHONE V1.7.493.353 Jan 12 2011 10:37:11

06-05-2009, 11:31 PM	#1
v164 Member Join Date: Mar 2006 Posts: 96 Thanks: 8 Thanked 26 Times in 19 Posts	Atcom AT-530 firmware bug I apologise that this is not directly related to VoXaLot. There seems to be a bug in the firmware for the Atcom AT-530 IP phone. By describing what I've discovered, I hope it might help facilitate a fix and/or workaround. (This is in addition to the previous problem, described in this earlier post ( http://forum.voxalot.com/voxalot-sup....html#post6823 ), however that problem is less significant) I'm using the Atcom AT-530 IP phone, running the latest firmware: Code: Version: VOIP PHONE V1.6.25.21 Sep 14 2007 17:22:50 The AT-530 is sitting on a public IP address (a static IP). It's set up to use sip.pennytel.com via SIP. The AT-530 has a built-in NAT router, and I use this so that the Internet connection is "shared" with the rest of the computers on my LAN. The problem is that, around two or three times per day, it becomes impossible for the computers on the LAN to get through to the internet (the AT-530 (or at least, the NAT router part of it)) appears to crash. It's then necessary to re-boot the AT-530 to restore connectivity. It is inconvenient having to constantly reboot the phone. Even when the AT-530 appears to have "crashed" however, the rest of the phone continues to work normally. VoIP calls can be made and received. The phone's connection to the WAN (internet) continues, but the connection to the LAN is broken. I even had a situation the other day where, while using the browser whilst talking to someone on the AT-530, the above problem occured, and I had to interrupt the call so I could re-boot the phone. Initially, I thought that the problem must be a bug in the NAT router code. However, after thorough analysis, I've discovered the NAT router part continues to work, and that the problem can be boiled down to this: The LAN interface "forgets" it's MAC address. It stops accepting ethernet frames addressed to it's ethernet address. However, it will continue to accept ethernet frames from the LAN addressed to the broadcast address (ff-ff-ff-ff-ff-ff). Here's a demonstration of the problem. In this situation, the LAN interface appears to have stopped working. From a computer on the LAN (at 192.168.11.32), I'm going to try to "ping" the AT-530 (at 192.168.11.1). Pinging the Atcom AT-530 IP Phone LAN interface 00-09-45-53-xx-yy (192.168.11.1) from a Windows PC on the LAN (192.168.11.32). Code: C:\WINDOWS\Desktop>arp -a No ARP Entries Found This checks the computer's ARP cache. "No ARP Entries Found" means this computer does not currently know the MAC address for any IP addresses on the LAN. Code: C:\WINDOWS\Desktop>ping -n 1 192.168.11.1 Pinging 192.168.11.1 with 32 bytes of data: Request timed out. Ping statistics for 192.168.11.1: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms There is no response to pinging the AT-530 LAN interface. However, checking the ARP cache again... Code: C:\WINDOWS\Desktop>arp -a Interface: 192.168.11.32 on Interface 0x1000002 Internet Address Physical Address Type 192.168.11.1 00-09-45-53-xx-yy dynamic This shows that the AT-530 did respond to my computer's broadcast query "Who has 192.168.11.1? Tell 192.168.11.32". It responded (correctly) with, "192.168.11.1 is at 00-09-45-53-xx-yy". My computer then sent the ICMP "ping" packet to 00-09-45-53-xx-yy, however this packet was not accepted by the AT-530. The AT-530 rejected the ethernet frame addressed to it. However, the AT-530 will accept ethernet frames addressed to the broadcast address, as shown by this next test. Code: C:\WINDOWS\Desktop>arp -s 192.168.11.1 ff-ff-ff-ff-ff-ff C:\WINDOWS\Desktop>arp -a Interface: 192.168.11.32 on Interface 0x1000002 Internet Address Physical Address Type 192.168.11.1 ff-ff-ff-ff-ff-ff static This manually assigns a "static" mapping. My computer will no longer ask "Who has 192.168.11.1?" but will use the MAC address stipulated by the above command. With this setting, we once again try to ping the AT-530... Code: C:\WINDOWS\Desktop>ping -n 1 192.168.11.1 Pinging 192.168.11.1 with 32 bytes of data: Reply from 192.168.11.1: bytes=32 time=2ms TTL=64 Ping statistics for 192.168.11.1: Packets: Sent = 1, Received = 1, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 2ms, Maximum = 2ms, Average = 2ms C:\WINDOWS\Desktop> The AT-530 accepted the ICMP "ping" packet in this case. This shows that the AT-530 is accepting the ethernet frames directed at the broadcast address (ff-ff-ff-ff-ff-ff), but does not accept the ethernet frames directed at it's own address (00-09-45-53-xx-yy). Further testing showed that, using the broadcast address (ff-ff-ff-ff-ff-ff), the following IP packets are accepted: - ICMP - UDP - TCP for existing sessions only (so I can't get around this problem by simply using the broadcast MAC address for all packets) This is a strange bug. Packets going out to the LAN from the AT-530 are completely unhindered, and everything else, including the NAT router software appears to be working fine. Since the WAN interface is unaffected, if I get a report of the AT-530 "crashing" when I'm not at home, I can even log into the WAN interface via the Internet and reboot it by remote control. The only positive clue I have as to a probably cause, is that, during a four-week period when I disabled SIP registration, this problem never occured. This suggests that the problem is somehow related to the SIP or VoIP part of the AT-530. Further indicating this is that the problem seems to frequently occur after a missed incoming call. It's been almost a year since I brought this problem to the attention of the manufacturer, however there has been no response. The AT-530 is a nice phone otherwise, so it would be good if this problem could be fixed. Obviously, I would not be able to recommend this phone to friends and family while this problem persists.

06-16-2012, 09:22 AM	#3
v164 Member Join Date: Mar 2006 Posts: 96 Thanks: 8 Thanked 26 Times in 19 Posts	An update: This problem appears to have been almost if not completely solved in this firmware: Code: Version: VOIP PHONE V1.7.343.331 Jan 4 2010 10:22:23 However, the problem has re-appeared in the most recent firmware: Code: Version: VOIP PHONE V1.7.493.353 Jan 12 2011 10:37:11

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Hardware]Konfiguracja telefonu TC-300 GSM VoIP	agatus	Polski Support Voxalot	24	04-14-2008 07:20 AM
How to configure my speedtouch 716 WL v5	444719	Voxalot Support	10	08-29-2007 05:12 PM