This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
I really don't know when it started? I could always see the Router in NEW VIEW or using my Windows Explorer replacement Explorer++? Now I can't always do that?
When I run NET VIEW this is the result:
==================
C:\>net view System error 1231 has occurred.
The network location cannot be reached. For information about network troubleshoting, see Windows Help.
==================
Googling that doesn't find anything useful, I'm on Windows 10, version 1709, which was installed on 10/18/2017, which could very well have been the last time it worked OK? Either that or a firmware problem but I don't know which firmware it started with?
I've downgraded the firmware all the way back to V1.0.9.4, and all releases in between. Same problem exists?
I do KNOW the names of the PC and Router on the LAN, so individual NET VIEWS work fine? For instance:
==============
C:\>net view \\irv8700 Shared resources at \\irv8700 Irv's 8700 Share name Type Used as Comment ------------------------------------------------------------------------------- C_8700 Disk K_8700 Disk L_disk Disk Users Disk The command completed successfully.
C:\>net view \\192.168.1.1 Shared resources at \\192.168.1.1 readyshare Share name Type Used as Comment ------------------------------------------------------------------------------- USB_Storage Disk read:admin;write:admin The command completed successfully.
C:\>net view \\readyshare Shared resources at \\readyshare readyshare Share name Type Used as Comment ------------------------------------------------------------------------------- USB_Storage Disk read:admin;write:admin The command completed successfully.
===========================
On occasions, rebooting the router fixes the problem for a short time. Same goes for turning on or off UPnP?
I just REBOOTED the router and that didn't help. Had UPnP off, so I turned it on, that 'fixed' it:
==============
C:\>net view Server Name Remark ------------------------------------------------------------------------------- \\IRV8700 Irv's 8700 \\READYSHARE readyshare The command completed successfully.
============
However I know in a short period of time the READYSHARE will disappear and I'll be back to the 1231 error.
I do use the Router with a USB drive to share movies. My iPad's Media Server programs work fine, until something happens and they can't see the shared DLNA server. The Samba Server will always work though? Annoying in that if I want to use the DLNA client I must reboot the router.
Anyone else see this? It seems to be UPnP is required to make NEW VIEW work right now, but in the past turning it off make it work too? Still it fixed the problem only for a short time?
Any suggestions? Other than this I've NOT had a problem with any of the V1.0.9.xx firmware releases?
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?
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
This sounds very much like a Windows issue.
Your PC knows nothing about the firmware on your router. There aren't any drivers either.
Any drivers are related to the network hardware on your PC, wifi and Ethernet.
.... I'm on Windows 10, version 1709, which was installed on 10/18/2017, which could very well have been the last time it worked OK? Either that or a firmware problem but I don't know which firmware it started with?
That build has been out there for some time. If it were causing major issues we would have heard about it here. That is, though, a clue worth pursuing. Maybe there was something in the update that messed up your local network stuff.
I assume that you have been through the process of restarting your whole network in the recommended way.
Be sure to restart your network in this sequence:
Turn off and unplug the modem.
Turn off the modem router and computers.
Plug in the modem and turn it on. Wait 2 minutes.
Turn on the modem router and wait 2 minutes.
Turn on the computers.
You might like to reset the router too. It may not help, but there are times when it can magically restore sanity. You won't lose anything, especially if you save a backup of your configuration. But be careful about restoring that backup. It may bring back problems.
You say nothing about the modem involved in this saga. Remember, that is also an important part of the network and has to be properly configured to work with a router.
Just another user with a set of boilerplate macros.
Your PC knows nothing about the firmware on your router. There aren't any drivers either.
Agreed, but then how do you explain rebooting the router cures it for a short time or just enabling or disabling UPnP makes it work without doing anything on W10, not even a restart of the PC. Just wait for the Router to come up. That and the fact that while the router appears to be on the network but not showing in NET VIEW or EXPLORER++ the SAMBA server still works but not the DLNA server on the Router?
Any drivers are related to the network hardware on your PC, wifi and Ethernet.
.... I'm on Windows 10, version 1709, which was installed on 10/18/2017, which could very well have been the last time it worked OK? Either that or a firmware problem but I don't know which firmware it started with?
That build has been out there for some time. If it were causing major issues we would have heard about it here. That is, though, a clue worth pursuing. Maybe there was something in the update that messed up your local network stuff.
I assume that you have been through the process of restarting your whole network in the recommended way.
Be sure to restart your network in this sequence:
Turn off and unplug the modem.
Turn off the modem router and computers.
Plug in the modem and turn it on. Wait 2 minutes.
Turn on the modem router and wait 2 minutes.
Turn on the computers.
You might like to reset the router too. It may not help, but there are times when it can magically restore sanity. You won't lose anything, especially if you save a backup of your configuration. But be careful about restoring that backup. It may bring back problems.
Yes, did all that, many times. That is how I discovered the problem could be cured with rebooting the router only. Matter of fact, it is still working fine now:
Compared to my original post you'll see my wife's PC was turned on and picked up fine as well. It seems the UPnP must be enabled as well for the NET VIEW command to work? I know when I was troubleshooting and I was trying to determine what might have an effect on NET VIEW in terms of settings. NET VIEW wasn't working and I did TURN OFF UPnP and NET VIEW started to work. However with it OFF even rebooting the router didn't make NET VIEW work. Once I enabled UPnP again (without the router reboot) NEW VIEW started to work again? Could it have something to do with W10 and SM1/3? Don't think so, otherwise I'd have discovered this problem with others on the web. W10 1509 had this problem (1231 error) and that was while in Beta. Nothing since.
You say nothing about the modem involved in this saga. Remember, that is also an important part of the network and has to be properly configured to work with a router.
I did have a modem replaced about a month ago too. I did the normal 'bring up process' and all seemed to work fine. Like I said, I can't tell for sure when this started. I first noticed it when I tried to use a DLNA Client on my iPad and it did see the R7000 but never could see anything below that, like the shares. Then discovered the SAMBA client worked though? Next I did the NET VIEW on the PC and discovered the problem with it. Not touching ANYTHING else I rebooted the router and the iPad DLNA client and NET VIEW on the PC worked fine. I can't even think of how this could be a W10, modem, or even iPad problem (when I first discovered this I did reboot the iPad and that didn't help).
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
Agreed, but then how do you explain rebooting the router cures it for a short time or just enabling or disabling UPnP makes it work without doing anything on W10, not even a restart of the PC.
By doing this you are forcing the local network, your PC, to reestablish a network connection.
Sadly, this repair does not persist, because whatever is going on on your PC kicks in again.
That's just a theory, but one based on my own current grief with a local network that, on one PC only, suddenly drops its speed to a crawling pace. It all started when the LAN port on my motherboard died and I had to install a PCI LAN card. But you don't want to know about that!
Just another user with a set of boilerplate macros.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
Yeah, I'm thinking it's a Windows thing. After all, 'net view' should mainly be using broadcast for discovery. The R7000 should just be blindly forwarding broadcasts everywhere.
Are any of your shares on Wi-Fi? As you may or may not know, Wi-Fi is not too good at handling broadcasts and multicasts.
BTW, here are some threads that talk about version 1511 causing problems.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
@TheEther, there are some things in my mind that rule out Windows... NOT one report of this on the latest Fall Update version, 1709. The other link I posted to a thread here that had both W10 and W7 doing it.
My first posting had shown only HARD WIRED stuff between my PC (IRV8700) and the Router (192.168.1.1) and the USB drive (READYSHARE). Later posting showing my Wife's PC coming on-line and that is WIRELESS. There are other devices that are wireless connected all the time though, like Amazon FireTV stick and Echo, iPad's, and when on, a SmartTV. Nothing else. All those were on when I ran NET VIEW.
Saw the FIRST link and I did change the SERVICES to AUTOMATIC with no change.
2nd link is for a BETA and almost 2 years old.
3rd one had a fairly recent response and claimed 1709 fixed the problem.
My thought right now lead me to the FIRMWARE. I really suspect 'over time' something drops or changes in the Router and it can't respond to the broadcast and W10 can't handle the 'error' or it sends back something W10 can't handle and posts the error.
Well, I just tried NET VIEW again:
C:\>net view System error 1231 has occurred. The network location cannot be reached. For information about network troubleshooting, see Windows Help.
Nothing has changed on either PC... sometime between may last post 8:54AM and now it started to fail again. I'm sure if I reboot the router (or possibly disable UPnP) it will be working again.
It could very well be connected to the USB share too? It seems strange to me that when my iPad's program I use that has both a DLNA and SAMBA client if the DLNA client can't see the share other than the router itself, but the SAMBA client has no problem, it is somehow connected to what the Router is presenting to the LAN. That takes W10's PC out of the equation, no?
Thinking along the lines that it might be the USB share, I did the Safely Remove and once it was ran NET VIEW again, and got a COMPLETELY different error :
C:\>net view System error 53 has occurred. The network path was not found.
Weird??? Adding MORE questions... I pulled the USB cable and plugged it back in. Immediately ran NET VIEW (disk is active, probably rebuilding the DLNA catalog as the light shows drive being read, and got this:
C:\>net view Server Name Remark --------------------------------------- \\IRV8700 Irv's 8700 \\LARAINE-XPS8500 The command completed successfully.
Just removing the USB drive allowed NET VIEW to show me the REST of the LAN?
Ahh, waiting for the USB Drive light to stop flickering:
C:\>net view Server Name Remark ---------------------------------------- \\IRV8700 Irv's 8700 \\LARAINE-XPS8500 \\READYSHARE readyshare The command completed successfully.
At this point I'm 'declaring' it IS NOT W10, but something to do with the firmware, probably similar to WIFI being lost, but this has to do with the USB Drive, and it is causing responses back to the NEW VIEW command in Windows to be 'bad' and W10, if anything' doesn't know how to handle it and throws a useless error...
Now the REAL question is do OTHERS have this problem? I did 'report' this in the lastest firmware thread, even using @JamesGL but never got an answer.
Again, NOTHING was changed in either PC or other attached device, and all done here on my W10 1709 release PC as I entered the NET VIEWS.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
See my response to TheEther and some more discovery I did.
See the last part though when I disconnected and reconnected the USB drive from the Router. Merely disconnecting it changed the error code that Windows produced. Reconnecting it 'repaired' NET VIEW. Yes, reconnecting it would allert the router there was an added share to handle, but that was INTERNAL to the router. At first the USB Drive is not really available as the disk was being read, but that was enough to make NET VIEW work again, and once the disk was read, a subsequent NET VIEW did add that share. All done with no change on either PC.
So let us assume 'something' I'm running would cause this to break? It isn't my wife's machine either, and that wasn't on the last time this happened. I can't trust letting the PC sit and 'things' happen all the time when connected to the Inet. Also I've had this happen when ALL PC's were off, just last night for instance. Before I shutdown this PC (only one on) I did a NET VIEW and the Router Share was seen. It WAS not when I booted this PC this morning, and the reason I opened this topic.
I am NOT discounting it could still be a W10 or some program doing something to damage the ability to see the LAN with NET VIEW, but again, since I know the SHARE names even when NET VIEW itself fails, NET VIEW \\SHARENAME works, so that too sort of rules out possibly a W10 problem, no?
I am at a loss how to CAPTURE the real culprit here? Surprised others (other than that one link I posted) are not experencing this too? Not many use USB drives? USB drive problem? It all worked fine before though?
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
Well, there's always Wireshark. At least, that's what I would do to see what's going on the wire.
I've never trusted ReadyShare. Too many reports of corrupted or flaky shares, and performance is basically terrible. Use a real NAS, like Synology or QNAP. Leave the router to do what it does best: route.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
@IrvSp wrote: Surprised others (other than that one link I posted) are not experencing this too? Not many use USB drives? USB drive problem? It all worked fine before though?
USB drives are a constant source of frustration.
In particular, things that work with USB2 refuse to play ball when plugged into USB3.
No one has ever got to the bottom of that. But I don't think anyone has put as much effort into debugging as you have.
Given the frustrations with the latest firmware for the R7000 and wifi, you have good reason to point a finger in that direction. It is just the logic that fails me. But who said IT was a logical domain?
Just another user with a set of boilerplate macros.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
@TheEther wrote: Well, there's always Wireshark. At least, that's what I would do to see what's going on the wire.
I've never trusted ReadyShare. Too many reports of corrupted or flaky shares, and performance is basically terrible. Use a real NAS, like Synology or QNAP. Leave the router to do what it does best: route.
Yes, I was thinking of firing Wireshark up. Wasn't too sure what to look for? Since my PC is on a fixed 192.168.1.30 IP Address I guess I could filter for anything going in or out from that address.
Oh, I forgot to mention, it takes a good amount of time when I enter NET VIEW and get back the 1231 error... all other times, even the 53 error come back immediately. All the more reason I think the router isn't responding or possibly W10 TCP/IP is retry and/or timing out and throwing the error. Possible that it got an error but didn't have a message for it so threw the catch-all error?
My USB drive is 2.0 and connected to 2.0 port and has worked 'forever', although in the beginning I did have problems with bad DLNA catalog when I first got the router years ago. Worked with NG Support and eventually got it fixed. Everything worked fine until recently. Of course there could be a possibility of some disk corruption too I guess causing problems? When I get a chance I'll take it to the PC to be sure. I have already used NET USE to assign it a drive letter and ran CHKDSK on it and it was clean???
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
Well the PC's were sitting still for hours.
The NET VIEW now fails with the 1231 error again and I'm having FireFox 'hang' with the spinning dots for about a minute when I try to access the Router? All this after disabling and reconnecting the USB drive. I'll probably need to reboot the router soon.
Something is clearly wrong, but I can't get a finger on it.
Another noticeable problem. The WAN IP Address is get RENEWED about every 1 1/2 hours. Lease time is around 2 hours according to the status of the connection. I've been round and round with my ISP on this and they claim it isn't so. I'm not wondering if the lastes V1.0.9.xx flashes have this set internally? Many routers do allow one to set the lease time, but not the R7000? Can you check your lease times? Reason being that seems to be the time that I lose NET VIEW ability?
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
Working FINE now? Both Firefox and IE get in OK?
BTW, under the ADVANCED TAB, on the INTERNET PORT select CONNECTION STATUS. What do you see for the LEASE? I see this:
Lease Obtained
0 days,1 Hours,34 Minutes
Lease Expires
0 days,1 Hours,4 Minutes
This is causing the router to be doing a DHCP request and TIME SYNC about every 1 and 1/2 hours.... Log has this:
[Time synchronized with NTP server] Sunday, Dec 31,2017 19:02:16
[Internet connected] IP address: 67.8.x.x, Sunday, Dec 31,2017 19:02:16
[Time synchronized with NTP server] Sunday, Dec 31,2017 17:32:06
[Internet connected] IP address: 67.8.x.x, Sunday, Dec 31,2017 17:32:06
[Time synchronized with NTP server] Sunday, Dec 31,2017 16:10:09
[Internet connected] IP address: 67.8.x.x, Sunday, Dec 31,2017 16:10:09
Never the same exact set period either, but around 1 and 1/2 hours. Most routers have a setting for getting a new lease. The R7000 does not. In another forum for my ISP someone else has hit this too, I've asked what router but didn't get an answer yet. Wondering is the firmware is causing it? Bad lease time in the code?
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
The lease time on the Internet port is set by the ISP's DHCP server. It's fairly common for ISPs to set short lease times. You might not believe it, but I've heard of really short leases, like minutes. While such a short lease is a little misguided, there's really no harm. The extra traffic and processing to renew a lease more frequently is insignificant.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
@TheEther, true, and I do know the ISP generally sets it but some routers do let you override that in a setting.
The quick lease renew started fairly recently too... I've got daily logs that show it starting 11/15 at 1AM. I was running V1.0.9.12 that I installed 5 days before. So I guess that answers that, not caused by the Router.
However, this fix, "Fixes the issue where Internet sessions are disconnected when the DHCP lease update occurs on the Internet port.", in V1.0.9.14 that went out in Dec. I probably needed. I was getting 'stalls' when using the Internet, usually it took a few seconds to complete the drop, sync, and connect again. It was long enough to recognize it. With V1.0.9.14 on it has not been a problem like that again.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
I am having the exact same issue on my Windows 10 system. Latest R7000 firmware. My Windows 7 system has no issues, nor does another Win10 system on my network.
The Win10 system in question can reach the other computer in the network listing in Explorer, but readyshare only by manually entering the \\readyshare address in the address bar.
I am also getting the 1231 error when running net view at the command prompt.
I noticed the behavior when upgrading from 1.0.7.12 to 1.0.9.14 and now .18.
Have not tried toggling UPnP.
Seems cosmetic at one level, since I can reach the other systems and network printers -- and even readyshare after a delay in explorer, but the network listing in explorer does not include readyshare or the printers. The only culprit left from my own digging on this issue is the router ... and it is quite frustrating.
I am having the exact same issue on my Windows 10 system. Latest R7000 firmware. My Windows 7 system has no issues, nor does another Win10 system on my network.
The Win10 system in question can reach the other computer in the network listing in Explorer, but readyshare only by manually entering the \\readyshare address in the address bar.
I am also getting the 1231 error when running net view at the command prompt.
I noticed the behavior when upgrading from 1.0.7.12 to 1.0.9.14 and now .18.
What is the difference between the W10 PC that works and the one that doesn't? At they the same? Same W10 version, same edition (Pro/Home)?
Although both rebooting the router and changing things like UPnP's state will make my W10 Home 1709 version work, it is only temporary.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
@TheEther, tried WireShark. I guess I don't know how to really capture NET VIEW. I did set the filter to show everything from my PC, 192.168.1.30, and I started the capture before I issued NET VIEW and stopped it after I got the 1231 error. However I can NOT find the actual command in the capture. I do see a lot of traffic back and forth from my PC to the router (192.168.1.1)? Only a 26K file so I've attached it here (it was removed, wrong ext, sigh... PM me and I can send it to you if interested). If you can, can you look at it? In the capture I see a LOT of references to READYSHARE (share name of the router), but at an odd IP Address, 224.0.0.252? Could that be the internal Router USB address?
I see in the list a lot of requests to tell my PC who has 192.168.1.9? However I only have 192.168.1.2-5 attached wirelessly now and my PC at 192.168.1.30 on-line? Screen capture of some of those attached...
Do you know how I can capture only the NET VIEW traffic?
I rebooted the router and of course NET VIEW worked:
C:\>net view Server Name Remark ------------------------------------ \\IRV8700 Irv's 8700 \\READYSHARE readyshare The command completed successfully.
So I started WIRESHARK. Same filter and this time I got hardly any lines (see capture attached). It was so fast I did it twice and all the traffic is shown in the capture.
I think I can 'fool' the s/w here by renaming the original WireShark capture extension from .pcapng to .jpg and then if you can d/l it change it back and view it? It seems when I RMB on a link and try to open it in a NEW TAB I get a chance to save it to disk or open it in a viewer (maybe the way my Firefox is setup though). If you can do this, the changing of extension should work.
Before my wife got up I rebooted the router. Of course NET VIEW worked after that just fine. I went and had breakfast and for over an hour my PC say idle, and even the display and hard disk went to 'sleep'. Woke it up and ran NET VIEW:
C:\>net view Server Name Remark --------------------------------------- \\IRV8700 Irv's 8700 \\LARAINE-XPS8500 \\READYSHARE readyshare The command completed successfully.
Still working, good. Since my wife's PC is now on I went to it since it is a W10 PRO. Surprise, it gets a 1231 error from NET VIEW!!!
This is all very confusing to me? We both have the same W10 release, 1709, and even similar h/w but one is HOME edition and the other PRO? I know you have similar results, one W10 PC works, the other doesn't?
I almost suspect some sort of 'connection' needs to be made between the router and PC when the router comes up or reboots? Once up and another PC comes on-line it will not work for that PC maybe? Might explain why when it was working fine one night before I shutdown it failed the next morning?
The PC must talk to the Router when it starts, if nothing else, to get its IP Address and Internet access. Hmm, this could be a large clue! Both of these PC's have a router assigned/reserved IP Address. Wonder if that could have something to do with it? On the one that fails for you, it is a reserved IP Address and the other isn't?
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
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.
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.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
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.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
@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.
Re: Problem with NET VIEW, W10, R7000, most recent firmware (including V1.0.9.20)
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:
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.
