I was pointing out that we do not have a setting in the BBHN GUI for changing the network port speed settings to lock them down, instead we stick with letting the device choose under Ethernet autonegotiation protocol (often cited as addendum 802.3u but now bundled into the official 802.3 spec's)

When you hard code the speed on a device it (usually) disables autonegotiation of speed and duplex on that link

Cisco confirms this is the case:

http://www.cisco.com/c/en/us/support/docs/lan-switching/ethernet/10561-3.html

"If you want to hard code the speed and duplex on a switch that runs Cisco IOS Software (turn off auto-negotiation), issue the speed and duplex commands underneath the specific interface. Duplex is subservient to speed in the sense that if speed is set to auto, then the duplex cannot be manually set."

The Usual fallback I've seen in the 10/100 world was 10/Half (though I've sen some smart drivers upgrade the link to 100/half if they see 100mbhs traffic)

When you get into gigabit it gets even stricter it seems (quoting same article)

"By default, all devices are supposed to perform autonegotiation. 802.3z does not specifically define a way to turn Autonegotiation off, for both 1GigabitEthernet and 10GigabitEthernet."

You could hard program the speed into the back-end of the BBHN device  and the operating system will honor it,  its just we don't expose a hard interface config setting via the GUI (at this time).

Same Article:

"Cisco recommends to leave auto-negotiation on for those devices compliant with 802.3u."

Though despite that recommendation , like you, I have had portions of my network where I have hard coded link data. Though I have also have portions where I have hard coded, and it actually mucks things up (I had a buggy version of VMWARE ESX at one time that had issues where the interfaces woudl periodically reset itself to half duplex unless you left autonegotiation in place as one example)

So yes we will fully support 100mbps on 100mbps devices, its just we tend to let autonegotiation set the link speed rather then exposing a GUI setting where mistakes can be made.

I concur with Joe.  Looks like as we expect that the power is split between the two ports.  On 2.4ghz it shows a roll off one could expect of a 2.4ghz wifi amp that as you get out of band it falls off. It also shows that calibration data likely isn't used on the test out of band as it's allowed to excite higher.

Re: the link on code: yep that is what I thought it would take (it's nice to have the confirmation) the page in question doesn't on first look to have taken into account cal data so without a spectrum analyzer specced to deal with wifi we wouldn't know if it's stable.  I don't have access to one above 1ghz so I'm out on that regard. In the post it looks like what was done was to repurpose an existing RF channel's cal data without any knowledge as to how accurate it is.  This may work in the same room but over 5 miles may fail. Not sure what those graphs were generated from, if it was a proper spec analyzer then it does overall look good but I suspect it was made from a wifi device which means we can't really trust it reliable to show the actual signal quality.

I can't look at the zip though to be sure that is actually what they did from my phone so will have to check later.

Good catch on the link, it never came up when I was looking so is news to me.

Maybe I'm a bit paranoid, but if I am going to put a commit in to the base I have to feel comfortable we are not going to get anyone in trouble or break any hardware.  As noted if someone's got the gear we can test it with and the dev skill to run with it (I got a dozen other tickets open at the moment ) I'm all for it eventually making it into the build.

Glad it is working when in trunk mode.

Jist a note for anyone else who may come across the config in the future:

The hard coding of the speed and duplex is not handled in our default BBHN builds.  While this config may work for a LAN a potential for collisions is possible as the network card aboard the Ubiquiti should fall back to 10mbps/half duplex.

Let me clarify one thing. I set the vlan on the switch ports used by the UBNT devices to access mode and to vlan 2. no trunk mode. Without anything coming up in search engine on the page I knew from earlier research that the dtdlink was vlan2. So that's all I setup.

I didn't see a need for any other vlans, let alone a trunk. Hind site all my wireless AP's at work are all on trunk ports. Last weekend I was testing 1.1.2 and 3.0.0 and then I was testing 3.0.0b2 .The idea was to simulate a three sector tower setup. I had a total of Five M5's. Three to form the ring ( three 120 degree sectors ) and two out on perimeters to act as clients. I set the switch ports to access mode on vlan 2 and I could see the traffic and pass traffic between the nodes on what I'm designating RING 0.

Then earlier this week with an M2 running 1.1.2 and it worked. I upgraded the M2 to the 3.0.0 The same switch config but only a single M5 and the M2. no go it was all broke. upgraded to 3.0.0b2 and same scenario. I went over everything that I did, notes, drawings, configs. I had been monitoring with Wireshark the whole time this was taking place.

Earlier in the week I saw the traffic Now since i went back to my original three M5's as ring 0 and running 1.1.2 its all working again. ?????? Step 2 . This evening. I upgraded back to 3.0.0b2 on all nodes with just VLAN2 and it didn't work. This proved something had changed. Step 3 . I set all UBNT device ports to trunk mode with vlan 10 native allowing 1,2,& 10 on the trunk. Everything is working. I can pass traffic both to and from 2.4 & 5.8 and from one band to the other. The confusion only came in when I simplified my setup and used a single M5 & M2. I could see the DTDLink traffic with the three M5 on the original testing last weekend. Its all working now. Thank you

=========

Switch configuration

This configuration was done for a three sector array with two backbone nodes setup to pass traffic from This site to the next.

This assumed you have a console cable connected to a computer and that there is no configuration on the switch. The switch has had a Factory reset preformed. All commands were done on a Cisco 2950 switch running 12.3 code. This may or may not work with other versions of code.

1. First we setup the VLANs and second the ports that need these vlan's
   
2.  Cisco 2950 running 12.3 code connect using a console cable. 8N1 / 9600
   
3. 
   
4. #Setup the vlan database:
   
5. switch>enable
   
6. switch#
   
7. switch#config t
   
8. switch(config)#
   
9. switch(config)#vlan 10
   
10. switch(config-vlan)#name BBHN
    
11. switch(config-vlan)#no shutdown
    
12. switch(config-vlan)#exit
    
13. switch(config)#vlan 2
    
14. switch(config-vlan)#name DTDLINK
    
15. switch(config-vlan)#no shutdown
    
16. switch(config-vlan)#exit
    
17. switch(config)#exit
    
18. 
    
19. switch# show vlan
    
20.  VLAN   NAME  STATUS
    
21.      1 default    active
    
22.      2 DTDLINK active
    
23.    10 BBHN      active
    
24. 
    
25. switch# config t
    
26. switch(config)#interface range Fa0/1 - 3 << Program up all three ports at once
    
27. switch(config-if-range)#Description BBHN Sector Array XX
    
28. switch(config-if-range)#switchport mode trunk
    
29. switch(config-if-range)#switchport trunk allowed vlan 2,10
    
30. switch(config-if-range)#switchport trunk native vlan 10
    
31. switch(config-if-range)#speed 100
    
32. switch(config-if-range)#duplex full
    
33. switch(config-if-range)#no shutdown
    
34. switch(config-if-range)#exit
    
35. 
    
36. switch(config)#interface range Fa0/4 - 5 << Program up two backbone link ports at once
    
37. switch(config-if-range)#Description Link to site XX
    
38. switch(config-if-range)#switchport mode trunk
    
39. switch(config-if-range)#switchport trunk allowed vlan 2,10
    
40. switch(config-if-range)#switchport trunk native vlan 10
    
41. switch(config-if-range)#speed 100
    
42. switch(config-if-range)#duplex full
    
43. switch(config-if-range)#no shutdown
    
44. switch(config-if-range)#exit
    
45. switch(config)# interface fa0/6
    
46. switch(config-if)#Description TestPortUseOnly 
    
47. switch(config-if)#switchport mode access
    
48. switch(config-if)#switchport access vlan 10
    
49. switch(config-if)#switchport speed 100
    
50. switch(config-if)#switchport duplex full
    
51. switch(config-if)#switchport spanning-tree portfast
    
52. switch(config-if)#no shutdown
    
53. switch(config-if)#exit
    
54. switch(config)#exit
    
55. 
    
56. switch# copy run start << Copy the running configuration to the startup configuration
    
57. 
    
58. switch#show interface trunk
    
59. 
    
60. Port Mode encapsulation Status Native Vlan
    
61. Fa0/1 on 802.1q Trunking 10
    
62. Fa0/2 on 802.1q Trunking 10
    
63. Fa0/3 on 802.1q Trunking 10
    
64. Fa0/4 on 802.1q Trunking 10
    
65. Fa0/5 on 802.1q Trunking 10
    
66. Port Vlans Allowed
    
67. Fa0/1 2,10
    
68. Fa0/2 2,10
    
69. Fa0/3 2,10
    
70. Fa0/4 2,10
    
71. Fa0/5 2,10

Also interesting, and a bit over my head presently, but may be of interest to developers: Using WiFi Atheros chips in hamradio bands:

http://yo3iiu.ro/blog/?p=1301

What happens if you plug them in directly to each other bypassing the switch?

Nothing changed between 1.1.2 and 3.0.0* on the Ubiquiti side for DTDLINK (though the upper level protocol did change) 

The fact it worked on 1.1.2 without configuration is a mystery to me unless Cisco has added some auto route vlan feature since I was last around.

You should be able to verify this with a wireshark directly to the node seeing a dot1q tagged vlan which the switch should honor and then flood out the rest of the ports (as a dot1q tagged vlan -- hence the need for trunk mode). If it doesn't have the tag then something is wrong or if the switch strips the tag the nodes won't be able to see the packet.

Just to verify all devices are running 3.0.0b02 correct  when testing the 3.0 dtdlink right ?

Hi Matt,

the member support never materialized with the YRARC group, though we do still use Mesh in our Emergency Prepardness.

I believe the two folks you reference had/have mesh gear, but don't know if they're still online...or what firmware they're running  

contact me offline and I'll put you in touch.

i can do the propagation path checks too.

va3srv

Not ment to be a slam just asking the webmaster to tag it for us.

The site search doesn't search the forum so that limits the ability.  I only could find it because I knew for see it existed and used google search. It's one item that the webmaster should be fixing in a future site upgrade.

Not sure why it would of worked on 1.1.2 vs 3.0.0 as we made no changes to Ubiquiti on dtdlink (we did disable it on Linksys )   It's always been a dot1q tagged vlan port. 

And the guide I sent is just an example, I haven't owned a new cisco switch in a while I've been using different gear because of work.

Hi "neighbor". I travel to Vinings for work quite often (but dont bring a node with me usually). ;-(

I'm off Overlook Pkwy.

I'm here this week, but, leaving today.

Be back in 2 wks. K5DLQ - Darryl

I have been wondering about this: Channel Power vs Frequency for Ubiquiti devices

http://interline.pl/Tests-and-comparisons/Channel-Power-vs-Frequency-Ubiquiti-devices