dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1682
share rss forum feed


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

[Config] AP1242AG question

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/RokuSDK···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?
--
»Death Star Petition



wyked
Premium
join:2001-11-01
Cibolo, TX

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.
--
What is a Juggalo? I don't know, but I'm down with the clown and down for life yo!



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

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.
--
»Death Star Petition



DarkLogix
Texan and Proud
Premium
join:2008-10-23
Baytown, TX
kudos:3
reply to wyked

downloadAP1242AG.txt 6,331 bytes
Heres the config
I've altered the ssid names and removed the password hash
--
»Death Star Petition


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

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.
--
»Death Star Petition


ladino

join:2001-02-24
USA
kudos:1

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.



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

1 edit

Yep same SSID

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


HELLFIRE
Premium
join:2009-11-25
kudos:18
reply 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



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

Ya both are on the entertainment ssid



DarkLogix
Texan and Proud
Premium
join:2008-10-23
Baytown, TX
kudos:3
reply 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?
--
»Death Star Petition



tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1

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

»supportforums.cisco.com/thread/27779

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

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."



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

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.
--
»Death Star Petition



tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1

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
 

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."


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

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.)



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

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.
--
»Death Star Petition

cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:9

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.)


HELLFIRE
Premium
join:2009-11-25
kudos:18
reply 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


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

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.
--
»Death Star Petition



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

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.
--
»Death Star Petition



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

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.
--
»Death Star Petition


HELLFIRE
Premium
join:2009-11-25
kudos:18
reply 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 See Profile

Regards


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

1 edit

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.



DarkLogix
Texan and Proud
Premium
join:2008-10-23
Baytown, TX
kudos:3
reply 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.
--
»Death Star Petition



tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1

said by DarkLogix:

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.

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.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."


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

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

Doing "no ip igmp snooping" on the AP fixed it.
--
»Death Star Petition


HELLFIRE
Premium
join:2009-11-25
kudos:18

...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



tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1

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/Cisco_12···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.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."


cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:9
reply 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.



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

said by cramer:

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.

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.
--
»Death Star Petition

HELLFIRE
Premium
join:2009-11-25
kudos:18
reply 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