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:
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.
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.
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:
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.
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.
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.
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...
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.
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.
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?
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.
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 18.104.22.168, some of the SSDP packets sent to multicast address 22.214.171.124 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?
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:
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.
I have intermittent issues with Bonjour working consistently all the time.
This is the same type of multicast discovery process and it's hit or miss frequently. I'll have wired devices that usually find other wired and wireless devices but not always. Some wireless devices that usually find other devices but not always. Some wireless devices that will fail consistently, but if you shut off wifi, wait a few seconds then turn it back on, they'll find other devices again. Some wireless devices whose visibility comes and goes at random. Some wireless devices that even when they're visible to others, cannot be see any other devices.
Because I have all of the devices that need to be found at specific DHCP addesses set in the router, I can normally find them with a direct connection even when the Bonjour search fails to find them to see that they are up. Which doesn't hlep when the application that needs to find them only support the Bonjour discovery that's not working. Any times the direct connection also fails, is a time the wireless client has been dropped from the network, just because.
Every time it happens, I think about replacing the router now.
I researched your issue and found only one other case that was very similar and it was resolved with an RMA of the device.
Please call us at 1-866-606-1866 with your serial number and we will be happy to assist. After an initial assessment of the issue and typical troubleshooting, we can get this resolved for you.
Thank you and have a great day!
It's not worth the effort and shipping cost to RMA the unit.
I've had other issues with it where connecting a Nook Color to the WiFi causes the router to crash every time. Or at least it did on a prior version of the Nook Color software, we haven't tried again once the device was assigned to a different wireless network instead.
I've also had issues with a WAP4410N operating as a bridge in either Client mode or WDS bridge mode where it would often disconnect. Other errors on the router's log would also show up intermittently when the WAP4410N was connected this way, sometimes causing the entire network to slow until the WAP4410N was power cycled.
I've tried many different settings and all of the work arounds others have posted for the two devices and both have the most current software. I never found a combination that lasted more than a few days, frequently less, and frequently much less once the problems manifested after the initial set up.
I've already replaced the WAP4410N with a different wireless bridge instead. The other product isn't as robust or fast as the WAP4410N when it's working. But the other product works consistently and has never decided to just drop off the network and it was a fraction of the cost.
If new software comes out before I replace the router for either device, I'll try them again. But, really I'm more likely to replace the router first and simply recommend others do the same instead of investing time in this one. Especially based on the time between software updates that still don't fix the basic issues.
It may even be that the WAP4410N will make a good bridge in client mode connected to some other router. I was never able to figure out which side of the WAP4410N - WRVS4400N connection was really the problem.
Hi Kobi- I see the case was escalated to level 2. I will contact the technician regarding the case in hopes you will have a resolution sooner. I apologize for the delay but I will see if I can get the ball rolling for you.
Has this ever been resolved or acknowledged by Cisco? I have the exact same problem with my RVS4400N and I am rsearching non Cisco routers at this point unless I can find a fix.
No. This has never been resolved. Though I have debugged this issue and proven beyond any doubt that this is a router issue (failure to comply with some broadcast specs), Cisco said that they will not fix it as this is end-of-life product.
If you cannot ship your Cisco router back for refund, you may consider using OpenWRT firmware on it. Of course you can always buy a non-Cisco product as you said.
The information you have provided here has been great for me, so thank you (especially for the wireshark stuff and the different router insight you provided). That detailed information finally put me on a track towards looking closer at the RSTP/STP port settings and the upnp setting on the WRVS4400n to fix an almost identical problem I was having with a 5 PC/2 printer LAN setup at a small business (all running Win7Pro 64bit or Win8Pro 64bit) using a standard windows workgroup and Xp compatible 40bit/56 bit password encrypted sharing.
I believe at the heart of your problem (and the one I just fixed) is the step up from Fast Ethernet (half duplex) networking to Gigabit Ethernet (full duplex only) and the need for spanning tree protocol enabled on ports, and the router/PCs to use upnp to tweak values for optimum discovery.
Before doing anything else, I went to each of the machines and reconfigured the services on the PCs relevant to workgroups, setting them to “automatic start” to ensure they'd be running again even if they stopped and started any that weren't already running (as listed on the link below, as previously provided by Misty Williams)
With upnp being listed within those service, I decided to re-enable upnp in the router, and to verify I hadn't accidentally setup some VLANs (which I hadn't), so I then proceeded to the RSTP section.
The group changes I made to the RSTP settings are as follows:
Hello Time: 1
Max Age: 6
Forward Delay: 4
Force version: Compatibility
And then I enabled the protocol on each of the ports and rebooted the router and machines to see if it fixed the problem so that all systems could see all systems in the network list without manually typing UNC paths.
It fixed the long standing problem of devices randomly disappearing from the network list and even UNC paths temporarily becoming unavailable, so it might be worth trying these options on your setup and even on the netgear you mentioned to see if it is the same problem for you.
This had been an on going inconvenience for the small business I installed and configured the WRVS4400n and fileserver for and they'd continued to work around for 8months. After replacing all the network cables and countless other wild goose chases I'd began to suspected it was caused by Sage Line 50's data thrashing(like a DoS attack on the router), or the PC's internet security suite updates changing services and personal firewall settings, or a sporadic routing information issue with the unknown business park router that was the gateway for the WRVS4400n's WAN port (on the other side of the hardware firewall). So hopefully this is another mystery solved, and thanks again for the information.