NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
EruvWeather, TheEther, guys, this is driving me nuts...
As it stands NOW my wife's PC continues to have NET VIEW work properly, and has since I did a clean install of her X64 W10 Pro Ver. 1709. On the other hand mine will only work IF I reboot the Router and her PC is not on. Once her's comes on, it no longer works, and will never work again until I reboot the router.
I opened the POWERSHELL on both PC's and ran "get-smbserverconfiguration" and compared results.
Interesting, on mine EnableSMB1Protocol is set to True, but on her's, it is set to False?
Checking Features installed I have SMB1 Server checked where her's has Client checked?
Odd, what do you have?
I've set mine to Client now but need to re-boot. Will update when I come back on.
EDIT:
FIXED IT!!!!
GET-SMBSERVERCONFIGURATION now matches her's and it WORKS as expected!!!
C:\>net view
Server Name Remark
---------------------------------------------
\\IRV8700 Irv's 8700
\\LARAINE-XPS8500 Laraine's XPS8500
\\READYSHARE readyshare
The command completed successfully.
I don't KNOW how my SMB1 features were set or when, or even why.
Suspect at this point a change happened during one of MS's Updates?
Searching the web I found this page, https://community.spiceworks.com/topic/1995592-disabling-smb1-stops-domain-authentication marked SOLVED.... in it:
-------------
Did you try just disabling smbv1 and not actually removing the windowsfeature?
edit: by running this command in an elevated powershell prompt:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
---------------------
Wonder if I did that it would have fixed it as well?
EruvWeathergive this a try... might just work!
I wouldn't expect to see the actual words "NET VIEW" in a packet capture. It's just a Windows command. You certainly don't see "PING" in a ping packet, which is just an ICMP echo request.
224.0.0.252 is the address used for LLMNR (Link Local Multicast Name Resolution). It was designed by Microsoft and is very similar to mDNS. I found an interesting read on the controversy between LLMNR and mDNS. It seems that LLMNR has "lost" the battle with mDNS, but I guess Windows is still using it.
No idea what's going on with the ARP for 192.168.1.9. Perhaps there was a device at that address in the past.
As to why NET VIEW might be returning immediately with no traffic, it's likely that Windows is just returning cached results. You might consider re-running Wireshark and just capture everything. There could be some important exchanges going on via broadcast that might be filtered out with a "host 192.168.1.30" filter. You can always filter after a capture.
Yeah, that is why I don't know how to find the 'thread' for Net View, don't know what to look for? I'm sure there are other things going on at the same time too, as I see an e-mail check as well during that time.
mDNS, makes sense, saw some DNS requests...
As for 192.168.1.9, I might have had that many pool requests at one time but not now. Only 2 - 5 were assigned to active devices. Didn't see anything for 192.168.1.6/7/8 either? Makes no sense?
I created the capture with a filter "ip.addr == 192.168.1.30" and adding in the "host 192.168.1.30" didn't seem to shorten it?
I did read somewhere that NET VIEW will use a cache and it can be up to 25 minutes before a device is dropped out of the cache as it is renew after that time. Maybe that explains the fast trace in WireShark. Since NEW VIEW is still working and very fast, I suspect that the cache renew is not happening. Only when something on the LAN changes is it updated I suspect? Maybe the router signals that, I don't know.
I've uploaded NET_VIEW.JPG, it is the capture in case you want to look at it. D/L and change the extension to .pcapng and then use that to open WireShark.
At this point, I'm really thinking something is wrong with the firmware, especially since someone else also has this happening and working on one PC and not another.
Also the delay in opening the router in a browser that michaelkenward also has, is new, and doesn't always happen, but new with .20 for sure. Suspect a cache involved there too maybe?
I don't want to go too far back in firmware for fear of losing some security updates, and that supposed fix for the IP Address dropping on a RENEW of the IP Address which is happening often for me. Right now I'm sort of stuck. I do transfer files from my PC to the router USB drive often, and use Explorer++ to do that as I can select a file and drag it to the share folder on the router in the network, but if I can't see the network share in Explorer++ I can't do that. I know I can using NET USE assign a drive letter to the share, that works, just like NET VIEW \\readyshare, can then use Explorer++ for transfers... so I do have a work-around. Still, I think the firmware is involved and would like it fixed, as it did work before for a long time until recently.
NOTE/EDIT: I checked the file, d/l'ed it and changed the extension and then double clicked on it, opened WireShark and it is all there.
TheEther wrote:
Ignore the ARP for 192.168.1.6 for now. It's a red herring.
NET_VIEW.JPG doesn't work. All I see is a tiny white square. Did you attach the right file?
Did you post Wireshark capture file somewhere? I don't see it.
You have to D/L the file and change .jpg to .pcapng, then it will work by double clicking on it wherever you did the D/L to. Worked for me when I tested it.
Oh, sorry. Ok, I can view it with Wireshark.
AFAICT, I can see standard NetBios Queries and responses. I also see a successful connection to READYSHARE. So, it looks good there.
I also see LLMNR queries, but no responses. As I mentioned earlier, LLMNR is kind of dead, so it's no great surprise that the router is ignoring them. Nor is there any harm.
The next bit is where NET VIEW comes into play. For reference, these two articles are pretty good at describing how the Windows Computer Browser service works:
Name Resolution and Browsing (look for Browsing in a Windows Network)
How Computer Browser Service Works
In the packet capture, you can see packets 56 and 58 are Computer Browser Service packets. Packet 56 is a Get Backup List Request from 192.168.1.30. This is a request to find a server that can provide the list of Windows servers on the network. Packet 58 contains a Get Backup List response from the Netgear, stating that READYSHARE is a server.
Now, it's my understanding that what should happen next is that 192.168.1.30 should contact the server (in this case READYSHARE) and ask for the list of Windows servers via a NetServerEnum request. It appears that 192.168.1.30 never does this. This might explain why the NET VIEW command is returning nothing. The command has nothing to display because the computer never sent a NetServerEnum request. Why? I don't know.
Anyway, it looks like the Computer Browser Service operates on 12 minute cycles. That is, every 12 minutes computers that have File Sharing enabled will announce their presence. You could run Wireshare through an entire 12 minute cycle and see what happens, although I'm not sure if a whole lot will be learned from it.
TheEther wrote:
Ignore the ARP for 192.168.1.6 for now. It's a red herring.
NET_VIEW.JPG doesn't work. All I see is a tiny white square. Did you attach the right file?
Did you post Wireshark capture file somewhere? I don't see it.
TheEther, you actually meant 192.168.1.9. Just discovered WHAT that is... and it isn't a red herring.
It is our wireless HP Printer. Sometime ago we had 2 HP wireless printer, an HP 310A and the only one we have now, an HP 7525. Before we got the HP 7525 I had wireless problems with the HP 310A. The easy solution via HP was to set it on the printer setup for the Network at an xxx.xxx.xxx.10 IP address. That indeed solved the problem. When we added the HP 7525 I automatically within its settings set it to 192.168.1.9.
So, this I think might be a clue? The printer is turned on as needed. Usually it isn't needed often so most of the time it is off. I don't recall it being on when I tried to do a NET VIEW, but obviously something within Windows or the R7000 KNEW it had an IP Address and was trying to see what it was?
Right now I'm getting the 1231 error. I opened Explorer++ and selected NETWORK. It saw my PC, my wife's PC, and 2 R7000 items, the R7000 itself and the Media Server on it, but NOT the USB share. Same for Windows Explorer, see the attached screen capture.
Now I'm thinking 'possibly' when the printer is turned off that notifies the Master Browser on the R7000 and it deletes the printer, however it doesn't recover?
I'm going to test this again, reboot the router, test NET VIEW, turn on the printer, test NET VIEW, and the turn off the printer, and then test NET VIEW again. I will capture the Explorer++ with the Router working on NET VIEW and post this as well. If nothing else, you can see the difference that is shown for the Router, which to me indicates a router problem, not W10.
