WRVS4400N is interfering with Windows7 HomeGroup (NetBIOS?) on wireless links(?)

[kobilraz1]

I have been using Windows7 (64bit) on all my network computers for some years now. One main computer is connected directly to the LAN port, and 4 via WLAN. Three more LAN ports are used for some VoIP equipment (non-Microsoft). All the Windows7 computers were connected via HomeGroup and were working impeccably. This was true as long as I used my old Linksys WRT150N Wireless-N router.
I recently decided to upgrade it to WRVS4400N so I would be able to use VPN for remote access. For the simplicity of the migration, I configured the WRVS4400N to have the same SSID and the same IP ports assigned exactly as it was on the WRT150N. I set only the default VLAN (I plan to add a second VLAN for guests that will be allowed to access the internet only), and I enabled WMM on the wireless, as I also have wireless VoIP handsets.

The swap was easy, and except for an issue I had with the “SIP Application Layer Gateway” that caused the WRVS4400N to hang, I had no issues. (I disabled the ALG as it was not really required).

After some time I noticed that I do not see all the HomeGroup computers, and I fail to communicate with them even when I enter \\hostname in the explorer address box. It worked well for a short period after I restarted both computers, but after a while I started having problems again. I thought that it would be wise to re-establish the HomeGroup, as there must be something different on the new network after all, and the old HomeGroup is not handling it well. So I had all my computers leave the HomeGroup, and I setup a new HomeGroup on the main computer. Now none of the other computers could join the new HomeGroup.
I contacted Cisco support, and the support person had me ping the ports, and claimed that if I can ping the ports, I could pass any other type of messages. This caused me to come to the conclusion that I must have somehow corrupted the Windows HomeGroup by resetting it. Especially since the Windows error message said “Windows cannot set a HomeGroup on this computer”. I spent two days on the Windows forums and tried all the tricks they suggested to recover the HomeGroup, but all failed. The other computers would not connect to the new HomeGroup, and in some cases they did not even recognize that there is a HomeGroup already set on the other computer.
Finally it crossed my mind to try to connect the Windows computers back to the old WRT150N. Once the computers were connected back to the WRT150N it took me just seconds to have all the computers join the HomeGroup with no issue whatsoever.
So now I am back to square one. The computers are connected to the WRVS4400N and have trouble connecting with sometime after they are booted. And I also learned a few things:

1. The Windows7 HomeGroup has no bugs I could blame.
2. The WRVS4400N interfered with the messages that had to take place between the computers, and thus prevented them from joining the HomeGroup. The WRT150N handled these messages correctly.
3. The WRVS4400N’s interference with these type of messages (NetBIOS?) is causing the computers to be unreachable after a while.
4. I have not tried to connect more than one computer to the LAN port, so I don’t know that for sure, but from looking at many other discussions, this may be a problem that is unique to the wireless link of the router. I also learned from these forum messages, that my problem might be a common problem to more models, and even more makes of wireless routers.

So here is the question: what functionality is missing or got corrupted on the new models (such as my WRVS4400N) that the old models (such as the WRT150N) could handle correctly, and is there a setup configuration or parameter that need to be set, that could solve this issue. Your input and support would be appreciated.

[jasbryan]

Kobi,

I wanted to ask what have you tried changing on the router? anything?

Disable IPS and test? repost results.

Also test with two clients on the LAN ports this way we can verify it's wireless problem or both.

Next you can change Netbios broadcast over TCP and test.

Only make one change at a time and then test, this way we know what fixed the issue if it changing a setting did resolve it.

Jasbryan

[kobilraz1]

Jasbryan,

Thank you for your support.

I have tested the LAN, and I can now say that this is NOT a wireless issue. I got the same problem on wired LAN (could not join the HomeGroup over the LAN as well).

As you requested, I have also tried to disable IPS, and that did not make any difference.

Other things I tried to disable and enable based on my own guess were:

• Inter-VLAN Routing
• Dual-Stack IP
• Multiple BSSID
• Wireless Isolation (between SSID w/o VLAN)

As you can imagine, none of these changes made any difference.

As for Netbios broadcast over TCP, I am not aware of any such parameter on the WRVS4400N. The Wi-Fi adapter, and the LAN NIC of the computers are set by default to "Use NetBIOS setting from the DHCP server. If static IP address is used or the DHCP server does not provide NetBIOS setting enable NetBIOS over TCP/IP." The status of these interfaces show indeed that NetBIOS over TCP/IP is enabled.

Thanks.

[kobilraz1]

I have made another attempt to solve my issue by hooking up the old WRT150N as the DHCP server to the WRVS4400N. I disabled the DHCP server on the WRVS4400N, enabled dynamic routing on both routers, disabled the NAT and changed the IP address of the WRT150N. After booting all the computers of my network, I made sure that they are using the WRT150N as the DHCP server. And.... NOP it did not fix my problem. PCs still can't join a HomeGroup under such a configuration. Only a pure WRT150N configuration lets them do it.

So, I have not solved the issue, but I guess I have narrowed the area where the missing or faulty functionality is. As this is not related to the wireless part, and it is not related to the DHCP server, I guess it should be related to the L2 Switch.

[tjkintz99]

I am following your efforts with interest. I decided to double check how Homegroup works today with my Netgear router. At first glance, things were promissing. Laptop A was on as was Desktop B. A and B could see each other via Homegroup. Laptop A got rebooted. Desktop B could no longer see it but Laptop A could see Desktop B. I then turned on Netbook C. C could see A and B, B could see C but still not A. I was too lazy to check what A could see but I once again conclude that for whatever reason, Homegroup is too unreliable to be used by me.

[kobilraz1]

Tom,

Millions of people around the world (including myself just until recently) use HomeGroups seamlessly and without any fuse. HomeGroup is the perfect solution for homes and small businesses that cannot afford to employ a professional IT person to manage the network, and need it to configure itself automatically.

I have just found out that Microsoft has published the protocol of HomeGroup in an open specification (that can be found here http://msdn.microsoft.com/en-us/library/ff362232%28PROT.10%29.aspx). The open protocol itself is based on well-established open standards, so that anyone can easily develop other applications or devices to interface with HomeGroups. So by giving up HomeGroup you will not be only giving up easy file sharing and printer sharing, and not only other Microsoft applications built around it like Windows Player streaming, and Remote Assistance, but also other applications that can be developed by third parties such as displaying presentations on screens via LAN and connections with TVs and mobiles.

Also, being an open protocol based on open standards, I see no reason why router manufacturers won’t be able to make sure their products are developed and tested to coexist with this feature. I am pretty sure they do it, and there must be something (maybe even obvious) that we are missing in our configuration that would make it work. I just haven’t been able to figure out what it is… so far...

[tjkintz99]

Kobi,

I agree with you in principle. Homegroup is a great concept and I wish it worked for me. I really hope you get to the root of your problem and it turns out to be the root of mine. I know I really tried to figure it out but ultimately gave up. However, without Homegroup I still have file and print sharing, Player streaming, Remote Desktop and Remote Assistance. I use these things all the time. I do have an extensive backgound in Windows and networking though. Although I am able to use classic Windows networking to get these functions to work, I acknowledge that not everyone can do it. When it came to Homegroup, I quickly figured out that my path of least resistance was using classic Windows networking rather than getting Homegroup to work reliably. As you know, it is very puzzling why millions of people can use a feature and a few like you and I have unexplainable (so far) problems. I really wish I knew what percentage of users have problems with Homegroup.

[tjkintz99]

In my earlier thread from December 2009, I reported similar problems with homegroup. I was never able to resolve those problems and simply quit trying to use Homegroup. Since then I have replaced the Cisco router it with a Netgear WNDR4000 and I still have the same problems with Homegroup. I know of no other Win 7 issues related to networking other than Homegroup. I would not be surprised that the router is the root cause of the problem but it is not unique to the Cisco router. Maybe they share some common code.

...tom

[kobilraz1]

As I continue to read about Windows7 HomeGroup (MS-HGRP), I understand that it doesn't involve any NetBIOS messages, so here is another question mark to take off my title.

As it is sometimes working and than stops, I tried to understand what is happening when it doesn't.

The most consistent failure is that one cannot join the group through this router. At that step the computer needs to update the network topology to make other computers aware that it has joined.
Sometimes the computer that needs to join doesn't even know that there is a group already defined on this LAN which indicates that it did not receive advertisement of that group.

Members of the MS-HGRP sometimes loose connection to the other nodes, which indicates that the information about the rest of the group has reached the end of its lifetime, and no refreshed information advertisement has reached it.

All these lead me to believe that the multicast functionality of the LAN subnet (probably over address192.168.1.250) or the functionality of it being able to receive IGMP messages and act upon them is not active or has some problem.

Unfortunately the WRVS4400N doesn't have any parameter that controls these functions that can be set from the web GUI, and I don't have any debug tools to see if they are on or off.

Can anyone check that for me, or let me know if there is another way to turn them ON?

[kobilraz1]

Further analysis I have done brought me to the conclusion that multicast on the LAN/WLAN subnet and support for IGMP (for adding anyone who joins the HomeGroup to the multicast group), are behind the problems I see.

I have also verified that on this model (WRSV4400N v2) the administrator does not have any control over enabling or disabling this feature. There is a parameter to bloc multicast messages coming from  the WAN but disabling it does not enable the LAN's ability to generate such messages, and specifically not to manage multicast via IGMP.

The good news is that I have contacted Cisco support, and they have promised me that they will reproduce the HomeGroup problem in lab. I will update this discussion with the results.

[jasbryan]

Kobi,

Please post your case number so i can follow their progress.

Jasbryan

[kobilraz1]

Jasbryan

The case number is SR 621220061. I have provided them all my Wireshark capture files.

Kobi

[kobilraz1]

To find out what are the messages that get lost in communication, I used Wireshark to capture both sides of the communication (thanks to tjkintz99 for suggesting this tool). I had only two Windows computers on the WRVS4400N LAN (none on the wireless side). One of them initiated the HomeGroup, and the other tried to join this HomeGroup. I merged the two captured files, and used Statistics‑>Compare to find out what happened to the packets sent between them. As the merged file has both sides of the communication, it should have a duplicate for all the packets that successfully travelled between these two computers (communication to/from other destinations appears only once). To be sure I capture all the issues, I repeated this test with a LAN computer that fails to communicate with a WLAN computer on its network.

I learned from this analysis that all the packets sent in unicast between my two Windows computers reached with none lost. However, some of the multicast packets got lost. I found out that some of the LLMNR packets sent to multicast address 224.0.0.252, some of the SSDP packets sent to multicast address 239.255.255.250 and all (there were only 3) the NBNS packets sent to broadcast address 192.168.1.255 were lost, i.e. they were not multicasted/broadcasted, and thus did not reach the other side. I also noticed that this is not happening all the time. Some packets are multicasted, and I guess this is why the problem is erratic, and when I try to join the HomeGroup right after the WRVS4400N was rebooted, I often get lucky and succeed.

This has proven my initial analysis, though I jumped a little too far by assuming that the multicast issue is related to IGMP functionality, while these are multicast groups that should exist by default according to Internet standards.

This also explains why I did never experience any problem with HomeGroup with my old WRT150N, and why it appears on some other routers. The WRT150N does not have a switched LAN, but rather a simple single-link hub. So all packets are broadcast by default, and appear on all ports. On a switched network, unicast traffic between two ports will not necessarily appear on other ports - only broadcast and multicast traffic will be sent to all ports. The problem may also appear on auto-sensing hubs that broadcast the 10Mb packets to the port that operate at 10Mb only and broadcast the 100Mb packets to the ports that operate at 100Mb only. This problem has also been reported for Netgear dual-speed hubs, and may exist for other "auto-sensing" or "dual-speed" hubs.

Half-duplex hubs are stupid, they forward all 1’s and 0’s to all ports, so no problem with HomeGroup will occur with them. All the other types of routers have to make sure they have implemented by design the entire Internet recommendations’ multicast/broadcast groups/ addresses.

This seems to be the root cause for my HomeGroup failure. As I have indicated, the required multicast packets do get sometimes through. That indicates that Cisco has designed these multicast addresses into the product, but sometimes they get dropped. Now it is up to Cisco to answer the question: why is it happening, and how can Cisco fix it?

[miswilli]

Hi Kobi,

I know this is a crazy question, but is multicast passthrough enabled in your firewall settings?

Also, is the IP mode set to dual stack- IPv4 and IPv6? Please see the following article to see why I ask this:

http://helpdeskgeek.com/windows-7/windows-7-cannot-connect-to-homegroup/

[kobilraz1]

Misty Williams,

Your question is not crazy at all.

Multicast passthrough was among the first things I have tried. It had no affect, as it only disables/enables multicasts coming from the WAN.

I have also tried to enable dual stack IPv6, and that also did not change the result (reported about it in the 3rd post). If you read my last post, you see that the problem is with packets going to IPv4 type of addresses. HomeGroup uses only local link IPv6 addresses, so this should not worry us.

I have worked with the HomeGroup troubleshooting guide you are referring to, when I was still suspecting it to be a Windows7 issue. I have now shown that some multicast packets get lost, though they sometimes do get through, which coincides with the original issue's erratic behavior. So the logical conclusion should be that this is not a set-up issue. Not of any of the computers, and not of the router. It must be some kind of a stability issue of the router.