"iw wlan0 station dump" returns "beacon interval:100" on:
node_details
firmware_version "3.18.9.0"
board_id "0xe2d2"
firmware_mfg "AREDN"
model "Bullet M2 Titanium HP "
Has AREDN abandoned the 500ms beacons in 2 GHz devices in the current firmware?
We have 13 nodes (and growing) on 2397 MHz and am wondering if 5x more beacons
may have increased channel congestion.
Chuck nc8q
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
https://github.com/aredn/aredn_ar71xx/blob/develop/files/etc/config.mesh...
see "beacon_int" definition here:
https://openwrt.org/docs/guide-user/network/wifi/basic?s[]=beacon&s[]=int
Check the live node to see what this config param is at "/etc/config/wireless".
Sometimes "iw" does not report correct data, e.g. it will report rates for a 20Mhz channel width, and has to be manually translated if using 10Mhz. A packet capture can show the beacons to confirm what is actually being transmitted.
Joe AE6XE
root@KE8MVM-W-Xenia-Omni:~# cat /etc/config/wireless
config wifi-device radio0
option type mac80211
option channel -2
option chanbw 10
option distance 23000
option country HX
option htmode HT20
option beacon_int 500
option path 'pci0000:00/0000:00:00.0'
config wifi-iface
option device radio0
option network wifi
option mode adhoc
option ssid "AREDN-10-v3"
option encryption none
config wifi-iface
option device radio0
option network wifi_mon
option mode monitor
root@KE8MVM-W-Xenia-Omni:~#
Joe: Thanks. Chuck
What you may be seeing is due to the history of this 802.11 adhoc network. This is from memory, so hopefully I am remembering this correctly... In order for an RF link to change the beacon rate, with 2 or more nodes on the channel, then all of them have to be offline at a given point in time. Suppose that we started on a link with 100ms beacon rates, when a new node joins an existing adhoc network, it will inherit parameters from the oldest 'adhoc' network, e.g. the BSSID, beacon rate, probably more.
You can see the adhoc network identifier or BSSID or Basic Service Set ID showing in wifi scan -- there will be a row specific for the adhoc network you are joined to, and does not represent a mesh node. If there are other adhoc networks (different SSID), then you will see 'foreign adhoc network' and not any of the nodes in that network (have to join to find out).
This adhoc network information and settings don't go away as long as one node stays live at all times for a given adhoc network. When a node goes to join with another, the parameters of the one with the oldest time stamp wins.
...try power cycling all the nodes on this link all at the same time, then check what iw beacon interval shows.
Joe AE6XE
http://web.cse.ohio-state.edu/~lai.1/papers/mobihoc-02.pdf
Context of paper is the 802.11 1999 edition spec and in concluding remakes say the results also applies to 802.11b (used in AREDN only on 2GHz and 900MHz devices). 802.11n on 5GHz, 3GHzand 2GHz, 900MHz should follow suit to be compatible as 'b' and 'n' could be used at the same time.
This is the significant step in beacon handling:
" 3. If a beacon arrives before the random delay timer has expired, the station cancels the pending beacon transmission and the remaining random delay."
There is a "beacon generation window". If a node doesn't get the beacon out in this timeframe, it cancels it. The network could not be saturated by beacons. It is limited and has to be transmitted within the assigned window of time. We'd need to calculate this beacon window to see what max % of time on the channel it could consume.
Joe AE6XE
In this paper:
--------------------------------
According to the IEEE 802.11 specifications [4] ... Each station in an IBSS shall adopt the timing received from any beacon that has a TSF time value (the timestamp) later than its own TSF timer. All stations in the IBSS adopt a common value, aBeaconPeriod, that defines the length of beacon intervals or periods. This value, established by the station that initiates the IBSS, defines a series of Target Beacon Transmission Times (TBTTs) exactly aBeaconPeriod time units apart. Time zero is defined to be a TBTT.
Beacon generation in an IBSS is distributed; all stations in the IBSS participate in the process as follows.
Beacon Generation and Clock Synchronization:
1. At each TBTT each station calculates a random delay uniformly distributed in the range between zero and 2*aCWmin*aSlotTime. (The aCWmin and aSlotTime parameters are specified in Table 1.)
2. The station waits for the period of the random delay.
3. If a beacon arrives before the random delay timer has expired, the station cancels the pending beacon transmission and the remaining random d
4. When the random delay timer expires, the station transmits a beacon with a timestamp equal to the value of the station’s TSF timer1 .
5. Upon receiving a beacon, a station sets its TSF timer to the timestamp of the beacon if the value of the timestamp is later than the station’s TSF timer2 . (It is important to note that clocks only move forward and never backward.)
-----------------------------------
Hi, Joe:
Wow! Gotta read that response a few more times.
Thanks for the document links.
Now, these IBSS beacons, are they the ones used to determine LQ?
Chuck
Got it:
I see the 'My Ad-Hoc Network'.
"try power cycling all the nodes on this link all at the same time, then check what iw beacon interval shows."
Power cycle 13 nodes at the same time. Oh, My!
Maybe some day. OTOH, I bought a mega-millions lottery ticket today.
Chuck
If I'm reading this right, the amount of bandwidth consumed by beacons for a given interval would always be exactly the same no matter how many nodes there were.
Joe AE6XE
Hi, Darryl:
Ooopps, from time to time, yes. They are not RF connected to the device I tested,
It was a neighbor's "Bullet Titanium" I tested. I did not mention which neighbor node I tested.
I need to revisit some of my neighbor's Bullets and repeat this test with better documentation.
Thanks, Chuck