Can anyone think of a setting on the AP1242AG access point that would effect the use of the roku's SSDP?

for reference to the SSDP I'm talking about
»sdkdocs.roku.com/display ··· ol+Guide

I have 2 wireless devices (Roku 2 XD and a Nexus 7) I'm wanting to use the roku app for the nexus 7 to control the roku, but it can't discover the roku.

so is there some setting that might block broadcast packets from one wifi device to another?

actions · 2013-Feb-4 9:46 am ·

wyked
Premium Member
join:2001-11-01
La Vernia, TX

wyked

Premium Member

2013-Feb-4 10:52 am

I would search your config to see if you have your bridge groups configured with the port-protected keyword.

If so then you would effectively have wireless client isolation enabled which would cause the issue you are seeing..

If you want to post your sanitized config it might help as well.

actions · 2013-Feb-4 10:52 am ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

2013-Feb-4 11:10 am

I'll post the config when I get home.
but for the moment this is a good sign, as there's something that could be causing it.

actions · 2013-Feb-4 11:10 am ·

DarkLogix

DarkLogix to wyked

Premium Member

2013-Feb-5 1:12 am

to wyked

AP1242AG.txt
6,331 bytes

Heres the config
I've altered the ssid names and removed the password hash

actions · 2013-Feb-5 1:12 am ·

DarkLogix

DarkLogix

Premium Member

2013-Feb-5 11:01 am

so anyone see anything that might be a fix?

ya I know most 1242 AP's out there aren't likely to have people want to use a roku app on them.

actions · 2013-Feb-5 11:01 am ·

ladino
join:2001-02-24
USA

ladino

Member

2013-Feb-6 1:59 pm

Are the 2 wireless devices using the same SSID?

The AP should treat the SSDP traffic just like any other IP traffic. You could create an ACL to see if there are any hits for TCP/UDP port 1900 & go from there.

actions · 2013-Feb-6 1:59 pm ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

1 edit

DarkLogix

Premium Member

2013-Feb-6 2:47 pm

Yep same SSID

I'll see about using a computer to wireshark sniff for 1900 traffic.

actions · 2013-Feb-6 2:47 pm ·

HELLFIRE
MVM
join:2009-11-25

HELLFIRE to DarkLogix

MVM

2013-Feb-7 10:50 pm

to DarkLogix

Need some time to take a detailed look at the AP config, but nothing looks out of the ordinary.

Besides wireshark, a "debug ip packet" is an option.

Also, are both devices in the same VLAN? Looking at your config, you have mutiple VLANs, so I'm wondering if
you have proper intervlan traffic traffic occurring or not.

Regards

actions · 2013-Feb-7 10:50 pm ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

2013-Feb-7 11:15 pm

Ya both are on the entertainment ssid

actions · 2013-Feb-7 11:15 pm ·

DarkLogix

DarkLogix to HELLFIRE

Premium Member

2013-Feb-8 9:32 am

to HELLFIRE

As I don't have a cable long enough to reach the console port on the AP and borrowing a laptop from work to do this wouldn't be a good idea.

Isn't there a way to direct debug info to a text file?

actions · 2013-Feb-8 9:32 am ·

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

2013-Feb-8 11:05 am

why do that when you can view it in a vty session.

»supportforums.cisco.com/ ··· ad/27779

however -- the better move is to span the ap port -- then use wireshark.

q.

actions · 2013-Feb-8 11:05 am ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

2013-Feb-8 11:18 am

I'd forgotten how to make debug messages go to the telnet/ssh session

and a text file would be easier to review.

Well the port is a trunk, and oddly intel's drivers don't want to accept the nic is an intel so I don't think I can do a trunk on my main computer.

actions · 2013-Feb-8 11:18 am ·

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

2013-Feb-8 11:28 am

said by DarkLogix:

Well the port is a trunk, and oddly intel's drivers don't want to accept the nic is an intel so I don't think I can do a trunk on my main computer.

not sure how that is significant.
span the physical port -- not the vlan. it'll dump everything into your destination.

alternatively, you could simply span a single vlan and dump it to a destination port.

mp-bgp_switch#sh ver
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
mp-bgp_switch#sh run int fa 0/24
Building configuration...
 
Current configuration : 57 bytes
!
interface FastEthernet0/24
 switchport mode trunk
end
 
mp-bgp_switch#sh run int fa 0/23
Building configuration...
 
Current configuration : 34 bytes
!
interface FastEthernet0/23
end
 
mp-bgp_switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
mp-bgp_switch(config)#monitor session 1 source int fa 0/24 both
mp-bgp_switch(config)#monitor session 1 destination int fa 0/23
mp-bgp_switch(config)#end
mp-bgp_switch#
*Mar  4 18:45:00.947: %SYS-5-CONFIG_I: Configured from console by console

actions · 2013-Feb-8 11:28 am ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

2013-Feb-8 11:44 am

I'll give it a try ether tonight or this weekend.

though I'm also trying to figure out whats wrong with my config for adding a 2nd NME-16ES-1g-p (from some of what I read it should ack like an independent L3 switch (loaded the same IOS as my other etherswitch onto it) and set OSPF intending to have a redundant routing path and to then set a 2nd default gateway via DHCP (so far its not working as planned.)

actions · 2013-Feb-8 11:44 am ·

DarkLogix

DarkLogix

Premium Member

2013-Feb-9 11:17 pm

Wireshark-ap···apng.zip
5,688 bytes

Ok did the session monitor

but a bit rusty at wire shark filtering, so maybe one of you could look at the output file I attached.

the Nexus 7's IP is 10.0.3.16
the roku is 10.0.3.14

I did the monitoring by plugging a nic into the ether switch and using the session monitos commands, the AP is powered by that ether switch btw.

actions · 2013-Feb-9 11:17 pm ·

cramer
Premium Member
join:2007-04-10
Raleigh, NC

cramer

Premium Member

2013-Feb-10 12:43 am

The only traffic from 14 is ping. 16 and 17 are sending SSDP queries but not getting an answer. My guess would be multicast traffic isn't getting to the roku. (either dropped within the switch(es) or by the AP itself.)

actions · 2013-Feb-10 12:43 am ·

HELLFIRE
MVM
join:2009-11-25

HELLFIRE to DarkLogix

MVM

2013-Feb-10 1:42 am

to DarkLogix

said by DarkLogix:

Isn't there a way to direct debug info to a text file?

Putty logging would've been my first suggestion.

Checking the wireshark capture and setting filter to "ip.addr == 10.0.3.16 and ip.addr == 10.0.3.14" -- no traffic comes up.

You might also want to check frames 23 and 89 :

M-SEARCH * HTTP/1.1
 
Host:239.255.255.250:1900
 
Man:"ssdp:discover"
 
ST: roku:ecp
 
MX:2
 
M-SEARCH * HTTP/1.1
 
Host:239.255.255.250:1900
 
Man:"ssdp:discover"
 
ST: roku:ecp
 
MX:2

The best way I think to TS this is take the 1242AP out of the equation for the traffic, but since Roku and Nexus are both
wireless, that idea's not going to work...

Regards

actions · 2013-Feb-10 1:42 am ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

2013-Feb-10 11:57 am

Well the roku does have a wired connection available, but the nexus 7 doesn't.

When I did debug ip packet on the ether switch through putty I saw that it skipped some sequence numbers, showing that it missed some data.

actions · 2013-Feb-10 11:57 am ·

DarkLogix

DarkLogix

Premium Member

2013-Feb-10 12:09 pm

Just looked over all the interface setting on the web interface to see if there was anything related to multicast.

found
Reliable Multicast to WGB

googled it and followed some links, then per a cisco forum post did "no IP IGMP Snooping"

seem that worked.

actions · 2013-Feb-10 12:09 pm ·

DarkLogix

DarkLogix

Premium Member

2013-Feb-10 12:34 pm

Thanks for the help.

The forum post I found was someone with a wifi device accessing a multicast server, they opened a tac case and found the ap wasn'trelaying multicast packets to the wired side.

actions · 2013-Feb-10 12:34 pm ·

HELLFIRE
MVM
join:2009-11-25

HELLFIRE to DarkLogix

MVM

2013-Feb-11 12:45 pm

to DarkLogix

said by DarkLogix:

I saw that it skipped some sequence numbers, showing that it missed some data.

Was it TCP or UDP data being transmitted? If it's UDP, remember UDP doesn't use sequence numbers.

Original Link Here, but the "ip igmp snoop" command...

IGMP snooping allows switches to examine IGMP packets and make forwarding decisions based on their content. You can configure the switch to use IGMP snooping in subnets that receive IGMP queries from either IGMP or the IGMP snooping querier. IGMP snooping constrains IPv4 multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically to forward IPv4 multicast traffic only to those ports that want to receive it. With Release 12.2(33)SXJ2 and later releases, IGMP snooping also constrains multicast traffic to VPLS interfaces.

IGMP, which runs at Layer 3 on a multicast router, generates Layer 3 IGMP queries in subnets where the multicast traffic needs to be routed. For information about IGMP, see Chapter 37 "Configuring IPv4 Multicast Layer 3 Switching."

...I've really got to read up on multicast again... but glad you got your problem figured out DarkLogix

Regards

actions · 2013-Feb-11 12:45 pm ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

1 edit

DarkLogix

Premium Member

2013-Feb-11 12:46 pm

It was the debug sequence numbers that were skipping.

A problem I read about when looking to have the debug data go to vty. Because the way the buffer works sending the debug messages to vty they get sent via UDP so if the interface buffer gets full it drops the debug message.

actions · 2013-Feb-11 12:46 pm ·

DarkLogix

DarkLogix to HELLFIRE

Premium Member

2013-Feb-11 12:51 pm

to HELLFIRE

I think its more of IGMP not being handled properly by the AP.

per the posts that I found it seems the 1242 (and maybe other cisco AP's, though maybe fixed at some point) doesn't handle multicast properly.

it should have seen that there was a wifi client listening for multicast and another sending multicast, but instead they didn't see each other via multicast and the multicast didn't reach anything other than the AP.

so wireshark didn't see it because it was constrained to the wifi side of the AP only.

actions · 2013-Feb-11 12:51 pm ·

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

2013-Feb-11 2:12 pm

said by DarkLogix:

igmp is a layer-2 join mechanism for mcast streams.
when a host wants to join an mcast stream -- it sends a join-request upstream. for devices that are "in the way" -- they 'snoop' the igmp and forward it along upstream -- until the tree is constructed to the source -- or some device who is aware of where the source is via pim, etc.

igmp snooping is a mixed-bag of support out of the box (i.e. enabled by default).

from what it appears -- cisco ap's are disabled by default.

dot11 igmp snooping-helper

should help snoop the mcast source and forward it along.

q.

actions · 2013-Feb-11 2:12 pm ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

2013-Feb-11 3:16 pm

Well it looks like "ip igmp snooping" was on by default on mine.

Doing "no ip igmp snooping" on the AP fixed it.

actions · 2013-Feb-11 3:16 pm ·

HELLFIRE
MVM
join:2009-11-25

HELLFIRE

MVM

2013-Feb-11 11:10 pm

...which makes me wonder why it was an issue in the first place. As the chunk I quoted said, it's so a device can
figure out how to forward multicast traffic. IIRC it has to be one SOMEwhere along the physical chain of devices
so it can figure out where it has to go... unless turning it on in two places along the chain screws it up somehow...

I hate a mystery right before going to bed....

Regards

actions · 2013-Feb-11 11:10 pm ·

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

2013-Feb-11 11:31 pm

i would venture a guess of the following (based on this article -- i'm knee-deep in ccie lab and don't want to break too much focus)

»wiki.stocksy.co.uk/wiki/ ··· eirdness

if this is indeed the truth -- it may seem that for every 'non-native' bridge-group -- you may need to tell the access-point to snoop igmp. by disabling 'igmp snooping' you won't have any igmp being forwarded upstream (i.e. if you had wired hosts performing the same functions) -- and everything will be isolated.

i think with the snooping helper -- you'll sniff igmp, bridge them to wired, as well as push them over the wireless -- but that is pure speculation on my part.

i haven't messed with autonomous a/ps in a long time -- everything i've done is controller-based.

q.

actions · 2013-Feb-11 11:31 pm ·

cramer
Premium Member
join:2007-04-10
Raleigh, NC

Westell 6100
Cisco PIX 501

cramer to HELLFIRE

Premium Member

2013-Feb-12 3:09 am

to HELLFIRE

It's a bug. It simply doesn't handle multicast correctly. (common failing of wireless gear.)

IGMP snooping allows the device doing the snooping to filter multicast to what's actually needed on a link. Without this "hack", all multicast traffic is flooded as broadcast traffic.

actions · 2013-Feb-12 3:09 am ·

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

2013-Feb-12 10:04 am

said by cramer:

My understanding is IGMP snooping trades CPU for bandwidth.
It builds a table of what is listening for multicast and then if something sends a multicast it only sends it to those listening, thus saving bandwidth on the non-listening ports. (kind of like a switch to a hub)

but on the AP1242AG (possibly other models too, and possibly fixed in a newer IOS) it just dead ends multicast at the radio, so even another wifi device won't hear the multicast.

By turning snooping off (the default is on, thus why the command didn't show up in the running config, but the no form does show up in the running config)

Its just a matter of a bug that IGMP snooping doesn't work on the AP.

actions · 2013-Feb-12 10:04 am ·

HELLFIRE
MVM
join:2009-11-25

HELLFIRE to cramer

MVM

2013-Feb-12 11:46 pm

to cramer

You wouldn't happen to have a bugID would you cramer? Funny that it still hasn't been fixed yet, but there's been wierder ones...

Regards

actions · 2013-Feb-12 11:46 pm ·

Forums → Equipment Support → Hardware By Brand → Cisco	« [HELP] ASA5505 > cable modem interface • Interface status..... »
page: 1 · 2 · next