here, here wifiguy! I couldn’t agree more.
ccie4526, you are basically saying, expect less, but pay more with Canopy. This is precisely why I continue to seek alternative, more capable and less expensive platforms like the nanostation2 and Mikrotik.
I think the real issue is that we are all identifying waning performance and capabilities from motorola now, as compared to the past.
Most agree here, there’s nothing like an unregulated 5700SM, P8 on 7.3.6 firmware. I bought my first kit in 2002, and of those 30 modules, I still have 28 working flawlessly with no support issues. Compare than to my most recent purchase of 100 SM lites. What a pack of crap. 19 have already been RMAd.
wifiguy wrote: I completely disagree with you. If the device claims it can do NAT/DHCP than it damn well better be able to do it, otherwise it shouldn't be advertised as a feature.
Completely agree with you!
The need to add an external router just to do NAT seems absurd to me!
It increase the installation cost, but also:
1) add some hardware that customer must keep running, properly connected, powered on (possible problems). It even waste space on customer's house (and he doesn't understand the need for another separated device... and me too)
2) configuring the SM in bridge is a potential security hole. An advanced customer could disconnect from the external router and cause IP conflicts, or broadcast, or sniff traffic or whatever else. Not sure as NAT
No way...
Any 30$ consumer router do NAT much better than Canopy SM. I don't believe it is difficult to implement in a platform already based on Linux :(
My 2 cents...
ccie4526 wrote: My $0.02 worth....
[soapbox ON]
We are dealing with wireless bridge radios here. These are not designed to be NAT devices or routers. These are not designed to be DHCP servers. Quit expecting this device to be the be-all and end-all solution. Put a (Linksys/DLink/Netgear/yourchoice) device behind the ethernet port of the radio and let that purpose-designed device take care of what happens inside the end-customer network. If you want to assign addresses to those end-customer firewalls/routers/whatever, set up a DHCP server on Linux/BSD/Windows and let that device do what it is designed.
[soapbox OFF]
We already run a SOHO router behind every SM for security reasons, as well as DCHP adressing purposes for the customers internal network. What we would like though, is to not have to use up so many static IP addresses. Our network has grown to the point that it's becoming a PITA to come up with enough static IP's for new installs. We are going to test the scenario you describe for handing DHCP adresses out to customers via a Windows server and see how the gear behaves in this type of scenario. You can have your soapbox back now, I'm done.
hpiguy wrote:
We already run a SOHO router behind every SM for security reasons, as well as DCHP adressing purposes for the customers internal network.
hpguy
if you already have a SOHO router on the customer side, you actually have no reason to enable NAT on Canopy.
Regarding to static IP (I guess you mean public IP) I honestly don't see a real advantage on assigning them to the customer via DHCP.
In my experience only a little percent (5%) of our customers switch the SM off when they don't use it, so the overall saving of public IPs will be very poor.
It could be of course an advantage in terms of configuration management.
Unfortunately, in Italy we have a very strict regulation about supplying connectivity. Due to an anti-terrorism law, every ISP has to log every single IP session and keep into an archive available for authorities request. For this reason I prefere to configure static IP or implement NAT and log every session with a syslog server.
Lately we have been seeing some very odd situations aswell.
Radios seem to be losing the ability to authenticate and checkout bam profiles properly. We have P9 & P10 Canopy 900/2.4 gear running primarily 8.2.2. For the most part it runs well. However on 900, 2.4, and 2.4lite sms, there seems to be some issues with radios losing their ability to register to the access point or authenticate.
15 other 900MHz sms on this access point work fine… virtually identical configurations.
Session Timeout: 2, AirDelay 17 (approximately 0.47 miles (2499 feet))
Session Count: 422, Reg Count 522, Re-Reg Count 178
RSSI (Avg/Last): 1724/1747 Jitter (Avg/Last): 5/6 Power Level (Avg/Last): -65/-65
Another 900 from earlier today…
Session Timeout: 0, AirDelay 240 (approximately 6.68 miles (35280 feet))
Session Count: 43, Reg Count 38, Re-Reg Count 13
RSSI (Avg/Last): 1391/1371 Jitter (Avg/Last): 4/4 Power Level Avg/Last): -74/-76
Both of these worked fine for the longest time.
I see 3-5 of these a day sometimes.
I would really like to know what is actually happening to them…
Syslog output, auth logs, are all very vague.
Even in the changelogs they state what the problem is, in a nutshell…
These radios arent even lites… just 8.2.2 firmwares. 90% of our radios are bridge mode, there’s the odd NAT straggler customer who’s still in nat from way back.
The really curious thing is… alot of these radios when tested in an indoor
testing scenario, link to an AP fine, and transfer data to/from the internet through it. Yet when re-deployed, cannot achieve a long-distance link.
Anyways… overall, I love the linear performance of canopy.
Yet still the whole stability/reliability thing can make your heart skip beats from time to time.
Why not just call up Motorola, give the MAC address, and re-enter the calibration data? You could have done that during your truck roll to save a second roll and a radio replacement. There is a web interface to enter the data.
We have thousands of SM’s (900, 24 and 57)running 8.2.4 with NAT on and we are not experiencing this problem.