1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. If you had a PIAF Forum account in the vBulletin days, log in with your old credentials. Otherwise, sign up again and we'll get you back in business as soon as we can.
  3. A serious FreePBX vulnerability has been reported. Update your Framework Module immediately. Click here for details.
  4. Critical FreePBX vulnerability! Update your server immediately. Details here.

Aastra 57i and DHCP

Discussion in 'Endpoints' started by swimboy, Oct 7, 2010.

  1. swimboy Member

    I just set up a test environment to try out the Aastra 2.3.0 scripts (I'm currently using the 2.2.0 scripts on my production phone system).

    I put one of my 57i phones on a separate physical network with the test server, deleted the local settings and reset to factory defaults, and let it load up the new firmware and the new scripts.

    Everything seemed to work just fine, but when I put the phone back on my production network, it wouldn't get an address from the DHCP server. It appears to only look for the DHCP server it communicated with previously on the test network. After timing out in 15-20 minutes, it proceeds to boot, using the IP address it had on the test network. I've verified that the DHCP server on the production network is functioning normally.

    Even after erasing the local config and reverting to factory defaults, this behavior persists. (And yes, I double-checked that I plugged into the WAN port and not the PC port).

    The DHCP lease is for 24 hours, and I don't know if it will behave after the lease expires; but it seems to me that if the DHCP server isn't accessible at boot time, it should search out another DHCP server, and certainly not wait 20 minutes before timing out looking for the original server.
  2. kmcdaniel Guru

    I'm not sure about the 2.2.0 scripts as I am using 2.3.0 and not sure how similar the two are:

    Whenever I have a problem with a 57i registering and pulling DHCP, I delete a few files on the server and reboot the phone. In my example lets say the phone originally had extension 400.

    go into /var/cache/aastra - delete "400.context" &
    edit /var/cache/aastra/startup_asterisk.cfg - delete all lines under the extenstion number, i.e. everything under [400].
    go into /tftpboot - delete "macaddress.cfg" for the phone that had extension 400.

    not sure if it will work with 2.2.0 scripts.
  3. bjeung Member

    Any chance the DHCP server on the production network is out of leases?

    Change network cable?
  4. swimboy Member

    I'm definitely not running out of leases. It appears to be something related to the VLANs on my network. I use port-based VLANs for most endpoints on my network: the switch adds vlan tags to packets entering the switch according to the port, and strips the tags as they exit. This is working for all my Aastra phones except for the one I used in the test environment. Now, that one either doesn't receive or ignores the reply from the DHCP server (I've confirmed that the DHCP server sees the request and replies to it).

    If I configure the phone for VLAN tagging, and disable the adding and stripping of VLAN tags on the switch port, it processes the DHCP reply correctly.
  5. Linetux Guru

    You have to be careful with VLAN tags and Aastra phones (unsure of others). They can do some 'funny' things with tags, wherein they may show up on the wrong network if you're not careful about how you provision the port. I think you've sniffed out the source of the problem - but having tagged & untagged ports on a switch is never a good idea unless that's what you really intend to do. The Aastra's also don't play nice with some cheaper switches (Linksys in particular) when it comes to tagged/untagged ports. I've never had any unexpected results when using higher-class switches (HP/Cisco)... I suspect it has something to do with RFC 'fudging', but I've never bothered to take the time to dig into it.
  6. swimboy Member

    OK, I think that's pretty much explained the issue. It's a NetGear switch, which has always worked just fine in the past with some pretty complex VLAN configurations, but it wouldn't surprise me to learn that it doesn't follow all of the RFCs to the letter.

    The problem occurred when I put the single phone on the test server, which led me to believe that it was the firmware upgrade, but evidently it was due to the change in VLAN configuration on the switch port moving it to the test environment.

    Returning the VLAN configuration back to how it was before I started has caused the problem to go away.
  7. thx2000 Member

    This post ultimately led me down the right path to solve a strange problem I had with some Aastra 6731i's and a Netgear smart switch. However I'm still confused on how VLAN tagging/untagging should be configured in this instance.

    I had set up VLAN 10 for data and VLAN 20 for voice. PVID on each port was set to VLAN 10. Each port was configured for untagged traffic to VLAN 10 and tagged traffic to VLAN 20.

    In aastra.cfg I added the following code so the phones would boot up access the PBX's tftpboot server on the data VLAN grab this config, reboot and connect to the voice VLAN.

    Code:
    tagging enabled: 1
     VLAN id: 20
     VLAN id port 1: 10
    
    All of the above worked great for the 6755i's on the network, but the 6731i's were rejecting my dhcp offers. I could see the DHCP broadcast on the correct VLAN, but only the 6731i's would reject my offer.

    After spending hours playing around with my dhcpd.conf configuration I stumbled on this post and decided to change each port's configuration to tagged for both VLAN 10 and 20. Initially I thought that this configuration wouldn't allow any untagged devices to access VLAN 10, but to my surprise everything worked perfectly and the 6731i's started accepting my DHCP offers.

    So, is this just a strange caveat of the Netgear switches or the Aastra phones, or if a port is going to be designated to send/receive tagged traffic should it not be an untagged member of any other VLAN?

Share This Page