How did slip past without me noticing it came out?! I’ve been waiting for new software for 3+ years!
So far it looks pretty good and it appears they have solved my problem of not needing to SSH tunnel into the software because something in our VPN was preventing access.
And I like the new port mirroring option if you needed to do some on-site packet capturing.
Anyone else have any comments or problems?
We have 2 CMM with the gps module not working, I like the idea that we can put them back to work with one AP generating pulse, and the CMM receiving that pulse and sincronize all the canopy elements on that site.
cool version upgrade.
so if you can generate the pulse from an AP, could you use something like syncpipe injector to generate an actual gps timed pulse?
Well its a pulse, and all the canopy equipment will be sincronized, but not will be satelite pulse.
Im wondering if you use a syncpipe, since it is gps generated pulse, would the sync sent to the cmm be gps timed appropriately. Would there be an offset in the sync propagation that would be notable since the sync is generated in the syncpipe, sent to the cmm then repropagated to the APs, Im assuming there would be a delay, but I dont know how much that would be.
if your POPs are far away more than 2km, doesn matter that they dont have the same pulse; the important thing is that all the equipment in each tower is sincronized.
since when?
The rule is if an AP on one tower can hear any AP on any other tower, they all need to be in sync.
thats what I thought, but im often mistaken so I rarely take my thoughts and apply them as facts.
So would using a syncpipe to generate the gps sync then sending it to the APs create a notable delay (if it even worked?)
Syncpipe, CTM, and CMM are all in sync with each other.
im talking about the delay added by going from the syncpipe to the cmm to the ap instead of syncpipe to ap or cmm directly to the ap. if it adds 2ns i dont think it matters but if it adds 2ms im guessing it would
Does the SyncPipe not use the RJ12 timing cable direct into the APs?
one ap, the cmm does 7 with an uplink
Has anyone downloaded this software to their CMM micro yet just to see if there are any problem with it
I’ve got it running on all my CMM’s now and no problems so far.
Running great for a few months now on several CMMs. (We were working with the beta version)
It successfully overcame a GPS problem we were seeing on several towers where we would periodically lose sync. After upgrade we see NO GPS dropouts whatsoever on towers that previously would drop sync for 1-2 minutes at a time, 3-5 times a day.
As I understand it, there are several GPS-related changes in the 3.0 firmware, such as pushing GPS-related support tasks to a higher scheduling priority than network traffic handling. (face it - if GPS drops then sync drops and connections drop, so network traffic is significantly interrupted anyway) It also changes something where it now uses warm instead of cold reboot of GPS, or something like that, when experiencing possible GPS problems. (which if you know anything about GPS you know that means a huge difference in sync reacquisition time) There’s also some changes that fix a problem recognizing some newly-manufactured replacement GPS cards.
Oh, and SNMP finally reports the correct value for rxUnicastPkts… 
j
I am having a programming issue with CNUT, anyone Seen this?
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Checking Network Element Status ( SITE= Golf Village CMM )
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Current = CANOPY CMM 2.2 Build 2 Feb 23 2006 16:45:22, , 5 ( SITE= Golf Village CMM )
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Using Package G:'IT_Department’Documentation’Canopy’Firmware’CMM’CMM_30_BUILDOFFICIAL.pkg3 ( SITE= Golf Village CMM )
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Transferring Files: boot.bin ( SITE= Golf Village CMM )
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Programming: ( SITE= Golf Village CMM )
[u:1z4farg1]Host: 10.8.XX.XX;ESN: 0A003EE01A35;Message: Programming Error: Cannot connect to device. ( SITE= Golf Village CMM )[/u:1z4farg1]
Are you using CNUT 3.x?
jlewis wrote: I am having a programming issue with CNUT, anyone Seen this?
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Checking Network Element Status ( SITE= Golf Village CMM )
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Current = CANOPY CMM 2.2 Build 2 Feb 23 2006 16:45:22, , 5 ( SITE= Golf Village CMM )
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Using Package G:\'IT_Department\'Documentation\'Canopy\'Firmware\'CMM\'CMM_30_BUILDOFFICIAL.pkg3 ( SITE= Golf Village CMM )
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Transferring Files: boot.bin ( SITE= Golf Village CMM )
Host: 10.8.XX.XX;ESN: 0A003EE01AXX;Message: Programming: ( SITE= Golf Village CMM )
[u:154g675d]Host: 10.8.XX.XX;ESN: 0A003EE01A35;Message: Programming Error: Cannot connect to device. ( SITE= Golf Village CMM )[/u:154g675d]
Test whether you are able to telnet from the machine running CNUT to the CMM. It looks like it's successful in transferring the boot.bin file - the next step is to telnet to the device and initiate the update, which appears to be failing. If you are unable to telnet manually (user 'root' and whatever password you use for your CMM) then you need to determine what is preventing it, likely a firewall rule somewhere blocking TCP port 23. (either on the machine running CNUT or on a router/firewall somewhere between there and the CMM - we use them between backhauls and CMMs to isolate each tower, for example)
j
I am not blocking anything on my network… I am able to upgrade BH’s, SM’s and AP’s without issues. Thoughts? Or am I still missing something?