4.1 and 46xx v2.8 never gets past Discover x.x.x.x

[Drew2400]

Okay. So I installed 4.1 and the IP sets downloaded the latest firmware v2.8 for 46xx sets. Now it never gets past the
Discover x.x.x.x (x.x.x.x is the ip of the IPO).

It loads the firmware, gets and IP Address, requests 46xxsettings.txt and 46upgrade.scr then stays on Discover.

I tried static and dynamic IP settings. Any ideas?

Drew

 

[kwing112000]

I just used the 2.8 bins on some phones today and they worked great. I had the bins that i downloaded from avaya so i am not running 4.1. I am not using the settings file for anything either. we are doing everything thru DHCP. The only thing i did have to do was rename my files to match the old names. my phones upgraded and came right up

 

[Drew2400]

Yep, both files the .scr and .txt are located in the appropriate folder. You can verify this by watching the TFTP log view windows in Manager.

Okay, so I point the gateway address at the IPO and it seems to work now. However, I can't get out to the internet through the WML page.

Interesting enough, I read that most firewalls (I have a PIX) will not allow traffic back out the same port as it came in on.

 

[kwing112000]

I thought you were using solar winds? I have heard there are issues with manager and TFTP. I use MV_IPTEL from Avaya and it works great. You can do HTTP, HTTPS, TFTP. All you do is put the files you want into the data folder and it will transfer them. I did 2 different sites today with the 2.8 bins and had no issues.

 

[fshaw]

I have had a similar issue with digital phones pulling firmware for 4.0(10) with a 406 V2. According to Tech Support, some Windows XP PCs just won't let you do TFTP with Manager; Nobody is exactly sure why. I loaded Manager on a different pc, redid my TFTP address and everything went fine.

BTW, did you check the settings for Manager to ensure that TFTP is checked on. And have you disabled Windows firewall and all other antivirus programs at the services level to confirm that it is not a firwall issue.

Good luck,
Frank

Frank Robertshaw
The Phone Guy
Nashville, TN

 

[Drew2400]

Yep, TFTP is checked, firewall is off and the Virus scan does only that (no spam, firewall, email).

Also, new problem. I have a friend who also has a 406v2 at the 4.1 level. We are VPN'd together. Because I'm pointing my IP Phone at the IPO as opposed to the actual gateway. I cannot initiate a call from the IPPhone to his switch using the code I created to dial things on his switch (I don't want SCN enabled). So I have *95N with the N being a number on his switch.

From a 5420 I can dial *95*17 and get his voicemail. From the IPPhone I get a CALL REJECTED after dialing *95. Now before the upgrade this was possible without problem. The IPO's default gateway is the PIX and therefore talks to the VPN tunnel no problem. Pointing the IPPhone to the IPO caused the above error.

 

[Drew2400]

Okay, my bad, I had a brain "hiccup" again. I created a shortcode and ARS entry with the same *95. Sorry for that one... It still bothers me that I have to point the phone at the IPO as it's gateway to get it to work.

 

[fshaw]

Does the other system have the same TFTP issue? Have you tried to TFTP bin files from the Manager pc for the other system?

Frank

 

[Drew2400]

As the IPPhone is pointed to the switch as it's default gateway and not the PIX (which is the default gateway). Calls to the other IPO go through. Calls to the other VM does not. The phones really want to use the PIX as their Gateway. Everything worked before 4.1 without change to configuration. There is something in this particular 2.8 IPPhone firmware that does not agree with the environment.

I find it hard to believe that no-one else is having the same problem. It's a standard architectural design with the firewall/router being the gateway of last resort for everything inside. Hmmmm.......

 

[Drew2400]

Okay, so here's the latest. The IPPhone is pointed to the PIX (as it should be). I use a scanner (SolarWinds) which allows me to look at the ARP table in the IPPhone using SNMP. I have ARP entries for everything but the PIX (the default gateway). It says all 0's and 'Invalid'.

There has got to be something in this firmware level or the 46xxsettings.txt file that would be causing a problem. It just stays on Discover x.x.x.x

It does, however, have an ARP entry for the IPO which it's trying to discover in the previous paragraph.

Drew

 

[kwing112000]

I am using the bins and they have worked great at 4 sites. No issues. I am not using the 46xxsettings.txt file for anything. Maybe that is where the issue is. we just use DHCP to hand out the info and every site i have put these on has come right up. I have done most of them remotely. maybe it is worth using the original txt file and static the phones and see if they come up or set up 176 in your DHCP.

 

[tlpeter]

Put down your 46xxsettings.txt file overhere
Maybe you have a entry inthere wich is not correct


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[Drew2400]

kwing:

FYI, I use option 176 which is handed out with by the PIX. Keep in mind, the PIX has this feature as Cisco uses the same technology (SSON 66 or something). I did use the default 46xxsettings.txt and it still doesn't work.

It must have something to do with the implementation of this firmware and it's utilization of ARP and Gateway of last resort. Keep in mind, this worked with the older version of firmware (2.3) flawlessly.

Drew

 

[TheDoz]

Have you tried using a static ip address outside the DHCP range and is your ip route in the ip office pointed to your default gateway?

"The lack of money is the root of all evil

 

[Drew2400]

Yes, I have used a static and pointed to the PIX. The phone will won't get past "Discover x.x.x.x".

I have also used a static and pointed it to the IPO which points to the Default Gateway and the phone gets starts up perfectly with the exception that it can't surf the net (WML) and can't communicate with anything outside of this network.

This leads me to believe that there is a crucial setting on either the pix or the IPO. Now, remember, this worked perfectly in this configuration with the old firmware (2.3).

This has to be something in the implementation of this particular firmware. I also find it hard to believe that I'm the only one with this problem. I'll bet there are quite a few businesses out there with PIX's and their def GW. And, BTW, this is the same problem with 5621, 4620 and 5610. Strange...

 

[TheDoz]

Does your ip route in the ip office look like this?

ip address: 0.0.0.0
ip mask: 0.0.0.0
gateway ip address: 192.168.42.10 (for example)
deastination: LAN1
metric: 0

"The lack of money is the root of all evil

 

[Drew2400]

Sure does. The IPO has SIP & H.323 trunks and works fine.

 

[TheDoz]

Have you tried resetting phones?
1. Press Mute momentarily
2. Dial 25327# (Mute CLEAR#)
3. Clear all values? * = No # = yes
4. Are you sure? * = No # = Yes

Do you have any 5420 or 2420 digital phones that that updated their fireware OK?

Have you tried plugging ip phone directly into the ip office LAN1 port bypassing PIX?

Or maybe try loading old firmware for ip phones to see if they come up.
I would keep trouble shooting until you narrow the problem down to a single source.
Check and double check all settings.

"The lack of money is the root of all evil

 

[Drew2400]

PROBLEM SOLVED!

TheDoz: yes, I tried that. You'll love the solution though. Thanks for the help.

Okay, so, sometimes I'm a little more lucid then others. Does everyone remember I was eluding to ARP and I kept mentioning that the ARP tables looked funny?

Here's the deal, it had absolutely nothing to do with telecommunications, the IPO or the IPPhones. Basic networking was all that it was.

The PIX will PROXY the ARP request for some devices with it's own MAC. My IPO is exposed to the internet to communicate with SIP providers. For those out there with PIX's, the new firmware does not like to be proxied by ANYTHING. It wants the MAC address for the gateway as one, the MAC as the IPO, etc.

Cisco has a command called SYSOPT NOPROXYARP interface (in my case, inside). This tells the PIX to not proxy ARP and allow devices destined for an internal device or gateway to communicate with them directly.

Now tell me I didn't pull that one out...errr... you know.

 

[Bas1234]

Have you checked the switches, if IGMP Snooping (multicast filter) is enabled you can get strange things. I always disable IGMP and spanning tree.

greetzz..Bas

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________

 

[kwing112000]

Drew,
Nice that you got that figured out. I could not figure out why it did not work. I have a bunch of sites running 2.8 and never had any issue at all. thanks for posting the fix as well.