AirOS V3.5-RC - PPPoE Fix + More

[UBNT-Mike.Ford]

Hey Guys,

Releasing the new V3.5-RC to you guys. This is to fix the PPPoE lockups.

Thanks,

http://www.ubnt.com/downloads/XS-rc/v3.5-rc/XS5.ar2313.v3.5-rc.4448.090910.1715.bin (http://www.ubnt.com/downloads/XS-rc/v3.5-rc/XS5.ar2313.v3.5-rc.4448.090910.1715.bin)

http://www.ubnt.com/downloads/XS-rc/v3.5-rc/XS2.ar2316.v3.5-rc.4448.090910.1708.bin (http://www.ubnt.com/downloads/XS-rc/v3.5-rc/XS2.ar2316.v3.5-rc.4448.090910.1708.bin)

Version 3.5-rc (09/11/2009)
---------------------------
- fixed: PPPoE client locks up.
- fixed: PPPoE client can't authenticate if in username symbol # is used.
- fixed: Traffic shaping is not working. Can't add shaping rules.
- fixed: VLAN QoS to WMM mapping.
- fixed: Traffic shaper is expected to honor packet priority.
- fixed: WEP entry field validation error message on Web UI.
- fixed: problem with AP channel when in some circumstances (after reboot/softrestart) it might get different from config value
- improvement: STA-Bridge multiple IP and VLAN per MAC.
- improvement: Set pppoe maxfail to 0 by default.
- added: Ethernet port MTU value can be set manually up to 1692 bytes (Long packet support (>1500bytes)).
- added: 152bit (128bit key + 24bit IV) WEP support in Web UI and config.

[jonesy]

- added: Ethernet port MTU value can be set manually up to 1692 bytes (Long packet support (>1500bytes)).
That's fantastic! I thought that the limitation to 1500 bytes was due to the hardware?

[jonesy]

Hrmm... I've just installed this firmware on a bullet5, and while it will allow me to to increase the ip mtu of eth0, the ethernet port will still not pass packets which are larger than 1500 bytes.

This is my laptop (ethernet MTU set to 1550) trying to ping the bullet5 (eth0 MTU set to 1550) eth0 is _not_ part of a bridge. There is an ethernet cable directly between my laptop and the bullet5.
root@kif:~# ping 192.168.0.20 -s 1472
PING 192.168.0.20 (192.168.0.20) 1472(1500) bytes of data.
1480 bytes from 192.168.0.20: icmp_seq=1 ttl=64 time=0.860 ms
1480 bytes from 192.168.0.20: icmp_seq=2 ttl=64 time=0.833 ms
^C
--- 192.168.0.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.833/0.846/0.860/0.032 ms
root@kif:~# ping 192.168.0.20 -s 1474
PING 192.168.0.20 (192.168.0.20) 1474(1502) bytes of data.
^C
--- 192.168.0.20 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1006ms

On the bullet I see input errors on the ethernet port:

eth0 Link encap:Ethernet HWaddr 00:15:6D:D3:8F:25
inet addr:192.168.0.20 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1550 Metric:1
RX packets:1325 errors:241 dropped:241 overruns:0 frame:0
TX packets:543 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:157346 (153.6 KiB) TX bytes:208362 (203.4 KiB)
Interrupt:4 Base address:0x1000

[skyhook]

- fixed: VLAN QoS to WMM mapping.

More on this...

[doush]

because of PPPoE lock up issues, we may need to upgrade more than 150 NS5 clients.

Is there a way to automatically do it ?

[jonesy]

I just heard back from ubiquiti support, the MTU fix is in a slightly later build.
I'm looking forward to being able to pass full 1500-byte packets plus VLAN tags and MPLS labels :)

[UBNT-Zy]

Hello Skyhook,

WMM priority is set according to the L2 (VLAN priority) and L3 (TOS DSCP) bits.

L2 scheme is:

0 (default), 3 goes to Best Effort queue
1, 2 goes to Background queue
4, 5 goes to Video queue
remaining goes to Voice queue


Jonesy,

I've sent you the details on support tracker channel regarding the large MTU issue.

[jonesy]

Thanks Zydrunas,
I just replied back to you, you sent me the xs2 binary rather than xs5, would you please send me the xs5 version?
Thanks!
Andrew

[jonesy]

because of PPPoE lock up issues, we may need to upgrade more than 150 NS5 clients.

Is there a way to automatically do it ?
You could write some scripts to do it, using perl or php to connect to the web interface and upgrade each one... check out this site for some ideas http://dren.dk/ubi

[UBNT-Zy]

Hello doush,

you can use scp for FW image upgrade and fwupdate command afterwards, like:

scp ./XS5.ar2313.v3.5-rc.4450.090916.1437.bin ubnt@192.168.1.20:/tmp/fwupdate.bin
fwupdate -c (optional - checks firmware file)
fwupdate -m

[skyhook]

Hello doush,

you can use scp for FW image upgrade and fwupdate command afterwards, like:

scp ./XS5.ar2313.v3.5-rc.4450.090916.1437.bin ubnt@192.168.1.20:/tmp/fwupdate.bin
fwupdate -c (optional - checks firmware file)
fwupdate -m

Hi Zy,

can you help us to write a script to update many devices efrom a text file (IP, user, pwd)?

[jonesy]

Thanks for the help Zy! Large packets pass through the bullet I tested on fine since upgrading to build 4450.

[bluestu]

Where is the dynamic routing we were promised? Im getting sick of Ubiquiti's half baked products. Last chance before I move all our equipment and CPE's to another vendor.

I'm furious!!

[HKFUN2K7]

link to latest build rc 3.5 4450 anyone pls?or later build.thnx

[mdzidic]

because of PPPoE lock up issues, we may need to upgrade more than 150 NS5 clients.

Is there a way to automatically do it ?

At first You must enable SSH on all Your CPEs...
On You Linux/Unix machine You need package SCP
Also You need to generate ssh public keys (check: http://support.svi.nl/wiki/ScpBatchMode )

After that try this bash script...

ip.txt
XXX.XXX.XXX.XXX
YYYY.YYY.YYY.YYY
XXX.XXX.XXX.XXX
YYYY.YYY.YYY.YYY
XXX.XXX.XXX.XXX
YYYY.YYY.YYY.YYY

ubnt.sh
#!/bin/bash

FIRMWARE=$1
USER=$2

N=0
cat ./ip.txt | while read LINE ; do
N=$((N+1))
scp ./$FIRMWARE $USER@$LINE:/tmp/fwupdate.bin
ssh $USER@$LINE
fwupdate -c
fwupdate -m
exit
done

usage: sh ubnt.sh fw-filename.bin username

[900mhzdude]

Radius support in 3.5??? Please!

[Redstone]

I'm still waiting for the PEAP support in AirOS....

[UBNT-Mike.Ford]

Where is the dynamic routing we were promised? Im getting sick of Ubiquiti's half baked products. Last chance before I move all our equipment and CPE's to another vendor.

I'm furious!!


Hello,

This is not coming any time soon, I do apologize. At the current time our products work just fine for the majority of user's around the world. Dynamic routing has been one of our least requested features so other features take priority. It is on the roadmap, but do not have an estimated time frame for relaese. Also the majority of routing can be handled on the backend at your NOC with proper network planning.

Thanks,

Thanks,

[dubelt]

How about adding standard futures that UBNT team had forgotten at the beginning?

uPnP and static dhcp leases


the pppoe works fine for me, the "team" should read sometimes the "requests futures" threads. first request posts are from 2008 year !!!
why is it so hard for UBNT developers to make standard build in kernel futures usable?

[dadaniel]

Where can we get the corrected image?

[crisman]

can you add pppoe-relay in default firmware please? Actually there is an error and the package rp-pppoe is not compiled using the sdk. Please fix it.

[rconaway]

3.5 has a problem with the ACK settings. Out of 4 radios I upgraded that were working fine, the ACK settings jumped to 372 after upgraded on 2 of them. I can make a change, they seem fine, a couple hours later, they are on 372 again. Ping times seem to be okay so that number may be bogus.

Here is a feature request. Add in an algorithm that compares power output to CCQ%. If the CCQ% goes down, the power goes up, and vice versa, until the CCQ% hits 100%. If the CCQ% doesn't hit 100%, then adjust the ACK, and keep going until you find the best values. I"ve over simplified it but the basic concept it there.

[agsweeney]

3.5 has a problem with the ACK settings. Out of 4 radios I upgraded that were working fine, the ACK settings jumped to 372 after upgraded on 2 of them. I can make a change, they seem fine, a couple hours later, they are on 372 again. Ping times seem to be okay so that number may be bogus.

Here is a feature request. Add in an algorithm that compares power output to CCQ%. If the CCQ% goes down, the power goes up, and vice versa, until the CCQ% hits 100%. If the CCQ% doesn't hit 100%, then adjust the ACK, and keep going until you find the best values. I"ve over simplified it but the basic concept it there.

I have seen one of my CPE's with 3.4 go as high as 757 with AutoAck @ under 2 miles, while behaving fine for the client. There is an apple tree in the LOS. With 3.5-Release, I have not see this yet; it is currently @67 but the apples are falling off the tree.

In regards to your Feature Request; let me take this off topic and say that I had given a similar idea some thought a few weeks ago. It needs to be tied to the Obey REG power (which I've commented needs an overhaul), which means that on EXT antenna setups we need to be able to input the gain on the EXT antenna (yes, I will continue to harp on this point).

Only transmitting the required power necessary to maintain a stable link and remaining Legal at the same time... Kind of like TPC with a twist.

This "Idealistic Output Power Control" would also serve to reduce the noise generated by the link as it would not overrun beyond what is actually needed for the link.

Now if you could also add the ability for an AP to automatically find the best channel (from a list of channels you want to use, based on your antenna Freq specs and reg domain) and set itself up there.....

[bobcopro]

I haven't seen it mentioned yet - download the new airControl software from the UBNT forum and you can monitor and upgrade the firmware on many units at the same time. Nice beta software introduced at the Chicago conference.

[internetsaco]

do the wmm setting equal 0xb8 for priority for both sip and rtp voice value do you have wich value are set to get recognized as high priority packet?

either dscp or tos...


thx

[internetsaco]

Sorry for mispelling what are the value that are identified as high priority packet for the voice? is it TOS or DCSP for layer 3. What are the packet marker 0xb8

should i use vlan at layer 2 for tagging packet? is it better?
And my other question on the AP (nano). Is it better to set to auto?

Im in need of little documentation to better understand how the wmm setting work with ubiquity stock can anyone provide me with little info?

[internetsaco]

where are the qos expert is there any with this forum how know something about the way airos process layer 2 layer 3 qos ????

im beginning to get scared please post something

[ve7ka]

I'm still waiting for the PEAP support in AirOS....

Here here!

I have been waiting for over a YEAR! Ubiquity is ignoring us on this one. Its about an hours work for their developers too...

Come on guys, the university I work for is waiting for this functionality so we can do RADIUS assigned VLAN's via the bullets. In fact we have about 4 bullets sitting here waiting for this.

Thanks

[chickenlittle]

can you add pppoe-relay in default firmware please? Actually there is an error and the package rp-pppoe is not compiled using the sdk. Please fix it.

same problem seems to exist in the 3.5 release.. if needed i could provide a workaround..

[DasI]

3.5 has a problem with the ACK settings. Out of 4 radios I upgraded that were working fine, the ACK settings jumped to 372 after upgraded on 2 of them. I can make a change, they seem fine, a couple hours later, they are on 372 again. Ping times seem to be okay so that number may be bogus.

Here is a feature request. Add in an algorithm that compares power output to CCQ%. If the CCQ% goes down, the power goes up, and vice versa, until the CCQ% hits 100%. If the CCQ% doesn't hit 100%, then adjust the ACK, and keep going until you find the best values. I"ve over simplified it but the basic concept it there.
ACK timeout or ACK distance is distance function which directly depends on "speed of light" constant. Setting ACK value to low is much worse than setting ACK to high. On a good link you won't notice too high ACK value impact at all. On poor link you can notice some throughput loss, but anyway link will be still usable. The CCQ or some other quality assumption, error, retries rates and etc. won't lead to correct auto ACK algorithm. To have correct Auto ACK algorithm you need to measure time(in microseconds) between packet TX and it's ACK RX... Anyway without hardware support Auto ACK algorithm will always have worse performance than correct static ACK value. This because ANY auto ACK algorithm will need to do periodic updates and the throughput will drop slightly during these updates. So the best solution is to use Static ACK value for STATIC PtP link.

can you add pppoe-relay in default firmware please? Actually there is an error and the package rp-pppoe is not compiled using the sdk. Please fix it.
It seems that rp-pppoe package included but never used. The pppd package goes together with pppoe plugin integrated(which is actually some older/stable rp-pppoe version). So if you need pppoe-relay functionaly, try modifying and/or over-configuring pppd version of pppoe plugin, or replace it with newest rp-pppoe version. Btw. after this post there is a chance that rp-pppoe will be removed from SDK :)