Poly Edge network passthrough failing

[justinmarthaler]

We have deployed Poly Edge e350 phone to our desk and have the network passthrough the phone to the PC.  In the last several months, we have had several calls about people that could not access the network on their computer.  After troubleshooting the problem, we determined the problem was addressed by rebooting the phone.  Once the phone is rebooted, network traffic passes normally.  The phones are currently on firmware version 8.2.3.0870.  Has anyone else experience this issue?  

One idea we've considered for handling this is to proactively reboot the phones during our weekly maintenance window.  Is there a way to perform that action automatically at scale?

[sparrow]

We experienced the same thing about a year and a half ago, but at the time, Poly only had the VVX line of phones and after a weekend firmware upgrade push from Zoom, the data passthrough port stopped working. Debugging the issue, it came down to the phone dropping dot1x authentication on the data connection. We disabled dot1x on those ports temporarily while Zoom worked with Poly to release a fix. If you can? Work with Zoom on gathering debugs from the phone, maybe it's a similar bug.

[wreckITralph]

We're experiencing this as well. This has been an ongoing issue in my company for a few months now. My first step in troubleshooting anything network-related at this point is rebooting the phone. We have the e350, e320 and e220s and are experiencing this on all of them. 

[Eliot]

hi @justinmarthaler 

i do not see anthing in the hp/poly release notes for 8.2.3.

Poly Documentation Library

you might try doing a reset to factory on your hp/poly edge e350 desk phones experiencing the issue.

you could also open support tickets with hp/poly and zoom.

Did my response answer your question? If so, please don't forget to mark the reply as an accepted solution.

thanks,  eliot

[justinmarthaler]

@Eliot - thanks for looking at the documentation library.  We haven't tried a factory reset as the problem doesn't seem to be recurring on the same phones.  We'll start keeping a list of phones that have needed a restart to pass traffic and see if there are any commonalities.  

I opened a ticket with Zoom but there wasn't much value in the response.  Basically, Zoom can't reboot the phones in batch, no one else is reporting this issue, and you should run some network tests and check your internet connectivity.  So that wasn't overly helpful.  And I shudder at the thought of engaging HP support.  My past experience has been abysmal at best.

[sparrow]

You can reboot all phones in your account or by site yourself. Go to phone system management => phones and devices => top right corner select Resync by account/site. You might also have some luck finding a parameter on the Phone Admin Guide to schedule reboots. Zoom unfortunately does not support nor troubleshoot local networks. Your only option would be to work with HP/Poly on debugging the issue. 

[wreckITralph]

I've opened a ticket with HP on this. I'll try to remember to update you if I hear of a resolution.

[mosinjack]

We've encountered a similar issue with the Poly Edge e350 phones, where rebooting resolves the passthrough problem. Rebooting during the weekly maintenance window seems like a good idea. I wonder if there's a way to automate this process across multiple devices, maybe through a script or system integration. Looking forward to hearing if others have found a more permanent solution!

[wreckITralph]

I've got a feature request in with Zoom for some better management tools -- like scheduled reboots of phone devices. Hoping it gets some traction.

[sparrow]

If you have a Zoom account team like a TAM or CSM? I'd start there. You can also pitch that idea as a separate postings in this Zoom Phone community as a feature enhancement request and get others to back you. I'll give you mine. 

[wreckITralph]

We do have a TAM. As soon as I get access to the feature requests section of this thing, I’ll post there. It’s not currently working for me. 

[justinmarthaler]

@mosinjack - in your experience, are the PCs that are not able to connect to the network getting their IP address via DHCP?  Have you been able to check whether the PCs have a normally assigned address, or do they have an IP address starting with 169 which means it didn't acquire a valid IP address from DHCP (at least on Windows).  We had an instance yesterday where we spent a bit more time troubleshooting and found the PC hadn't acquired a DHCP address.  The PC had been unused for a few days so the lease may have expired.  We rebooted the phone to get things working for the individual, but afterward we wondering if a different device with a static IP attached to the phone would have worked.  In other words, is all network traffic failing to pass through or is it just some types of traffic.  With the next person that calls about this issue, we're hoping to test the idea of plugging in a separate device with a static IP address.  I'll report back our findings, but would like to know if anyone else has tried this.

[wreckITralph]

In our case, the PC is showing a 169.x.x.x IP. We initially thought it just wasn’t getting DHCP but my network team says when this happens, they can’t even see the PC on the switch. It’s like the phone’s pass through port completely shuts down. 

[justinmarthaler]

Oh, that's good information.  I'll have our network team take a look at the switches to see if we're experiencing the same behavior.  My guess is that the port is essentially shutting down, but trying to look at it from various angles to better understand it.  By the way, we also opened a ticket with HP, but we don't have a TAM so I'm not optimistic we'll get much traction.

[sparrow]

I recommend you point your phone logs to an external Syslog Server. HP is going to ask you to enable quite a few module log levels and the internal phone buffer is going to be overwritten rather quickly. If you don't have a sys log server? You can always use a desktop syslog application to capture those phone logs. 

[sparrow]

I've not tried this myself, but here are a few parameters that should work. Use a Zoom phone template and sync with a test device before applying to all phones. 

Scheduled Reboot Parameters

Use the following parameters to configure scheduled reboot times for Poly phones.

prov.scheduledReboot.enabled

0 (default)— Disables scheduled reboot.

1—Enables scheduled reboot.

prov.scheduledReboot.periodDays

Specify the time in days between scheduled reboots.

1 day (default)

1–365 days

prov.scheduledReboot.time

Specify a time to reboot the Poly phone. Use the 24 hour time format (hh:mm).

03:00 (default)

prov.scheduledReboot.timeRandomEnd

If this parameter is set to a specific time, the scheduled reboot occurs at a random time between the time set for prov.scheduledReboot.time and prov.scheduledReboot.timeRandomEnd. The time is in 24-hour format.

0–5 hours

hh:mm

[justinmarthaler]

Thank you for finding and posting those settings @sparrow.  We come across those today as well.  We are considering applying those to a test group of devices, but our main concern is the unpredictability of the reboot.  We have a maintenance window on Saturday evenings, but the reboot interval is number of days between scheduled reboots.  If we schedule the first one on Saturday, will it always reboot on Saturday if our interval is 7?  What if the phone reboots for any other reason?  Does the interval start 7 days after that reboot or 7 days after the scheduled reboot?  And if we bring a new phone online, would we only want to do that on Saturdays?

If we do test this out, I'll post back with our findings so others can try this out.