I’m sure by now no one is surprised to see this post and issue. Its been an issue in the PtP TDD force 300 links for a long time now. However I just wanted to reach out to the group and see if anyone has come up with a solution.
We have had three links that all experienced the same issue where the SM side of the PtP link stops passing traffic on its lan port. A reboot of the unit restores connectivity. Sometime it lasts for a few hours sometimes for a week or more. One of these links we fixed by replacing the SM side hardware. The other link we replaced with force 200 units ( not ideal but works for now). The final link is still in use and as of a few hours ago just needed another reboot.
our most recent tries to stabilize this link has been to upgrade to firmware 3.5.5 and also 3.5 ( currently on 3.5) . we have also set the Ethernet on both ends to 100mbps instead of gb.
At this point I am about our of idea’s its frustrating when some links are rock solid and then others just go flaky like this.
Any feedback is appreciated.
Thanks I had not seen that in the newest Beta. I will give ePTP a try and see if it is stable and the link stays up. Ill report back to the post with anything we learn.
Brandon,
Please submit a support ticket on this sooner. I don’t want you to spend so much time and get frustrated. If our support gets a shot at the issue they can at least guide in some shape or form. They can take a look at the tech support dump and at least conclude if something is happening in software or if there is some type of an unique hardware issue. Please copy and paste my response in your ticket. Sakid
We’ve just tried 4.6 RC35 on a F300 TDD BH and have not seen any improvement in the LAN port deadlock issue, and in fact it actually seems worse. We’ve had 3 watchdog restarts due to the LAN port not passing traffic issue in the 36 hours its been running. The BH is in fairly heavy use so we will be changing back to 3.5.6 in the wee hours and going to ePTP. The F300 BH seem fairly stable with that combination.
When we tried 16.2 RC35 this morning on another F300 BH that was using ePTP, the link became basically unusable and had to roll back. I had to drive to the tower to revert the upgrade as the throughput was so dismal it would not maintain a stable connection in ePTP mode. Everything in the F300 at the tower said it should have connected fine, but a link test during one of the brief periods of connectivity gave a total throughput of point 9 down and point 15 up. It wouldn’t stay registered with the master for more than a couple of minutes tops. A hard reboot had no effect. Once I rolled the slave back to 3.5.6 it popped right up with the master that was still on 4.6 RC 35. I of course reverted the master once I got back to the office. It has been stable since.
I would be interested in hearing what you encounter.
On the plus side, the ePMP 3000 AP running 6.4 RC35 has had no issues during the same time period, but is not under any real load at the moment.
We have addressed the issue with packet loss and low throughput in ePTP mode on AC radios in 4.6-RC35.
If you are experiencing the issue with the lan traffic on Ethernet port, please open a ticket with Cambium Support. If you can send Tech Support Files from AP and SM to me we would be able to come up with the conclusion too.
fedor.trutsko(at)cambiumnetworks(dot)com
We still have a ticket open (I think). I’ll check on Monday. It appears we only see the LAN issue when in TDD mode on 4.5.6 or RC35. On 4.5.6 ePTP appears stable but throughput is lower than expected.
So other than transferring our ticket from one person to another we have not heard anything back at this point on it.
Since it was opened up 7 days ago we have had the link stop passing traffic two more times. Its a heavily used connection and customers are getting understandably frustrated. We had left the configuration alone since opening the ticket so it was still TDD, 40mhz channel, 100mbps Ethernet connections on 3.5.
Last night we upgraded to 4.6.0RC35 and did the same as Riverrat changing over to ePTP mode. We had very similar results. The link would not stay connected for more then a minute or two. Often not at all. We have secondary backhauls in place we I could reboot both sides but it would not stabilize. During one of the longer connections I was able to run a linktest. It was less then 10mbps download and a few mbps on the upload. Eventually I had to bail on the ePMP and go back to TDD. Link came right back up and started passing traffic correctly.
The link is now back on TDD, 40mhz channel, 4.6.0RC35 firmware now 100mbps Ethernet on both ends.
stable for the last 12 hours but that doesn’t really mean anything at this point.
Ill update my ticket with this info but if anyone at cambium reading this wants to reach out I would really appreciate the help.
We’ve had 4 more drops on 4.5.6 in ePTP mode in the last 24 hours. I captured the engineering data and sent it in and changed to TDD which has it stable, or at least as stable as it gets. We had another BH link running the same software on ePTP and it began dropping the session on and of for 45 minutes and had to change it to TDD as well. Captured the engineering data on it while the event was occurring so maybe that will help.
As noted, customers are starting to get angry as both BH dropped during peak usage periods, though there appears to be no rhyme or reason when they will do it. I’ve had then go 3 to 4 days solid and then have it occur 3 times in the same day at apparently random times and loads.
Our ePMP3000 has been solid under RC35 for several days so that is good, but the F300 PTP modes definitely need some attention.
Riverrat,
Have you see issues with the ethernet port not passing traffic in TDD on lighter used links? We have a couple 20mhz channel links that don’t have to much of a load on them and they are completely stable. I am just wondering if its a heavy use / 40mhz issue.
I agree. Seeing about the same “regularity” of the issue on 4.4.3 and 4.5.6. The RC betas are actually worse. We had another incident this evening, of course, right in prime time.
We replaced the SM side radio yesterday that Fedor confirmed was a hardware issue. We downgraded the link to 4.4.3 since that had been stable in the past for us. We are running TDD still on a 40mhz channel.
The link kept dropping / re-registering. I upgraded last night to 4.5.6 . TDD. 40mhz channel and its been stable for 12 hours. I’ll report back in a few days.
We are running one F300-25 link on 3.5.6 that has been stable for 3+ days. The other link was still dropping out 2 to 3 times per day. Downgrading to 4.4.3 decreased that to once every 1 to 2 days. Cambium flagged the slave F300 for RMA. We have a new one in the box but we’re waiting for the weather to clear for the climb. Snow and ice for the next few days.
We finally had some decentish weather and made the climb for the slave replacement. Running almost 60 hours now with no issues, which is close to a record for this link since it started having issues. We are also running 4.4.3 in a 40 Mhz channel in TDD. As unlikely as it would seem, it appears we had faulty F300’s on both end of the link. The master eventually made it easy by just dying. Our other F300 backhaul has been running well in the same configuration. We want to go to ePTP once the confidence is there that it is stable.
Everything has been solid since the hardware replacement. Upgraded back to 4.5.6 and have one of the links running ePTP so will see how it holds.
Only weirdness out of the gate is that when I was checking the radio page of the slave, the selected receive frequency is bouncing back and forth between 5230, the actual transmit frequency of the master, and 5240 in a cyclic pattern. It does not appear to be affecting traffic in any way so appears to be some type of bug in the display. It may have been noted by someone earlier and I missed it.
If this runs steady we’ll try upgrading to 4.6 when it is officially released.
