Wireless Access

Hello all,

We are a Spanish university that uses Alcatel wifi equipment.
But Alcatel is an OEM of Aruba and we have always one eye on Alcatel and other eye on Aruba.

We have sent this issue to Alcatel support but I think it could be useful for all Aruba users.

We have AP70 and AP105 and we are using WPA-TKIP and WPA2-AES simultaneously.

Weeks ago, our end users support center told us there were some n phones that didn't navigate.
The phones CONNECT ALWAYS RIGHT but in some places they surf right by web and in other places they can't.

We discovered soon that the problem was the n APs.

We made some test with a test SSID and we found this behavior.
.-n SSID with AES encryption only. The client connects on n but the navigation doesn't work. The packet forwarding is very very slow. (See note below)
.-n SSID with TKIP encryption only. The client connects on b/g no n and the navigation work.
.-n SSID  and open or no encryption. The client connects on n and it navigates.
.-no n SSID. The encryption doesn't mind. It works always well.

These n phones work well at home n wifis.

Note: The most curious thing here in our wifi is that the n phones connected to n and AES suffer a big delay in DNS, WEB and almost any protocol, but not in ping. Any ping on the phone using IP number instead of IP name, never fails.

Equipment and versions

OAW-4650 (Aruba 7220 controller)
Alcatel/AOS 6.3.0.1
AP-70 and AP-105
HTC Desire C Android 4.0.3
HTC Desire 500 Android 4.1.2

Sony, Samsung, Iphone, etc. don't suffer this issue.

I suspect all n HTC phones are affected.

Now, you are advised.
And if you know a workaround or solution, please, tell me.

Nicolas

Universidad Autonoma de Madrid

Are you using 802.1x?

Yes. This is our major access system.
We are in eduroam initiative.

The "unusual" access system is PSK.
But the problem is the same for both.

Thanks

From the description, I understand we have an issue with HTC phones using Android unable to navigate to WEB and lot of delay in http/https and DNS quereis however ping always works fine. 

1.  Are we using the external (Public) DNS server ?
2.  Do we have this issue only with Android device and IOS or laptops working fine?
3.  Is the DHCP server configured on the controller ?
4.  Do we see any traffic from show datapath session table ?

Thank you

1.-Yes, we are using our campus DNS server in our wifi network.
2.-As long as we can test, yes. Any other device works fine. There isn't any other device, including those that are far from an AP, for which web navigation it's so difficult. We have used test AP105 twenty cms near HTC phone andthe navigation is almost blocked. For any type of user, end or technical, navigation is almost useless.
3.-Yes, it is. DHCP is served by the controller.
4.-We'll check it asap and I'll replay an answer.

We are very sure about the n HTC phones because these are the phones our mobile operator (Vodafone) send us for corporate users.We have now around 20 HTC Desire 500 and all of them shows the problem.
Our end users support center talked us about navigate problems with ALL HTC phones they configured for corporate users in "some" places.
Later we discovered these places are AP105.

Thanks

 

When we say campus DNS servers; are they going to be public servers? Please confirm.

From your description, I understand DHCP server is on the controller. Can we try connecting the HTC phones to connect to different vlan on the controller where DHCP server is hosted and gateway is hosted outside to see if that behaves differently ?

Thank you.

Yes it is. DNS server for wifi clients and for controllers is our public DNS server.

I don't understand very well the second question.

Do you want we use an external DHCP server not hosted by the controllers?

It can be done because we have another DHCP server for non-wifi equipment.

But, I don't understand what are we looking for.

The credentials exchange and DHCP leasing works right always.

With our previous controllers, DHCP server used was the external server and always was fine.

Anyway, we'll try it.

Maybe tomorrow I'll post the results for the tests you ask for.

Thanks

Hello,

I send a file with sh datapath results attached.

The tests using a different vlan and an external dhcp server is more diffcult than I said.

Our wired equipment and firewall fellows are involved in other urgent work these days.

Sorry.

I hope next week ....

The Alcatel tech support ask us more data also.

Anyway, thank you Aruba guys.

And, please, if anybody suffers the same problem with any kind of n phones, please, tell us.

Nicolas

Attachment(s)

DATAPATH.txt   29 KB 1 version

---

@nvelaz03 wrote:

Hello,

 

I send a file with sh datapath results attached.

 

The tests using a different vlan and an external dhcp server is more diffcult than I said.

Our wired equipment and firewall fellows are involved in other urgent work these days.

Sorry.

I hope next week ....

 

The Alcatel tech support ask us more data also.

 

Anyway, thank you Aruba guys.

 

And, please, if anybody suffers the same problem with any kind of n phones, please, tell us.

 

Nicolas

 

---

Question,

Why is DNS being given high priority?  Are you putting ALL traffic in the High Queue (the H flag)?

show datapath session table 172.16.226.23


Datapath Session Table Entries
------------------------------

Flags: F - fast age, S - src NAT, N - dest NAT
       D - deny, R - redirect, Y - no syn
       H - high prio, P - set prio, T - set ToS
       C - client, M - mirror, V - VOIP
       Q - Real-Time Quality analysis
       I - Deep inspect, U - Locally destined
       E - Media Deep Inspect, G - media signal

  Source IP     Destination IP  Prot SPort DPort  Cntr Prio ToS Age Destination TAge Packets   Bytes      Flags 
--------------  --------------  ---- ----- -----  ---- ---- --- --- ----------- ---- --------- ---------  -----
150.244.9.100   172.16.226.23   17   53    46876  1/3     7 0   1   tunnel 296  21   0         0          FHPI 
150.244.9.200   172.16.226.23   17   53    44901  1/3     7 0   1   tunnel 296  1d   0         0          FHPI 
172.16.226.23   150.244.9.100   17   46876 53     1/3     7 0   1   tunnel 296  21   0         0          FHPCI 
150.244.9.100   172.16.226.23   17   53    36929  1/3     7 0   1   tunnel 296  20   0         0          FHPI 
172.16.226.23   173.194.66.188  6    56539 5228   1/3     0 0   8   tunnel 296  95   0         0          C 
172.16.226.23   150.244.9.200   17   57864 53     1/3     7 0   0   tunnel 296  3    1         61         FHPCI 
172.16.226.23   150.244.9.200   17   44243 53     1/3     7 0   1   tunnel 296  1e   0         0          FHPCI 
172.16.226.23   150.244.9.100   17   27984 53     1/3     7 0   1   tunnel 296  6    1         61         FHPCI 
150.244.9.100   172.16.226.23   17   53    27984  1/3     7 0   1   tunnel 296  6    1         496        FHPI 
172.16.226.23   150.244.9.100   17   20657 53     1/3     7 0   1   tunnel 296  1c   0         0          FHPCI 

Hello

Maybe we made some priorities in the config to some traffics time ago for other problems.

Months ago we had another very old controllers and the config is very similar for the new controllers.

But, is this a question related with the problem described above?

Of course, we want to solve the problem. But we want to understand how these config questions (priority or DHCP) can crash or solve our n HTC phones connected with AES encryption.

I don't understand why these questions break n/AES but doesn't mind for g/TKIP or n/noencryption.

And, overall, thank very very very much, Cjoseph and Sriram.

Regards,

  Nicolas

---

@nvelaz03 wrote:

Hello

 

Maybe we made some priorities in the config to some traffics time ago for other problems.

Months ago we had another very old controllers and the config is very similar for the new controllers.

 

But, is this a question related with the problem described above?

Of course, we want to solve the problem. But we want to understand how these config questions (priority or DHCP) can crash or solve our n HTC phones connected with AES encryption.

I don't understand why these questions break n/AES but doesn't mind for g/TKIP or n/noencryption.

 

And, overall, thank very very very much, Cjoseph and Sriram.

 

Regards,

 

  Nicolas

---

I don't think it affects it; it is just something that was noticed.

- What version of OS is this?

- Has this every worked properly?

Hi,

Alcatel/AOS 6.3.0.1

Alacatel is an OEM of Aruba and they maintain the number of version.

As long as we can know, yes, it works properly.

We have more than ten thousand different users per day connected in our wifi.

And at peak hours our wifi have more than seven thousand sessions simultaneously. Many users have several terminals.

The complaints about malfunction in our wifi are very few and no one is similar to the problem I described above: the terminal is well connected but it does not navigate. 

This OS version and config work properly with almost any other phone, laptop, tablet, etc.

The problem affects only to 

1.-HTC phones

2.-connected on n

3.-and using AES.

If one of the three conditions changes then there is no problem.

Thank you very much again,

  Nicolas

---

@nvelaz03 wrote:

Hi,

 

Alcatel/AOS 6.3.0.1

Alacatel is an OEM of Aruba and they maintain the number of version.

As long as we can know, yes, it works properly.

We have more than ten thousand different users per day connected in our wifi.

And at peak hours our wifi have more than seven thousand sessions simultaneously. Many users have several terminals.

The complaints about malfunction in our wifi are very few and no one is similar to the problem I described above: the terminal is well connected but it dos not navigate. 

This OS version and config work properly with almost any other phone, laptop, tablet, etc.

 

The problem affects only to 

1.-HTC phones

2.-connected on n

3.-and using AES.

 

If one of the three conditions changes then there is no problem.

 

Thank you very much again,

 

  Nicolas

---

Is it possible that those HTC phones do not have the CPU to push an acceptable level of traffic when using 802.11n and AES.  Is there any way to open a case with HTC?

Maybe.

But the same phones work fine at the little n wifis of our houses.

This is one of the first things we test.

We'll try HTC option also.

Thanks

Nicolas

And another question I forgot now but I said in my first post: AES without n works fine.

Nicolas

No.

The HTC phone connected to wifi on n and AES doesn't navigate and doesn't mind how much load had the wifi network.

I've made tests using AP105 with or without load. The behavior is the same:

(n+AES) makes navigation bad ALWAYS,

(no n+AES) makes navigation good always.

The number of users I said previously are distributed by more than 500 APs and the tests was made over non congested AP105s and over one special AP105 mounted only for these tests.

The traffic load or the simultaneous users over AP can not be the reason, we think.

We used several AP105s and there isn't any phone or laptop that showed the same behavior.

The tests were made simultaneously with two HTC phones, two Sony phones, several Iphones and one laptop. The only affected equipment were the two HTC phones I wrote.

The other phones and laptop navigate good in every kind of encryption and every type of network (n or no n).

And the HTC phones doesn't navigate ONLY if n and AES were SIMULTANEOUS.

As I said in my first post, the most annoying result is that one ping to ip NUMBER in the phone didn't fail.

The ping utility could be very slow to obtain the DNS answer (maybe one of the reasons to the bad navigation but not the only one) , but when packet from DNS arrived, the ping to ip NUMBER never failed.

How is it possible that in n + AES, the DNS answers and http packets were so slow, and ping packets to ip numbers were so good?

Thanks again and sorry for my english,

  Nicolas

Hi all,

We are thinking about an interim workaround.

Can we assign a specific property to a device range?

The idea is to assign TKIP or to assign no-n to HTC phones using their mac addres.

Is it possible to assign a main type of connection for almos every device, but assign a "special" type of connection (n, encryption, other) to some range of devices?

The most useful key to identify devices is the OUI address, I think.

Can we make something like this in our controllers?

Thank you very much in advance,

Nicolas

Hello,

We found the problem cause.

As cjoseph said, It was the high priority push to DNS requests from clients.

We have one ACL in our controllers that includes several deny lines and one high priority push.

The ACL was added to solve problems with very old controllers, and was copied- pasted in the migration to new controllers and new OS version.

All the deny lines didn't affect.

The high priority line was the problem. But only in some HTC phones connected by n and using AES!!!!!!

Thanks to Alcatel TAC.

But I think that the REAL problem is a software bug.

It has no sense this behaviour.

Best regards,

 Nicolas