If I were in John's shoes, I'd feel the same way.

Personally, I'd have more respect for Tranzeo if they complied with the 
GPL and BSD licenses. The ER1000 series is Linux-based. Nowhere in 
Tranzeo's documentation or on their web site do I find the information 
required by the GPL. If one gets into the unit, the information required 
by the BSD license isn't there either. We (LCWA, that is) have talked to 
them regarding this and they're basically non-responsive.

To many, it's a small thing. In my opinion, it matters because it speaks 
to ethics.

FWIW.

Bob


John Scrivner wrote:
> Now if they would just drop a mere $1000 to join WISPA as a Vendor
> Member they would earn mine. I use their products every day. I have
> asked them to join, face to face, at shows as recently as the last
> WiMax World a month ago. Tranzeo benefits regularly from WISPA but as
> yet seems reluctant to support our industry efforts.
> Scriv
>
>
> On Mon, Oct 20, 2008 at 11:25 PM, Kurt Fankhauser <[EMAIL PROTECTED]> wrote:
>   
>> I read every word. Tranzeo has earned my respect.
>>
>> Kurt Fankhauser
>> WAVELINC
>> P.O. Box 126
>> Bucyrus, OH 44820
>> 419-562-6405
>> www.wavelinc.com
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of D. Ryan Spott
>> Sent: Monday, October 20, 2008 6:04 PM
>> To: [EMAIL PROTECTED]; WISPA General List; Mikrotik discussions; Mikrotik
>> Users Mailing List
>> Subject: Re: [WISPA] [Tranzeo] New Update - Tranzeo/Mtik disconnect issue
>> Oct 10th, 2008
>>
>> Ladies and Gentlemen,
>>
>> (Please pardon my extensive use of () and "" in this here email, I am
>> not so good with the typin' stuff!
>>
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>
>> A few weeks ago (years in some cases, hi Travis!) there was discovered a
>> "random disconnect issue between Tranzeo CPE and Mtik APs."
>>
>> First it was prism vs atheos (no, that was not it)
>> Then it was "tranzeo CPE are terrible. Yadda Yadda" (no that is not it
>> either as even MTIK CPE were seing this, although "not as often")
>> Then it was "you must have some power issue with the boards browning out
>> on the routeros board you are using" (nope, not that either)
>> Someone even threw in "Pluto is mad that it is not a planet any more."
>> (Pluto is now considered the largest member of a distinct population
>> called the Kuiper belt <http://en.wikipedia.org/wiki/Kuiper_belt>.)
>> Even I said it was not an issue and "hey they just disconnect a few
>> times a day.. who cares!" (whoops! talk to my P****** off customers!)
>> Even Marlon the strange wizard from the far side of the mountains said
>> the Tranzeo CPE were to blame (he convinced me to use Tranzeo over
>> SmartBridges! Thank Goodness!)
>> Travis from Idaho posted a forum entry here for Mtik to ignore or scoff
>> at: (Hi Uldis!) http://forum.mikrotik.com/viewtopic.php?f=7&t=24971
>>
>> I emailed Damian and another gentleman from Tranzeo privately and said
>> WTF kids? I did some network sniffing for them and was able to give
>> EXACT details about what was happening, when and how.
>>
>> We (Tranzeo and I, mostly Damian) opened a ticket with Mtik
>> (Ticket#2008091666000531):
>>
>>    Tranzeo laid out a packet sniff from Network Instruments Wireless
>>    Observer along with my wireshark packet sniff showing in brief that
>>    the Mtik AP was throwing out random zeros in it's beacon frame
>>    timestamp. They stated that when a zero is recieved, the CPE are to
>>    assume that there is a change in the settings of the wireless AP and
>>    they should disconnect and reaquire. (think of this as an INSTANT
>>    change from 802.11b to 802.11b/g and all your clients disconnect and
>>    reconnect, because, well, there is a change in the AP's
>>    capabilities. This is reasonable reaction to a notification of a
>>    change of settings.
>>
>>    Mtik replied with IEEE Std 802.11-2007 section 11.1.1.1 (located
>>    here if you have trouble sleeping:
>>    (http://standards.ieee.org/getieee802/download/802.11-2007.pdf
>>    *YAWN* let me tell you, this explains why wireless engineers are who
>>    they are.. whoa!) Mtik continued and said that the wording of this
>>    standard allowed for a timestamp of zero sent from the AP and
>>    basically the CPE should deal with it and play through.
>>
>>    Damian learned some Latvian so he could swear in a diffrent language
>>    than Canadian. Honestly, he likes to be legal in APs etc and just
>>    cannot see why us ULS users would flaunt the FCC _and_ put up with
>>    these Mtik bugs. I mentioned something under my breath regarding
>>    CPQs and firware updates about 3 years ago...
>>
>>    The nice gentleman engineer at Tranzeo placed some virtual CPE on a
>>    bench facing a Mtik AP and was able to reproduce the issue. He then
>>    released to me some very alpha firmware that would email him with a
>>    warning whenever a CPQ saw a zero frame. This alpha software would
>>    also IGNORE this frame and keep on trucking. This alpha firmware was
>>    given with the stern warning that if I changed ANYTHING on the AP I
>>    would have to really recycle it to make all the CPE realize there
>>    was a change. This poor engineer was probably overwhelmed when I
>>    installed this firmware on 110 CPQs in about an hour. I watched the
>>    log file generated by these emails and the events had to be
>>    happening in the hundreds per hour.
>>
>>    Mtik was silent so I poked Uldis a bit with a comment about silence
>>    from Latvia and no National holidays I could see along with:
>>
>>        While there is no specific _requirement_ to treat Zero as a
>>        reset, _most_ wireless CPE (including yours!) consider this to
>>        be a flag to reset.  If you don't then when the card is reset,
>>        the client will ignore all of the changes until the time stamp >
>>        the last one.
>>        This is the same as driving on the right side of the road. There
>>        is no _LAW_ saying you should do so, but you do because everyone
>>        else does! Perhaps there is a reason to drive on the left but
>>        not in this case! :)
>>
>>        I even showed Mtik support that even THIER Mtik brand CPE were
>>        disconnecting in some instances!
>>
>>    Mtik replied with a bit of beta software that seems to have helped.
>>    It is posted to the forum and only need be installed on APs.
>>    (remember CPE don't give out timestamps) This is the second or third
>>    iteration of this software.
>>
>> The Tranzeo engineer was receiving close to zero emails from my CPQ (A
>> LOT LESS) and is still seeing an occasional zero here and there on the
>> bench in Canada. He was doing a 72 hour test over the weekend but was
>> pulled off to perform testing on Tranzeo gear.
>>
>> Mtik released 3.15. This seemed to solve the issue and I down-graded to
>> TR6-3.6.7 from the alpha software.
>>
>> Do date, I now have:
>>
>>    1. Gray hair at 32.
>>    2. A really stressed out wife.
>>    3. a $500 loss in recurring revenue
>>    4. a bad name in the community.
>>    5. A fondness for scotch I did not have before.
>>    6. The following configuration:
>>
>>        TRCPQ with TR6-3.6.7CPQ:
>>        Long Preamble, accurate link distance settings, 512 RTS Threshold
>>
>>        Mtik532/XR2 with 3.15:
>>        /interface wireless
>>        set 0 ack-timeout=dynamic
>>        adaptive-noise-immunity=ap-and-client-mode allow-sharedkey=no
>>        antenna-gain=0 \
>>            antenna-mode=ant-a area="" arp=enabled band=2.4ghz-b/g
>>        basic-rates-a/g=6Mbps basic-rates-b=1Mbps \
>>            burst-time=disabled comment=2.4 compression=no
>>        country="united states" default-ap-tx-limit=0 \
>>            default-authentication=yes default-client-tx-limit=0
>>        default-forwarding=no dfs-mode=none \
>>            disable-running-check=no disabled=no disconnect-timeout=3s
>>        frame-lifetime=0 frequency=2417 \
>>            frequency-mode=regulatory-domain hide-ssid=no hw-retries=4
>>        mac-address=00:15:6D:64:21:2C \
>>            max-station-count=2007 mode=ap-bridge mtu=1500 name=wlan1
>>        noise-floor-threshold=default \
>>            on-fail-retry-time=100ms periodic-calibration=default
>>        periodic-calibration-interval=60 preamble-mode=\
>>            both proprietary-extensions=post-2.9.25
>>        radio-name=00156D64212C rate-set=default scan-list=default \
>>            security-profile=default ssid=sultan2.irongoat.net
>>        station-bridge-clone-mac=00:00:00:00:00:00 \
>>            supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps
>>        supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps \
>>            tx-power-mode=default update-stats-interval=disabled
>>        wds-cost-range=50-150 wds-default-bridge=none \
>>            wds-default-cost=100 wds-ignore-ssid=no wds-mode=disabled
>>        wmm-support=enabled
>>        /interface wireless manual-tx-power-table
>>        set wlan1 comment=2.4
>>
>> manual-tx-powers="1Mbps:17,2Mbps:17,5.5Mbps:17,11Mbps:17,6Mbps:17,9Mbps:17,1
>> 2Mbps:17,18\
>>
>>
>> Mbps:17,24Mbps:17,36Mbps:17,48Mbps:17,54Mbps:17,HT20-1:0,HT20-2:0,HT20-3:0,H
>> T20-4:0,HT20-5:0,HT20-6:0,HT2\
>>
>>
>> 0-7:0,HT20-8:0,HT40-1:0,HT40-2:0,HT40-3:0,HT40-4:0,HT40-5:0,HT40-6:0,HT40-7:
>> 0,HT40-8:0"
>>
>> I think we may have all been really quick to "blame Canada!" in this
>> instance. I think we were all burned just a bit by the CPQ fun we all
>> had a few years ago, and Tranzeo's older (smaller?) APs are not the
>> best-est in the world. But in this case, I believe that Tranzeo CPQ/CPE
>> were "doing the right thing" and resetting like they should. I _think_
>> that they are well engineered with serious thought going into them with
>> regard to what part of the spec they follow to the letter of the law,
>> and what spec they follow "as everyone else does". I am not an radio
>> engineer but it seems to me that to ignore the zero frame is a recipe
>> for disaster.
>>
>> Let me point out here the time and effort **TRANZEO** took to prove that
>> this was an Mtik issue while Mtik simply deleted forum posts and ignored
>> the issue. I think Tranzeo spent well over $8K in labor while using
>> their $100K+ analyzers to prove this issue and even provide a fix hint
>> to Mtik an un-affiliated competitor! Damian and his engineer have a
>> fiduciary responsibility to really not help their competition
>>
>> I know I sound like a Tranzeo fan-boy here so let me be straight.
>> Tranzeo makes great consumer CPE.... APs? Not so much! :) I like my
>> Mtiks (when they are not making me go gray and crave scotch)
>>
>> If you have any questions, shoot away.
>>
>> ryan
>>
>>
>> Randy Cosby wrote:
>>     
>>> Did it seem to help with latency as well as disconnects?
>>>
>>>
>>>
>>> Damian Wallace wrote:
>>>       
>>>> We saw an improvement.  Our customers with the issue have seen it
>>>> completely disappear.  Ryan can address that.
>>>> However, MT now seems to recognize that it is an issue in their code
>>>> which is what we maintained all along.  Its not a Tranzeo issue, so we
>>>> are closing it as a Tranzeo issue.
>>>> Damian
>>>>      -----Original Message-----
>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>>>> Behalf Of Chris Hudson
>>>> Sent: Friday, October 10, 2008 3:26 PM
>>>> To: [EMAIL PROTECTED]
>>>> Subject: Re: [Tranzeo] New Update - Tranzeo/Mtik disconnect issue Oct
>>>> 10th, 2008
>>>>
>>>> Damian did you guys load the patches on your test setup? Did everything
>>>> seem to work good for you?
>>>>
>>>>
>>>> Chris
>>>> ----- Original Message ----- From: "Damian Wallace"
>>>> <[EMAIL PROTECTED]>
>>>> To: <[EMAIL PROTECTED]>
>>>> Sent: Friday, October 10, 2008 3:29 PM
>>>> Subject: [Tranzeo] New Update - Tranzeo/Mtik disconnect issue Oct 10th,
>>>> 2008
>>>>
>>>>
>>>> http://forum.mikrotik.com/viewtopic.php?f=7&t=24971
>>>>
>>>> Fyi:  Tranzeo is closing this issue in our database.  It appears that MT
>>>> has fixed the issue using the patches in the post above.
>>>>
>>>> Damian
>>>>
>>>> ***************************************
>>>> Register your services in our FREE WISP Locator
>>>> http://www.part-15.org/maps/WISPSearch.asp
>>>> ***************************************
>>>> The PART-15.ORG tranzeo Discussion List
>>>> This is a Paid Subscription Email Discussion List Service.
>>>> All rights reserved. All content becomes the sole property
>>>> of PART-15.ORG
>>>> ***************************************
>>>> To unsubscribe from the list: Send an email to: [EMAIL PROTECTED]
>>>> In the Body: Unsubscribe Tranzeo
>>>> ***************************************
>>>> Register your services in our FREE WISP Locator
>>>> http://www.part-15.org/maps/WISPSearch.asp
>>>> ***************************************
>>>> The PART-15.ORG tranzeo Discussion List
>>>> This is a Paid Subscription Email Discussion List Service. All rights
>>>> reserved. All content becomes the sole property of PART-15.ORG
>>>> ***************************************
>>>> To unsubscribe from the list: Send an email to: [EMAIL PROTECTED]
>>>> In the Body: Unsubscribe Tranzeo
>>>> ***************************************
>>>> Register your services in our FREE WISP Locator
>>>> http://www.part-15.org/maps/WISPSearch.asp
>>>> ***************************************
>>>> The PART-15.ORG tranzeo Discussion List
>>>> This is a Paid Subscription Email Discussion List Service. All rights
>>>> reserved. All content becomes the sole property of PART-15.ORG
>>>> ***************************************
>>>> To unsubscribe from the list: Send an email to: [EMAIL PROTECTED]
>>>> In the Body: Unsubscribe Tranzeo
>>>>         
>> ----------------------------------------------------------------------------
>> ----
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>> ----------------------------------------------------------------------------
>> ----
>>
>> WISPA Wireless List: wireless@wispa.org
>>
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>> Archives: http://lists.wispa.org/pipermail/wireless/
>>
>>
>>
>> --------------------------------------------------------------------------------
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>> --------------------------------------------------------------------------------
>>
>> WISPA Wireless List: wireless@wispa.org
>>
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>> Archives: http://lists.wispa.org/pipermail/wireless/
>>
>>     
>
>
> --------------------------------------------------------------------------------
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> --------------------------------------------------------------------------------
>  
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>   


--------------------------------------------------------------------------------
WISPA Wants You! Join today!
http://signup.wispa.org/
--------------------------------------------------------------------------------
 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to