Can atheros 5.8ghz work over distance of 1.5 mile?

pcatiprodotnet

Would adding this startup shell script also work just as well?

/usr/local/etc/rc.d/my_startup_script.sh
ifconfig ath1 -burst
sysctl dev.ath.1.tpc=1
sysctl dev.ath.1.tpscale=1

I would prefer not to edit system config files unless necessary.
But, if that is required, I'm not sure exactly what to type into
/etc/inc/interfaces.inc function interfaces_wireless_configure

Thanks, -Pete

sullrich

Yes, that will work just fine. You can also utilize <shellcmd>as well from config.xml.</shellcmd>

pcatiprodotnet

Here is my current 5.x interface. Are there any additional commands/flags that could improve it?
I notice odfm is off. In another thread, it was suggested to enable "ofdm on 802.11a"; what command enables this? In the GUI, when I try to turn on odfm for this 5.x 802.11a interface, the wireless card appears to stop functioning.

ifconfig -v ath1

ath1: flags=8843 <up,broadcast,running,simplex,multicast>mtu 1500
inet6 fe80::202:6ffe:fe3f:4357%ath1 prefixlen 64 scopeid 0x3
inet 10.138.1.1 netmask 0xffff0000 broadcast 10.138.255.255
ether 00:02:6f:3e:43:57
media: IEEE 802.11 Wireless Ethernet autoselect mode 11a <adhoc>status: associated
ssid test149 channel 149 (5745) bssid 02:02:6f:3f:43:57
authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF
powersavesleep 100 txpowmax 26 txpower 63 rtsthreshold 2346
mcastrate 1 fragthreshold 2346 -pureg protmode OFF -wme -burst
roaming AUTO bintval 100

sysctl dev.ath.1

dev.ath.1.%desc: Atheros 5212
dev.ath.1.%driver: ath
dev.ath.1.%location: slot=17 function=0
dev.ath.1.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x168c subdevice=0x2063 class=0x020000
dev.ath.1.%parent: pci0
dev.ath.1.smoothing_rate: 95
dev.ath.1.sample_rate: 10
dev.ath.1.countrycode: 0
dev.ath.1.regdomain: 0
dev.ath.1.slottime: 9
dev.ath.1.acktimeout: 48
dev.ath.1.ctstimeout: 48
dev.ath.1.softled: 0
dev.ath.1.ledpin: 0
dev.ath.1.ledon: 0
dev.ath.1.ledidle: 270
dev.ath.1.txantenna: 0
dev.ath.1.rxantenna: 2
dev.ath.1.diversity: 1
dev.ath.1.txintrperiod: 5
dev.ath.1.diag: 0
dev.ath.1.tpscale: 1
dev.ath.1.tpc: 1
dev.ath.1.tpack: 63
dev.ath.1.tpcts: 63
dev.ath.1.monpass: 24

wicontrol ath1

NIC serial number: [ ]
Station name: [ test-10-130-10-1.olsr ]
SSID for IBSS creation: [ test149 ]
Current netname (SSID): [ test149 ]
Desired netname (SSID): [ test149 ]
Current BSSID: [ 02:02:6f:3e:43:57 ]
Channel list: [ 0 0 1110 1111 1 0 0 0 0 2220 22 ]
IBSS channel: [ 149 ]
Current channel: [ 149 ]
Comms quality/signal/noise: [ 0 36 0 ]
Promiscuous mode: [ Off ]
Intersil-Prism2 based card: [ 1 ]
Port type (1=BSS, 3=ad-hoc): [ 0 ]
MAC address: [ 00:02:6f:3e:2d:5c ]
TX rate (selection): [ 0 ]
TX rate (actual speed): [ 36 ]
RTS/CTS handshake threshold: [ 2346 ]
Create IBSS: [ On ]
Access point density: [ 1 ]
Power Mgmt (1=on, 0=off): [ 0 ]
Max sleep time: [ 100 ]
WEP encryption: [ Off ]
TX encryption key: [ 0 ]
Encryption keys: [ ][ ][ ][ ]

Antennas are set to the pfSense default currently (auto tx + receive diversity). Also, on our linksys/openwrt units, devs suggested setting rts=250, but in pfSense trying to set rtsthreshold=250 gives "badvalue" error?
Thank you, -Pete</adhoc></up,broadcast,running,simplex,multicast>

aldo

experiance with long links is plug nearest the middle on cm9 is =2 plug to the edge is =1 so

sysctl dev.ath.0.txantenna=2
sysctl dev.ath.0.rxantenna=2

would be the inner antenna plug on cm9

=0 is for both

lsf

Pete, you settings look fine, nothing seems "wrong".
Just for testing, could you set it up as AP and client ? adhoc mode seems to perform bad compared to client/AP mode. I havent tested it much, but from what others seem to experience, adhoc is not working properly. If you can confirm this, meybe you can work a little with Sam Leffler to figure this out ? Mail some feedback to the freebsd-mobile ML perhaps ?
Only testing I have done with adhoc is olsr in lab, and units have been like 2-5meters apart, and even then performance is not what it should be. So I suspect a driver bug of some sort.

PS. you can set sysctls in sysctl.conf, as for bursting i would just hardcode that in /etc/inc/interfaces.inc or modify the source to add a checkbox for it. All the code you need already exists, just rename some parameter (like copy the intrabss code section and rename the parameter to something like "bursting". You need to do this two places, /etc/inc/interfaces.inc and /usr/local/www/interfaces_wlan.inc. Should be very easy to add this.

aldo

setting the sysctls in sysctl.conf does not hold if you change a setting in the gui of the ath interface maybe this has changed since last we tried it. but this was previous experiance.

ifconfig seems to do something to it.

will test this again today

MAuVE

When a link is not stable and constantly switches modes (say 36-48 Mbps or 48-54Mbps) it is better to lock it to the lowest stable mode instead of leaving it flactuating up and down.
The reason is that the time wasted in negotiating with the other end the higher mode counterbalances any gain from the latter.

The command is :

ifconfig ath_x_ media OFDM/_yz_Mbps (x=0,1,2,…, yz=54, 48, 36,…)

pcatiprodotnet

"ifconfig ath0 -burst" cleared up all of the known issues we had with our existing 2.4 wireless network. Amazing. Thanks aldo!! Also, batching a command such as this to run every so often reducing ping times (interface reset?).
So far, we discovered our 5.x troubles were cause by three contributing factors: poor antenna (the antenna I linked to above has not performed well for us - replaced), bad wireless card (replaced), and imperfect installation cables/attachments/securing/etc (a cable/attachment that works well on 2.4 will not necessarily be good enough for 5.x), new-to-wireless installers, etc.
I really appreciate all the help and great tips!
Thank you,
-Pete

aldo

excellent pleaased to here it i really think there is something wrong with 5.8 Ghz in freebsd in AP mode please be warned
you could waste a lot of time it should be ok with short links and in client mode

lsf

Pigtails, connectors and such are not necessarily working on 5.X even if they work great on 2.4.
A lot of connectors have different specs. Be sure to get wires/connectors/pigtails that are made for operation up to 6ghz, or you might find yourself in all sorts of weird trouble. And if you keep testing with 2.4 antennas on the same cables you might find yourself even more lost ???, since everything seems to perform nicely on 2.4 :-\