I have searched the forum for any reports of "The Dude" crashing Tranzeo radios. I saw a request outside of the forum regarding this but have been unable to find any information about this in the forum. Forgive me if I have missed it and started a new 'string'.
I may have an issue related to this. I have shut down "The Dude" and currently the radios are stable and passing 36Mbs. Tonight I will test this to see if I can make "The Dude" crash the Tranzeo 5.8GHz bridge again. I'll report details of my results (if there are any results) to this forum.
snags
exit page left
I have suspected that the Dude crashed an OSBridge radio for me. I cannot be sure of this as I could not risk crashing more radios at my customers premises. This was one of the early beta releases. I have now started using V1.1 on just a few easily accessible radios so we will see how that pans out.
In reality, I don't think it is really the dude doing it but more the devices reaction to the SNMP calls.
In reality, I don't think it is really the dude doing it but more the devices reaction to the SNMP calls.
Thanks GJS,
It's 1:30am here and I just launched "The Dude". So far so good. I really hope it's not "The Dude". It's such an easy program to use. I want to keep it!
I'll report later if things go badly. If I leave this string without a reply, assume that I was wrong and "The Dude" did not crash my Tranzeo's.
*crosses fingers*
It's 1:30am here and I just launched "The Dude". So far so good. I really hope it's not "The Dude". It's such an easy program to use. I want to keep it!
I'll report later if things go badly. If I leave this string without a reply, assume that I was wrong and "The Dude" did not crash my Tranzeo's.
*crosses fingers*
If the Dude does crash Tranzeo radios, you should start working with Tranzeo to get them to fix their firmware. If the Dude can crash them, then anybody can write an snmp probe that will crash them -- with the probe running from anywhere in the world. I can imagine that all Tranzeos around the world could be crashed after this thing starts running!!! Sounds like a major problem if it is true.
John
John
Hi I'm back. Sorry I've been away from the forum so long.
I have not proven that "The Dude" crashes Tranzeos but I need to say that I have not proven otherwise either. That test was haulted when I found an end user that had added a third party add-on to his game "World of Warcraft". SO "The Dude" still remains untested.
However, as my client played his game, packet loss would begin slowly at first and then we'd suffer greater and greater loss until a backhaul tranzeo 5.8GHz radio (two towers away), would crash. He reported to me that everything "seemed" fine until he installed the third party software.
Once identified as a possible source of the problem, I tested and retested over night (late hours) with the network member and we were able to sucessfully re-create the problem again and again. Each time it took about 40 minutes to crash the Tranzeo. Finally I suggested that he not play his game if he wishes for me to leave him connected to the network until he uninstalls and virus sweeps his machine. He agreed to leave his game off until he did so. Sometime later the radio crashed again. I called him and he assured me that he had removed and virus swept his computer and that it now tests clean (viruses were found and cleaned up).
After further probing, I discovered that this member had removed his router after it had failed and had no physical firewall. I cut him off again and he installed a new router. Still his system was crashing the tranzeo requiring a drive out to the tower to reboot every time. Scores of members would be down in multiple counties.
I did not want to suggest that he format. I consider that a last resort, but then I make my living from my computer and the data it manages. Anyhow he sugested that we format and since then we have not had another problem.
As I was debugging this issue I called and worked closely with Tranzeo and after talking with a couple differing "tech levels" was told that if the unit were UDP flooded with thousands of UDP packets per second, that the unit will require a "hard reboot".
I'll still test "The Dude".
I have not proven that "The Dude" crashes Tranzeos but I need to say that I have not proven otherwise either. That test was haulted when I found an end user that had added a third party add-on to his game "World of Warcraft". SO "The Dude" still remains untested.
However, as my client played his game, packet loss would begin slowly at first and then we'd suffer greater and greater loss until a backhaul tranzeo 5.8GHz radio (two towers away), would crash. He reported to me that everything "seemed" fine until he installed the third party software.
Once identified as a possible source of the problem, I tested and retested over night (late hours) with the network member and we were able to sucessfully re-create the problem again and again. Each time it took about 40 minutes to crash the Tranzeo. Finally I suggested that he not play his game if he wishes for me to leave him connected to the network until he uninstalls and virus sweeps his machine. He agreed to leave his game off until he did so. Sometime later the radio crashed again. I called him and he assured me that he had removed and virus swept his computer and that it now tests clean (viruses were found and cleaned up).
After further probing, I discovered that this member had removed his router after it had failed and had no physical firewall. I cut him off again and he installed a new router. Still his system was crashing the tranzeo requiring a drive out to the tower to reboot every time. Scores of members would be down in multiple counties.
I did not want to suggest that he format. I consider that a last resort, but then I make my living from my computer and the data it manages. Anyhow he sugested that we format and since then we have not had another problem.
As I was debugging this issue I called and worked closely with Tranzeo and after talking with a couple differing "tech levels" was told that if the unit were UDP flooded with thousands of UDP packets per second, that the unit will require a "hard reboot".
I'll still test "The Dude".
Hi,
I have noticed that dude causes Trango Radios to crash. We run a wireless ISP in the Northern Suburbs of Mpls./St. Paul. Trango 5.8 GHz radios are used as a wireless backbone. It's a Layer 2 network/bridging w/ 400 + users.
Every time I try to run dude I have trouble with my trango radios... Initially we sent techs out to the towers thinking we had trouble w/ radios only to discover our "problem" went away when we shut off Dude.
I tried paring dude back to ping only for monitoring purposes. I still had the same issues with trango wierdness. Am I missing something? There has to be a way to trim back Dude so one can use it for simple network monitoring. Any ideas?
Thanks in advance!
Jay Mankie CTO
Genesis Wireless
320.396.2990
I have noticed that dude causes Trango Radios to crash. We run a wireless ISP in the Northern Suburbs of Mpls./St. Paul. Trango 5.8 GHz radios are used as a wireless backbone. It's a Layer 2 network/bridging w/ 400 + users.
Every time I try to run dude I have trouble with my trango radios... Initially we sent techs out to the towers thinking we had trouble w/ radios only to discover our "problem" went away when we shut off Dude.
I tried paring dude back to ping only for monitoring purposes. I still had the same issues with trango wierdness. Am I missing something? There has to be a way to trim back Dude so one can use it for simple network monitoring. Any ideas?
Thanks in advance!
Jay Mankie CTO
Genesis Wireless
320.396.2990
-
-
slipstream1
Frequent Visitor
- Posts: 52
- Joined:
I have Tranzeo, OSBridge, Milkrotik, High Gain Antennas, and Deliberant radios in my network. I have not had any issues with the Dude causing crashes. I have noticed that it keeps marginal link active because of the snmp link, it will not allow radios to go into power saving mode. So, the Dude has been a great help to me. I am still trying to figure out how much this program will actually do. Just my observations. 
I have done the additional testing that I promised and I have been able to "make" The Dude crash Tranzeo radios intentionally. I have however not yet tested The Dude to see if I can lessen the load on the Tranzeo radios to see if it can be used with minimal impact.
I want everyone to know that I like the dude. I want to be able to use it. I strongly suspect that the problem is in the Tranzeo radio and not with The Dude itself. As I reported earlier in this forum, upper level Tranzeo techs reported to me that too many UDP connections flowing through the Tranzeo 5.8GHz radio can cause it to crash even if the UDP packets are not destined for the Tranzeo unit. I feel that with further testing of The Dude on a bridged Tranzeo backbone could yield results suitable to allow me to cut back services on the Dude and not crash my Tranzeo's. I'm not seeing the same issue from ANY other radio. Let's go Tranzeo... get the fix done... I want to use ALL the features offered by "The Dude".
I want everyone to know that I like the dude. I want to be able to use it. I strongly suspect that the problem is in the Tranzeo radio and not with The Dude itself. As I reported earlier in this forum, upper level Tranzeo techs reported to me that too many UDP connections flowing through the Tranzeo 5.8GHz radio can cause it to crash even if the UDP packets are not destined for the Tranzeo unit. I feel that with further testing of The Dude on a bridged Tranzeo backbone could yield results suitable to allow me to cut back services on the Dude and not crash my Tranzeo's. I'm not seeing the same issue from ANY other radio. Let's go Tranzeo... get the fix done... I want to use ALL the features offered by "The Dude".
I'm sorry, I just noticed that I did not report my latest findings regarding "The Dude" and Tranzeo testing I've done.
I can intentionally crash Tranzeo radios on my network of thirty towers with "The Dude". I can repeat this process with success everytime. The Dude does crash Tranzeo radios.
The symptoms are as follows. Set "The Dude" to do the most complete and comprensive scan possible. Using the dudes most intense settings set the scans to begin probing the network and then monitor (through ping) a Tranzeo 5.8GHz radio.
The progression of packet loss slowly increases the longer that "The Dude" runs. At first the system will seem normal. Within a few minutes you'll notice that the Tranzeo packloss will begin. Gradually it becomes so bad that only a few (ICMP) packets get through. Meanwhile Internet traffic through the radio may still work although it is slow. Finally the pings become so bad that the Tranzeo radio loses http access. If this happens, it is likely that you will have to take a trip out to your tower to "hard" reboot the radio. If you can catch it soon enough and reboot using http access you've bought yourself more time, but if The Dude is left to run and the radio is not monitored, it will eventually lock up. I have found myself "camped out" at my computer over night in order to reboot the radio every few minutes while I figured out what was crashing the Tranzeos. The whole process from start of the dude to crashing a Tranzeo radio takes about 40 minutes. I've had it last as long as 3 hours when testing during low traffic time such as the middle of the night.
As I reported above, there are other things that can crash the Tranzeo radio's (virus/spyware), and as reported to me by the Tranzeo tech support people, high flow of UDP packets can cause them to crash. I suspect that in the course of doing what it does, The Dude is providing just the right combination of UDP packets with high traffic flow will and does set off this unfortunate situation.
I am going to test further the needed combination of The Dude and Tranzeo radios to see if there is a compromise that I can make to the Dude's settings that place less stress on the Tranzeo radios and yield enough results to be a practical network monitor for Tranzeo users.
I'll report those findings here. If you are a WISP and want to share information, war stories or need engineering services related to WISPing let me know.
I can intentionally crash Tranzeo radios on my network of thirty towers with "The Dude". I can repeat this process with success everytime. The Dude does crash Tranzeo radios.
The symptoms are as follows. Set "The Dude" to do the most complete and comprensive scan possible. Using the dudes most intense settings set the scans to begin probing the network and then monitor (through ping) a Tranzeo 5.8GHz radio.
The progression of packet loss slowly increases the longer that "The Dude" runs. At first the system will seem normal. Within a few minutes you'll notice that the Tranzeo packloss will begin. Gradually it becomes so bad that only a few (ICMP) packets get through. Meanwhile Internet traffic through the radio may still work although it is slow. Finally the pings become so bad that the Tranzeo radio loses http access. If this happens, it is likely that you will have to take a trip out to your tower to "hard" reboot the radio. If you can catch it soon enough and reboot using http access you've bought yourself more time, but if The Dude is left to run and the radio is not monitored, it will eventually lock up. I have found myself "camped out" at my computer over night in order to reboot the radio every few minutes while I figured out what was crashing the Tranzeos. The whole process from start of the dude to crashing a Tranzeo radio takes about 40 minutes. I've had it last as long as 3 hours when testing during low traffic time such as the middle of the night.
As I reported above, there are other things that can crash the Tranzeo radio's (virus/spyware), and as reported to me by the Tranzeo tech support people, high flow of UDP packets can cause them to crash. I suspect that in the course of doing what it does, The Dude is providing just the right combination of UDP packets with high traffic flow will and does set off this unfortunate situation.
I am going to test further the needed combination of The Dude and Tranzeo radios to see if there is a compromise that I can make to the Dude's settings that place less stress on the Tranzeo radios and yield enough results to be a practical network monitor for Tranzeo users.
I'll report those findings here. If you are a WISP and want to share information, war stories or need engineering services related to WISPing let me know.
Normis, how does one go about trouble-shooting this type of SNMP problem to determine what is happening? I suspect we are having similar problems with some devices (Trango AP's mostly) locking up when The Dude is running. I suspect that the dude is polling data from the AP's quicker than the AP can respond (with Trango, when information is requested, the AP gathers the data from all the SU's that are associated at the time). Trango denies having any problem with SNMP and I'd like to what the problem is.we are using the SNMP according to standards, and have checked this scan with many other non-tranzeo devices. if the tranzeo responds to a standard SNMP scan with an error, it may be a problem with their software, and they would have to check this issue.
Who is online
Users browsing this forum: No registered users and 25 guests