DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
[Config] AP1242AG questionCan 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+GuideI 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? |
|
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. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
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. |
|
DarkLogix |
to wyked
Heres the config I've altered the ssid names and removed the password hash |
|
DarkLogix |
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. |
|
|
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. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX 1 edit |
Yep same SSID
I'll see about using a computer to wireshark sniff for 1900 traffic. |
|
|
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 |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
Ya both are on the entertainment ssid |
|
DarkLogix |
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? |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
why do that when you can view it in a vty session. » supportforums.cisco.com/ ··· ad/27779however -- the better move is to span the ap port -- then use wireshark. q. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
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. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
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. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
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 |
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. |
|
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.) |
|
|
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 |
|
|
DarkLogixTexan 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. |
|
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. |
|
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. |
|
|
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 |
|
DarkLogixTexan 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. |
|
DarkLogix |
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. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
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. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
Well it looks like "ip igmp snooping" was on by default on mine.
Doing "no ip igmp snooping" on the AP fixed it. |
|
|
...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 |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
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/ ··· eirdnessif 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. |
|
cramer Premium Member join:2007-04-10 Raleigh, NC Westell 6100 Cisco PIX 501
|
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. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
DarkLogix
Premium Member
2013-Feb-12 10:04 am
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. |
|
|
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 |
|