I figured out the problem. It was VLAN related. I have a phone VLAN (VLAN5) where phones and sipx server are located. In most cases, phones are placed on switch ports that are shared with the data VLAN, which use VLAN tagging to differentiate traffic. My phone profiles are set to tell the device to use VLAN5 for its telephony traffic (by setting the VLAN tag). ANything plugged into the LAN port on the phone is untagged, so it works on the data VLAN. I set the phone to bridge to the LAN port.
I thought I needed to do my initial config of the device while plugged into a switch port that was forced to VLAN5 (untagged), so it would properly get a DHCP address and find the server. So on that untagged port, it woke up, got an IP from the sipx DHCP server, and loaded the profiles. Unfortunately, since the profile was set to expect tagged packets for VLAN 5, the untagged packets from the server were being ignored, so it failed to get a DHCP address after that. Instead, I just plugged the device into a normal switch port (tagged to support either VLAN). It gets a DHCP response from my data subnet's DHCP server the first time. This response includes the TFTP record to point to my sipx server on the other (phone) subnet, so it picks up the profile, switches itself to VLAN5, and things work fine. From then on it stays on VLAN5. This works OK because of 2 details: 1. I added appropriate records to my data net DHCP server on VLAN0 2. I have routing between the data and phone subnet (using extra ports on my PFSense firewall). In my case, I set a switch port to force an untagged VLAN5 for this connection to PFSense, because I did not want that box to have to decode the tagged packets--it was an ALIX box whose LAN adapter does not handle VLANs on-chip). I hope this is helpful for anyone in similar straights... Jeff On Jan 26, 2010, at 6:05 PM, Jeff Gilmore wrote: > I am working with Linksys SPA2102 ATAs (Analog Terminal Adapters) > for my residential sipx rollout, and I am having a problem with > their provisioning. > > I have created the phone profile and generated it. All settings > look as expected in the tftproot dir. When I reset the device and > watch it with wireshark, I can see it request and receive its IP > address, load the spa2102.cfg file via TFTP, > load the spa<MAC_ADDRESS>.cfg file. It seems to complete fine. > > The next thing I see is the device requesting the spa2102.cfg > again, and then it seems to be hosed. I see repeated offers from > the DHCP server for addresses, but the device ignores them. When I > call the voice interface on the ATA and check settings, it > indicates that it has lost its IP address, and that the addressing > mode has become "aasn", or sometimes "alasn", neither of which is a > valid option (it should be static, DHCP. PPPOE, etc.). > > It's as if the parsing of the config fails and crashes the device, > but I can't be sure, as it is difficult to tell exactly what is > going on with these cryptic devices. > > Does anyone have any suggestions? Is there anyone out there using > this device? If so, perhaps you could attach a sample of a working > spa<MAC_ADDRESS>.cfg file that I could alter and put into play as a > test. > > Thanks, > > Jeff > > P.S. I did update the device to the latest firmware, with no > improvement. > > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
