Wireless Access

Hey All,

I have an IAP-225 running as a RAP.  I have a wired port configured on it and have a switch hanging off that.  We have these wired credit card readers from Shopkeep iPP320 Credit Card Reader they are connected to the switch that is connected to the wired port.  that port is in access mode/tunnel.  The readers get IP's of the same /23 as the wireless clients (whom are .1x auth'ed and split tunneled)  The iPads on the wireless network are running the Shopkeep app that is supposed to be able to "detect" the wired card readers.  That is not happening.  Before I start to yell and scream at Shopkeep I want to be sure i am not missing anything on the AP/controller side.

I do not know what the Shopkeep app is doing to "detect" the wired readers but I assume it is somekind of broad/multicast...

Thanks,

rif

Make sure you don't have "Broadcast Multicast Optimization" enabled on that VLAN.

Also make sure you don't have "Drop Broadcast and Multicast" enabled on the Virtual AP that the wireless clients are connected to.

Is that ethernet port untrusted?

Find out what the ip address of the credit card reader.  When it is trying to find the devices, type "show datapath session table <ip address of credit card reader>" on the controller multiple times, so you can see what traffic they are trying to send.

Hi Colin,

Thanks for the input.  "Broadcast Multicast Optimization" is not enabled on the IP interface for that vlan.  "Drop Broadcast and Multicast" is not enabled on the VAP to which the wireless client are connected (although "Convert Broadcast ARP requests to unicast" is enabled)  The wired ethernet port is Trusted.  I am presently trying to get the guy out there to do start the "finding" process again so I can see the output of the "show datapath session table" command....

Thanks!

rif

Hi Colin,

So when tracking the reader's IP I get:

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Packets Bytes Flags
-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- --------- --------- -----
10.1.30.243 10.1.30.1 1 4 0 0/0 0 0 1 pc1 16 0 0 FI
10.1.30.243 10.1.30.1 1 2 0 0/0 0 0 1 pc1 16 0 0 FI
10.1.30.243 10.1.30.1 1 3 0 0/0 0 0 1 pc1 16 0 0 FI
10.1.30.243 10.1.30.1 1 0 0 0/0 0 0 1 pc1 16 0 0 FI
10.1.30.243 10.1.30.1 1 1 0 0/0 0 0 1 pc1 16 0 0 FI
10.1.30.1 10.1.30.243 1 2 2048 0/0 0 0 1 pc1 16 0 0 FCI
10.1.30.1 10.1.30.243 1 3 2048 0/0 0 0 1 pc1 16 0 0 FCI
10.1.30.1 10.1.30.243 1 0 2048 0/0 0 0 1 pc1 16 0 0 FCI
10.1.30.1 10.1.30.243 1 1 2048 0/0 0 0 1 pc1 16 0 0 FCI
10.1.30.1 10.1.30.243 1 4 2048 0/0 0 0 1 pc1 16 0 0 FCI

which is the reader sending traffic to the default gateway.  and then the defualt gateway sending traffic back to the reader's IP.  I don't know what traffic it's sending.

Then, I tracked the iPads IP address (where the shopkeep app is running) and found this:

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Packets Bytes Flags
-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- --------- --------- -----
10.1.30.90 10.1.31.255 17 51970 22222 0/0 0 24 1 tunnel 109 10 0 0 FC
10.1.30.90 10.1.31.255 17 50765 22222 0/0 0 24 0 tunnel 109 4 1 56 FC
10.1.30.90 10.1.31.255 17 49569 22222 0/0 0 24 1 tunnel 109 16 0 0 FC
10.1.30.90 10.1.31.255 17 55781 22222 0/0 0 24 1 tunnel 109 a 0 0 FC
10.1.31.255 10.1.30.90 17 22222 55781 0/0 0 0 0 tunnel 109 a 0 0 FY
10.1.31.255 10.1.30.90 17 22222 51970 0/0 0 0 1 tunnel 109 10 0 0 FY
10.1.31.255 10.1.30.90 17 22222 49569 0/0 0 0 1 tunnel 109 16 0 0 FY
10.1.31.255 10.1.30.90 17 22222 50765 0/0 0 0 0 tunnel 109 4 0 0 FY

So the iPad seems to be doing what one would think it should be doing, broadcasting for the reader but the reader seems to be misbehaving by sending traffic to the default gateway for a destination of the same subnet/vlan...

rif

The first device just sent 5 pings to the default gateway.

The second device sent broadcast packets to 10.1.231.255 on port 22222

We need better information somewhere about what is required for this application.

You could open a TAC case to make sure that nothing you are doing is blocking the broadcast traffic, however.  I only gave two guesses.

Hi Colin,

I did open a TAC case for just that purpose.  However, we purchased these POS devices through Shopkeep and we can't seem to get anyone on the horn that knows about what the app is doing under the hood (protocol wise).  Very frustrating!

Thanks for your time,

rif

Hold on:

" The readers get IP's of the same /23 as the wireless clients (whom are .1x auth'ed and split tunneled)"

What is the role of these split tunneled devices and what are the ACLs attached?

The role of the split tunnel devices is POP-RAP-Role and the ACL's are:

POP-RAP-USR

IP Version Source Destination Service Action Log Mirror Queue Time Range Pause ARM Scanning BlackList Classify Media TOS 802.1p Priority

and the DestCorpNet "destination" are our various corperate LAN's

Fully tunneled devices might not be able to send broadcasts to split-tunneled devices.  Change one or the other to match and test again.

Colin,

I can surely try that.  Right now the (wireless) iPads hosting the Shopkeep (broadcasting) app are in split-tunnel mode.  They get a 10.1.30.0/23 address.  The wired readers are in tunnel mode and also get a 10.1.30.0/23 address.   When tracing the iPads broadcast we saw:

10.1.30.90      10.1.31.255

10.1.31.255    10.1.30.90

that looks like a normal broadcast, but I do not know how to read the reply... how can a broadcast address 10.1.31.255 send a reply (pardon my ignorance)?  Can we assume that 10.1.31.255 is actually the default gateway repying?  If so that would indicate the traffic is getting down the tunnel right, and in fact we did see 10.1.30.243 10.1.30.1 at one point in responce to the broadcast.  

I guess my question is which one does it make the most sence to change?  I think it sounds like I should change the tunneled wired to split-tunnel?

Thanks,

rif

You should change them both to tunnel.  When you are doing split tunneling, the firewall processing is done on the AP.  When you are doing tunnel, the firewall processing is done on the controller.  The processing needs to be done in the same place to determine where we go from here.

Ok, that sounds reasonable.  In tunnel mode as you mentioned fw'ing will be handled by the controller will there be certain default settings to change to make sure the broadcast traffic isn't obstructed back on the controller?

thanks,

rif

Drop broadcast and multicast needs to be disabled at the virtual ap and broadcast multicast optimization needs to be disabled on the vlan.

Ok, that has been confirmed...

thanks,

rif

Should the wired port be trusted or untrusted?

rif

It should be trusted.

right, that's what i thought.  however when i put it unto trusted mode the wired clients showed "tunnel-down" in the ESSID on the monitoring page....?

If you make a wired port "trusted" the users no longer show up in the Client's tab.  The users can still pass traffic, however.

Ok, so it looks like it is working now... I have both wired and wireless in Tunnel mode, both wired and wireless users in the same role, and still have the wired port in "untrusted" mode...  What do you think?

rif

It should be working.

Hey Colin,

Do you think it would work if the wireless and wired users where both split-tunnel?  Now I have a complication with our analytics people as they were tracking the orders (the RAP is out at a pop-up retail store) via the WAN ip.  Now that the WAN ip is my corp office they cannot destinguish between sales at the shop and sales made back here by cust care...

rif

Try them both as split tunnel, absolutely.

Will do.

thanks,

rif

It all works now wired and wireless split-tunnel

Thank you!

rif