Here are a few threads related to control frame timeouts. There are more than a few people having problems with. These are all individual threads related to timing disconnects in one way or another. This is just from the first page of a search “control frame”. I don’t think the disconnects can be considered isolated they are happening on all frequencies, different hardware, PTP, PTMP, different ROS versions, etc etc.
if everyone you mentioned would give remote access to such location from AP side and also from the client ethernet side so we could have access to the client at the time when the disconnection happens and we would be allow to debug that system (reboot, install packages), then it would speed up the process.
As we are unable to reproduce such problem in lab.
I am not quite sure how you can be provided with access to the client from the Ethernet side as I am sure most of these locations are fed their only net access through the wireless interface. As I mentioned to you some of the clients I gave you access to have access available to them through a second wireless interface but not through the Ethernet interface, the other problem is that you guys are on the opposite time schedule as we are so you are accessing our network during off peak hours and disconnects rarely occur during these times.
You guys really need to get your own test network setup so you can reproduce real world conditions and problems rather than having to rely on your end users to beta test/trouble shoot software issues. I don’t see how you can provide bug free reliable software without your own outdoor test network.
No need to mention I fully agree whit what chadd mentions here.
In the next week, time given, I will see if I can find a client with the problem where I can use another second link to create a trouble free connection to the ´back´ (=ethernet port) of troubled client.
But like chadd already mentioned, that is going to be a bit of a problem, since if client would have a troublefree alternative connection I would already use that for his connection!
Or I should find a client with a stable connection that would also be setup with a second link that has problems!
I would think MT runs a network in Latvia. I would be really dissapointed if they didn’t. Or maybe they do and like old sovjet style no competition allowed!
Yesterday made a scan on a client unit that is regurlarly disconnecting (20-30 times a day, but daytime hours)
Client unit: SXT, Tx/Rx signal -53/-57, CCQ >95%
I scan 12 AP’s in the 5500-5700 range (and another 7 in 5200-5400 range).
Working freq. of this unit is 5680-10Mhz and I pick up -87 signal in 5685(10Mhz), -64 at 5640(20Mhz) and a -86 at 5700(10Mhz) to mention only the close ones.
This AP+client are running normal 802.11 while the mentioned close freq. units all run NV2 protocol.
Why would this unit disconnect so often? We already had swapped his CPE twice now, everytime the same result. So it is noting to do with the hardware. (First unit was a rb411 with R52 card in a plastic, but shielded, box. 2nd was also a SXT where 10Mhz channel stopped functioning.)
The signal of the 5685 AP is only 5Mhz away but 30dB weaker. (But they do ´touch´ eachoter in their band)
The signal of the 5640 AP is 40Mhz away but at -64 which means only 7dB weaker. But since this last one is alsoa 20Mhz band it only separates 30Mhz from troubled CPE.
Normally spoken (802.11) this would not give problems. A year ago, before TDMA was introduced in this valley it wasn’t a problem! It worked fine then with the rb411 but now it is not anymore.
Abandoning NV2 on other of my AP’s is not an option anymore since it does help other units to get better stability plus competition also uses TDMA which I have no control off.
Oh yeah, some add-on information on the post above:
Client claims he doesn’t notice any disconnects, not even during regular Skype phone calls with family that sometimes can last for half an hour…
So my feeling is (I have same reports from other clients with troubled units, they notice nothing.) that the disconnects mainly happen during idle time of stations.
The key word there being lab, I can’t repeat it in a controlled “lab” setup either. I tested NV2 on an indoor network for a while before I started running it outdoor and I never saw disconnects on the indoor network but once I started running it outdoors then the disconnects appeared.
If MT cannot reproduce such issues in their lab (with real customers)and our networks suffer from disconnects, what are we doing wrong then?
Can we ask what equipment MT is using in it’s lab (from CPE to internet) I ask this question because a recent issue with a 433AH virtual AP using 4.17 + OSPF was causing ping drops but downgraded the 493ah from 4.17 to 3.30 which the 433’s sector antenna’s were connected to and problem solved?
n21roadie, please don’t bring up such old problems. OSPF has been re-made for v5 and wireless drivers have been changed too. what was true with v4.17 and v3.30 isn’t the same anymore in v5.5, did you try to upgrade all your devices to v5?
You probably think that all we do is ask to uprade, but the upgrades contain improvements and fixes, and that’s why we make them
Without full change logs it makes it difficult to determine if it is worth it to risk upgrading to the current release. I have been told in the past to upgrade to fix a problem yet the fix is not listed in the change log. So why would I upgrade if there is no fix listed in the change log?
Like it or not new bugs are introduced with the latest release all the time, so I steer clear of them until they have been out for a little while if possible.
You both are completely right. Hence I always upgrade in the hope issues are solved, even ones not listed in the change log, and hence yes, I cut my fingers every time again…
I try to stay at least some weeks behind with upgrades but sometimes I really need to try things that ARE mentioned in the change log.
But overall, we could do with lots more info on what has been worked on by MT development. Like these disconnects. MT wouldn’t take its customers serious if they are not at least scratching themselves behind their ears and think: “What is it these guys consistently keeps nagging on about?” “We better take a deeper look into the subject, even although we can’t find it in our own network.”
To create an ´outdoor lab environment´ I would suggest MT sets its network up in such a way that several AP’s work in very close (spectrum) vicinity of each other and have at least 25 client on each AP. If you take about 4 or 5 AP’s this way all basically in ´view´ of each other, it is almost guaranteed you will have one or two CPE’s start playing up…
And if not, please show us the full setup. Maybe we are just doing something wrong…
I re arranged some working channels of some AP’s of my networks last weekend. Some units that were continuously disconnecting and had probably interference issues from far away (>15km) AP are now very stable.
BUT, now I have other units in some other AP network starting to play up again! Meaning I have to start shifting again. This time it is an AP that receives an 5Mhz different NV2 signal from an AP 15km away in an absolutely no NLOS or LOS situation (25meter high hill in-between!). It picks up that signal bounced from some buildings on the other side of the street I presume.
During the playing with this issue last weeks I get also more and more the ´feeling´ it is actually mostly my own MT AP’s running NV2 creating the issues.
Reverting back to no-NV2 is not an issue since in that case foreign TDMA almost immediately starts bringing my AP’s down. I have done so and than I see all CPE’s in my AP register starting to disconnect regularly. Even if ´foreign´ channel usage is not in the same band as the one the AP works in.
Rudy- looks like you have a ongoing battle trying to select a uncongested channel, if it was me and if distance wasn’t a issue is use 24GHZ (twentyfour) http://www.stelladoradus.com/24GHz.point.to.point.link.php for backhaul or some other unlicensed band for backhaul and retain the frequency the backhaul was using ( I assume you are using 2.4/5.8 also for backhaul PtP) up with a standby AP, so others cannot use that frequency and then you should have two frequencies to use?
I have too many backhauls to see that as an option. Too dear. But yes, I have been playing with that idea.
On the other hand, my PtP links are all fine. I have several back-hauls criss cross the valley to reach corners others can’t but they all don’t have any issues (at the moment). Probably because the use of high gain (concentrated beam!) and better antenna’s make them less vulnerable for the disconnection issue. And maybe NV2 handles PtP links better than PtMP.
And yes, I am re-arranging some of my networks to create more free spectrum but that is quit a process since all clients have the AP freq. locked (´freq scan list´) and thus have to be ´on-line´ to swap these as well while I don’t do this during busy hours of the day.
Little by little I am getting there so we’ll see. Just got some info abt v5.6 fm MT. see what they come up with… and how it will work out.
