Thanks John! I can say that I was frustrated by this whole situation. I managed to hang on to all of my customers through it but it has taken a lot of work and money. Not to mention very patient customers.
The part that makes me the maddest is that we had to pitch a fit as a group to get anyone to deal with this issue. Frankly I don't care WHO's fault it is, I just want it fixed. Shame on MT for tunnel vision and getting stuck on tranzeo when tranzeo wasn't the only company that had the trouble. And a big shame on tranzeo for not following the standards!!!! If you are going to move away from the standards at least put an option in the system to allow us to set the device back to a standards mode. I sure hope this problem goes away and doesn't come back. marlon ----- Original Message ----- From: "John Tully" <[EMAIL PROTECTED]> To: "Marlon K. Schafer" <[EMAIL PROTECTED]> Sent: Tuesday, October 21, 2008 7:41 AM Subject: Tranzeo client timestamp issue > Hello Marlon, > > I was forwarded a post from a Ryan on the mailing list. You can post this > response if you like. > > > > The tranzeo timestamp issues comes from tranzeo implementing a timestamp > check that is not included in the 802.11 standard for ap to client > communications. > > The timestamp check is included in the standard for the adhoc (IBSS) > wireless mode (which is not commonly used and we don't support) -- > and there is are reasons that it is included in adhoc mode and not in ap > to client mode. > > The standard requires clients to accept the beacon timestamp > unconditionally in ap to client mode. Tranzeo has added a specific check > because they said they thought it is logical that the check be applied to > ap to client mode. Good standards implementations do not add things to a > standard. These standards are made by IEEE committees of engineers that > are very specific for what they include and don't include. If a company > want to change a standard, then they need to join the committee and > through peer review get a new standard approved. > > We have made a work-around for their violation of the standard. But > rather than somebody saying thank you, the old saying of 'no good deed > goes unpunished' is proven again. We make many work-arounds for incorrect > standards implementations and extension by companies such as Microsoft, > Realtek, and now Tranzeo. We do that to help our customers, but in > reality, the vendors that do not follow the standards should fix the > problem. > > In summary, it is very unfair that we are blamed for problems made by > another company that does not implement the standard correctly. Many > people in this business don't do it just for money, but because they like > making things (be it WISP or equipment for WISP). Rants without basis > kind of put a wet blanket on the whole party. > > For those that would like to research this, here a clear reference from > the 802.11 standard that is pertinent: > > From 802.11-2007, 11.1.1.1 TSF for infrastructure networks: > ... A receiving STA shall always accept the timing information in Beacon > frames sent from the AP servicing its BSS. If a STAâ?Ts TSF timer is > different > from the timestamp in the received Beacon frame, the receiving STA shall > set > its local TSF timer to the received timestamp value. > > Tranzeo decided to assume that receiving a beacon with timestamp less than > in previous beacon indicates that AP has restarted (the standard has > another method to handle restarted ap units). This check is not in the > standard and this a tranzeo addition to the standard that has cause the > disconnect problem that Ryan has suffered from. > > Regards, > > John > > > > > -------------------------------------------------------------------------------- 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/
