Skip to topic | Skip to bottom
Home
SVWUX
SVWUX.ConnectionLogsr1.3 - 28 Jun 2006 - 14:45 - ChrisVergestopic end

Start of topic | Skip to actions

Log of Connection Attempts

27 May 2006 - West Valley College, Saratoga

I found a good spot with a view of the repeater just over the top of some trees:

http://maps.google.com/maps?ll=37.261408,-122.013119&spn=0.006302,0.014355&t=k&om=1

in the south west corner of the parking lot just to the north of the baseball diamond.

Using a 14.5 dB yagi (Hyperlink HG2415Y) and a Linksys WRT54GLv1.1 running OpenWRT WhiteRussian RC5, I was able to associate, obtain a DHCP lease, and maintain a stable connection.

  • Signal/Noise: -64/-83 dBm
  • Ping SVWUX repeater (100 packets): 0% packet loss, round-trip min/avg/max = 2.8/4.7/21.8 ms
  • Ping Steinway (100 packets): 5% packet loss, round-trip min/avg/max = 4.8/40.6/290.4 ms

I should note that I had not set the distance setting (wl0_distance=32168) on this particular AP. In the future I will collect statistics with and without the distance setting applied. I will also try various transmit power levels as Brian suggested.

-- TimUtschig

29 April 2006 - San Jose OES

Ian Kluft and Chris Verges used a 21 dB parabolic dish antenna connected to a Linksys WRT54G (OpenWRT whiterussian rc5). We were able to see the ESSID coming from the SVWUX 802.11b/g access point, but were not able to associate to the access point.

Summary of discussions:

  • Standard 802.11b/g defines RTS/CTS timers that restrict the operational range to less than 5 miles. 802.11 equipment that works over longer distances redefines the RTS/CTS timers.
    • Can we redefine the timers on the SVWUX repeater (a Linksys WRT54G running OpenWRT)?
    • If not, can we add a wireless bridge to the SVWUX repeater site that handles the proper RTS/CTS for long-range wireless shots?
  • Supporting multiple protocols (802.11a, 802.11b/g, 802.11n, 802.16) would prove beneficial as a long-term goal of the group in bringing together all manner of users.
  • San Jose R.A.C.E.S. needs a way to define preferential traffic in the event of an emergency situation. One possible solution discussed includes the following components:
    • Multiple ESSIDs, each ESSID associated to a separate VLAN
    • Quality of Service (QoS) defined for each ESSID/VLAN.
      • Highest QoS value (7) reserved for system management
      • Next three highest QoS values reserved for emergency operations (6 = medical, 5 = fire/police, 4 = all other emergency traffic).
      • All other QoS values can be defined as different service levels for non-emergency traffic (3 = voice, 2 = interactive sessions, etc.)

to top

You are here: SVWUX > WebLeftBar > ConnectionLogs

to top

Copyright © 1999-2008 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding SVWUX? Send feedback