+ Reply to Thread
Page 1 of 3 123 LastLast
Results 1 to 10 of 24
  1. #1
    Join Date
    Jan 2000
    Location
    Langley, Canada
    Posts
    8,090
    Rep Power
    10

    Default GeckoV4 4.1.10 build 6736 has been released

    GeckoV4 version 4.1.10 build 6736
    https://www.dropbox.com/sh/txr63s8t9eoormy/VC-MoLgS69

    note: 4.1.9.x are unpublished beta builds.

    What’s new:
    • System-wide (internal) updates to improve reliability, and performance
    • MIPS-COMPEX (WAR-1) releases will be available throughout the 4.1.10 series.
    • Qualcomm Atheros 11n and 11abg updates
    • PPPoE server has been updated
    • OLSR updated to fix issues with XSCALE platforms
    • SNMP memory leaks resolved
    • SSH UI phantom sessions has been resolved
    • Much more...

  2. #2
    Join Date
    Dec 2002
    Location
    Frozen Tundra of Canada
    Posts
    2,835
    Rep Power
    18

    Default

    I've installed this 4.1.10 release onto two AP's and all their CPE's. One of the AP's is an XScale Metro 533Mhz with 19 CPE's (WAR1a-SIAM & WAR1-MIPS) and the other AP is a Laguna with 28 CPE's (WAR1a-SIAM & WAR1-MIPS & a Xscale-WAR2).

    Everything upgraded properly, everything rebooted properly, everything associated properly. I don't have much more to report yet, but I just wanted to say that there were no surprises or bricks or lost configs or anything like that.

  3. #3
    Join Date
    Jan 2000
    Location
    Langley, Canada
    Posts
    8,090
    Rep Power
    10

    Default

    That is great to know, thank you.

  4. #4
    Join Date
    Dec 2002
    Location
    Frozen Tundra of Canada
    Posts
    2,835
    Rep Power
    18

    Default

    Hello.

    OK, I've just tried the R2SHPn cards again with Gecko Version 4.1.10 Firmware.
    The manufacturer of the R2SHPn card says the following:

    Code:
    "Here are the tx-power values that you should be seeing from the cards eeporom:
    
    11G  - 6-24mbps  26db      36mbps    25db       48mbps 24db     54mbps 23db
    HT20 - mcs0-mcs3 26db      mcs4-mcs5 25db       mcs6   23db     mcs7   22db
    
    Plus there is a 6db offset, so for the real output values you need to add 6db,
    so the real card output would range from 32db at 24Mbit to 28db at mcs7. You
    should be able to set it at full or default power and it will automatically adjust."
    So, formatting this like a Star-OS F9 Log display, this is what the manufacturer of the R2SHPn card says that I should expect to see...

    Code:
    6M     9M     12M    18M    24M    36M    48M    54M    mcs0    mcs1    mcs2    mcs3    mcs4   mcs5    mcs6   mcs7
    26.0  26.0   26.0   26.0    26.0    25.0    24.0    23.0    26.0      26.0      26.0       26.0       25.0      25.0       23.0      22.0
    
    Which would mean that the Real Power with the +6dB offset is:
    
    6M     9M     12M   18M    24M    36M    48M    54M    mcs0    mcs1   mcs2    mcs3    mcs4   mcs5    mcs6   mcs7
    32.0  32.0   32.0   32.0    32.0    31.0    30.0    29.0    32.0      32.0      32.0       32.0       31.0      31.0       29.0      28.0 <- REAL POWER
    However, if I set the card at 'full' power, with an overdrive of 0, Country Code of ##, Regulatory Compliance & Limit both off - on channel 2437, Star-OS then reports 18.0 db across the board. This is even with a ## country code selected, with an 'all-freq' license, and with [ ] Regulatory Compliance and [ ] Regulatory Limits unchecked.

    Code:
    Dec 31 02:14:36 kernel: wifi: phy0: 2437 power levels: (overdrive: 0 dBm)            mcs0 mcs1 mcs2  mcs3  mcs4  mcs5  mcs6  mcs7
    Dec 31 02:14:36 kernel: wifi: phy0:          6M   9M   12M  18M  24M  36M  48M  54M  mcs8 mcs9 mcs10 mcs11 mcs12 mcs13 mcs14 mcs15
    Dec 31 02:14:36 kernel: wifi: phy0: 1 chain  18.0 18.0 18.0 18.0 18.0 18.0 18.0 18.0 18.0 18.0 18.0  18.0  18.0  18.0  18.0  18.0
    This is the exact same results that I get from channel 2417 through 2457 (channel #2 to #10) - flat at 18.0 dBm across the board, all modulations & rates.

    If I select either Channel #1 (2412) or Channel #11 (2462) then the results are different
    Code:
    Dec 31 02:14:36 kernel: wifi: phy0: 2412 power levels: (overdrive: 0 dBm)            mcs0 mcs1 mcs2  mcs3  mcs4  mcs5  mcs6  mcs7
    Dec 31 02:14:36 kernel: wifi: phy0:          6M   9M   12M  18M  24M  36M  48M  54M  mcs8 mcs9 mcs10 mcs11 mcs12 mcs13 mcs14 mcs15
    Dec 31 02:14:36 kernel: wifi: phy0: 1 chain  15.0 15.0 15.0 15.0 15.0 15.0 15.0 15.0 15.0 15.0 15.0  15.0  15.0  15.0  15.0  15.0
    
    Dec 31 02:14:36 kernel: wifi: phy0: 2462 power levels: (overdrive: 0 dBm)            mcs0 mcs1 mcs2  mcs3  mcs4  mcs5  mcs6  mcs7
    Dec 31 02:14:36 kernel: wifi: phy0:          6M   9M   12M  18M  24M  36M  48M  54M  mcs8 mcs9 mcs10 mcs11 mcs12 mcs13 mcs14 mcs15
    Dec 31 02:14:36 kernel: wifi: phy0: 1 chain  14.0 14.0 14.0 14.0 14.0 14.0 14.0 14.0 12.5 12.5 12.5  12.5  12.5  12.5  12.5  12.5
    So, basically - Channel #1 (2412) gives flat 15.0 dBm on every rate, Channels #2 - #10 (2417-2457) gives flat 18.0 dBm on every rate, and Hannel #11 (2462) gives 14.0 on all G rates, and 12.5 on all N rates.

    NOW - on all other Channels - from 2312 - 2407 and on Channels 2467, 2472, 2477, 2482, the powers and rates are exactly what the Manufacturer says the card should be doing.
    Code:
    Dec 31 02:14:36 kernel: wifi: phy0: 2407 power levels: (overdrive: 0 dBm)            mcs0 mcs1 mcs2  mcs3  mcs4  mcs5  mcs6  mcs7
    Dec 31 02:14:36 kernel: wifi: phy0:          6M   9M   12M  18M  24M  36M  48M  54M  mcs8 mcs9 mcs10 mcs11 mcs12 mcs13 mcs14 mcs15
    Dec 31 02:14:36 kernel: wifi: phy0: 1 chain  26.0 26.0 26.0 26.0 26.0 25.0 24.0 23.0 26.0 26.0 26.0  26.0  25.0  25.0  23.0  22.0


    So, any of the default settings UNDERdrives the card quite a bit - by 8 dBm to 13.5 dBm in some channels & rates. I can bump the card up manually, by manually doing an overdrive - but then that defeats the automatic settings and could overdrive the card at some rates. Besides, proper performance out of a card isn't only about setting the power correctly - anytime you manually set a card's power (even if it is not over-driven) this can potentially lead to performance issues. http://dl.ubnt.com/ubi_mtik_power.pdf.

    In summary - if I set the Channel to anything other than Channel 1 to 11, then the card works as the manufacturer says it should. The powers are great, the throughput is great, the power output can go up and down automatically as the cards negotiate rates. However, if I set it to channels 1 through 11 (even with ## set, with Regulatory Compliance and Regulatory Limits turned off) then I get a flat power profile, with anywhere from 8 to 13.5 dBm less power than normal.
    Last edited by ninedd; 01-05-2014 at 12:33 PM.

  5. #5
    Join Date
    Aug 2007
    Posts
    139
    Rep Power
    11

    Default

    This isn't a big problem but it's odd test behavior that I thought I'd mention.

    With 4.1.10 installed on both AP and STA, PtP METRO link, each bridged eth to one R5SHPn mPCI card, HT40+ mode, WPA2, WDS, everything can ping everything and traffic moves normally.

    Replace the AP with a UBNT AP, bridged WDS, current firmware and traffic appears to move normally. However, although devices can be pinged on either side of the link from the other side and the METRO STA IP can be pinged from it's eth port, the METRO STA IP can't be pinged from the AP or through the AP. And although the AP can be pinged through the METRO, the METRO itself cannot ping the AP. Consequently, ping watchdog can't be used.

    I haven't tried this on prior firmware releases so this isn't necessarily unique to this version. Is this due to some sort of WDS incompatibility?

  6. #6
    Join Date
    Jan 2000
    Location
    Langley, Canada
    Posts
    8,090
    Rep Power
    10

    Default

    This could very well be a WDS incompatibility, or firewall on the AP. The WDS implementation used on Gecko is standard, but the UBNT AP may need to be configured (told) about your client - some APs have a WDS table you must enter your station mac addresses in manually to get WDS working properly.

  7. #7
    Join Date
    Mar 2005
    Location
    North Middlesex
    Posts
    1,454
    Rep Power
    15

    Default

    I am considering deploying some Access points in the 5.4-5.5 GHz band, but I need DFS for that. I have installed the DFS license feature on my unit on the test bench, but I do not see where to enable it.

    Is DFS in Gecko functional or still a work in progress? If it is still a work in progress, is there any wild guess as to when it may come to market. 6 months, a year, or maybe no idea whatsoever?

    Just wondering.

    Edit: I guess what I really need is the radar detection and avoidance parts to make it legal.
    Last edited by Stratolinks; 01-08-2014 at 10:34 PM.

  8. #8
    Join Date
    Nov 2002
    Posts
    2,386
    Rep Power
    18

    Default

    Sure it is

    uncheck Regulatory Compliance and the DFS channels appear in the channel list with * next to them.

    Not sure about CA though, I only use US.

  9. #9
    Join Date
    Aug 2005
    Posts
    99
    Rep Power
    13

    Default

    In 4.1 DFS channels are still available (Regulatory Compliance off), but without DFS functionality. No startup-delay and no log entries. Where I need DFS, I use 1.5.17 or Gecko 4.0 instead of 4.1. Haven't tried the latest 4.1 versions, as I haven't seen any message about changes of this.
    So far, as long as 4.0 fullfills our needs, it is OK. Just a little frustrating not to take advantage of the newest software. But the lack of DFS is eventually going to be a showstopper here at some point, as we are converting from 11g to 11an and need to use DFS-channels.
    Question: When running 4.0 on AP due to need of DFS, would the clients benefit from using 4.1.10 or is it best to stay with same version as AP?

  10. #10
    Join Date
    Mar 2006
    Location
    Srbobran, Serbia
    Posts
    4,084
    Rep Power
    17

    Default

    I have a problem with 4.1.10 to 4.1.10 connection. On 4.1.9.9 I had about 23Mbps throughput last time I tested. NowI have 400ms pings and 1-2Mbps throughput test.

    Both sides are ALIX. I am preparing details to send via mail. If one of you is able to check it before I replace version it would be good.
    Ljubomir Ljubojevic - Love is in the Air
    Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman...
    StarOS and CentOS/RHEL/Linux consultant
    Powerful Starv3 manipulation tool - StarV3 Multipractik for Linux

Similar Threads

  1. GeckoV4 4.1.9.7 build 6556 has been released
    By tony in forum StarOS™ Releases
    Replies: 45
    Last Post: 10-22-2013, 08:49 PM
  2. GeckoV4 4.1.6.1 build 6300 has been released
    By tony in forum StarOS™ Releases
    Replies: 11
    Last Post: 02-08-2013, 09:23 AM
  3. GeckoV4 4.1.6 build 6298 has been released
    By tony in forum StarOS™ Releases
    Replies: 0
    Last Post: 02-06-2013, 09:46 AM
  4. GeckoV4 4.1.5.3 build 6288 has been released
    By tony in forum StarOS™ Releases
    Replies: 17
    Last Post: 02-05-2013, 06:20 PM
  5. GeckoV4 4.1.5.2 build 6286 has been released
    By tony in forum StarOS™ Releases
    Replies: 2
    Last Post: 02-02-2013, 08:04 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts