If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
Noob networking question - why does \\DESKTOP\pubshare\readthis.txt not work but \\192.168.1.5\pubshare\readthis.txt work just fine?
On Thu, 12 Jul 2018 06:45:46 -0000 (UTC), Arlen Holder
wrote: Noob networking question - why does this command not work: Start Run \\DESKTOP\pubshare\readthis.txt But this command works just fine? Start Run \\192.168.1.5\pubshare\readthis.txt My overall goal is to set up a single password file on the LAN, but for this question, the text file above is good enough of a test of the network. Bear in mind I don't normally play with networking, so, the answer may be something silly that I forgot to do. Given two windows machines on the same LAN, here's how I set up the network. ================================================= =========================== 1. Make sure the PC1 computer name isn't something created by Microsoft! Start Settings System About Rename this PC (change name) Device Name = DESKTOP Restart http://img4.imagetitan.com/img.php?image=18_pubshare01.jpg ================================================= =========================== 1. Make a new folder on PC1 for public sharing: mkdir c:\tmp\pubshare ================================================= =========================== 2. Right click on that folder on PC1: Properties Sharing Share (select a username) Share ================================================= =========================== 3. That says "your folder is shared" to that user". pubshare \\DESKTOP\pubshare http://img4.imagetitan.com/img.php?image=18_pubshare02.jpg ================================================= =========================== 4. On PC2, as the same user, right click in "This PC" to Add a network location Choose a custom network location \\DESKTOP\pubshare That didn't work for me, so I got the IP address using "ipconfig" where the IP address worked fine: \\192.168.1.7\pubshare Where it asked "Type a name for this network location": pubshare (192.168.1.7) And it said "you have successfully created a network location: As long as the IP address doesn't change, you're fine. ================================================= =========================== 5. It's easy to reproduce on PC2 using the Start Run dialog box: This fails: Start Run \\DESKTOP\pubshare\readthis.txt This works: Start Run \\192.168.1.7\pubshare\readthis.txt ================================================= =========================== 6. Maybe the domain name is the problem? (I never set one, I don't think). On PC1: Start Settings Network & Internet View your network properties http://img4.imagetitan.com/img.php?image=18_pubshare03.jpg On PC2: It's similar http://img4.imagetitan.com/img.php?image=18_pubshare04.jpg ================================================= =========================== Bearing in mind I may have made a dumb noob networking mistake, can you point me in the right direction to getting this command to work on PC2? Start Run \\DESKTOP\pubshare\readthis.txt Where the eventual goal is a single location for a password file. ================================================= =========================== Just a thought, but have you tried adding DESKTOP 192.168.107 to your Hosts file? I add all my computers to HOSTS so that they can find each other faster. I use the same HOSTS file on each box so they all "know the same thing" (I also use it to block bad web sites but that a Whole other thing) Beamer Smith Out on a limb, sawing Madly |
#2
|
|||
|
|||
Noob networking question - why does \\DESKTOP\pubshare\readthis.txt not work but \\192.168.1.5\pubshare\readthis.txt work just fine?
|
#3
|
|||
|
|||
Noob networking question - why does \\DESKTOP\pubshare\readthis.txt not work but \\192.168.1.5\pubshare\readthis.txt work just fine?
On 13 Jul 2018 02:51:42 GMT, Arlen Holder wrote:
That transceiver is set to "Bridge" mode - and it may be blocking the NETBIOS broadcast packets (I don't know that for a fact yet though). BINGO! That is the problem! http://img4.imagetitan.com/img.php?image=18_pubshare07.jpg The *cause* of the NETBIOS name-resolution issue has been *identified*! *The transceiver is apparently blocking the NETBIOS broadcast packets!* The proof is that simply lugging the computer a few floors down to the router, and plugging the computer directly into the router, instantly solved all the SMB NETBIOS name-resolution problems. Woo hoo! I love figuring out what the problem is! *Thanks to all your purposefully helpful advice* NOTE: I usually mark a thread SOLVED but this isn't solved so much as it is IDENTIFIED as to why one Win10 computer wasn't recognized on the LAN by other WIN10 computers using SMB NETBIOS name resolution. It bothered me that almost never on the net did I find anyone who actually identified the problem where everyone threw commands at the problem until one of them worked - which I did too - but none of them worked! (Well, the HOSTS & LMHOSTS will work - but those are hacks.) NOTE: Yes I could figure out how to use tcpdump & wireshark to sniff out the packets, but it's crystal clear now what is happening since simply eliminating the outdoor transceiver temporarily solved the problem instantly. The outdoor transceiver is blocking the SMB NETBIOS broadcast packets! There are a bunch of possible solutions: 1. Figure out how to set the transceiver to pass NETBIOS packets 2. Figure out how to set up a WINS server (which seems like overkill) 3. Or, add a WiFi card to the desktop (I don't have a spare though) 4. Or, just put the static IP address in the LMHOSTS or HOSTS file I'll first read up on the transceiver software, to see if it's easy to get the transceiver to pass SMB Netbios broadcast packets, and then, if that doesn't pan out, I'll do one of the other three solutions. Since none of those solutions involved Windows 10, per se, this thread is pretty much over with from a Windows 10 standpoint. Thanks everyone for your purposefully helpful advice! (I won't need to post back unless a new solution comes to mind.) |
#4
|
|||
|
|||
Noob networking question - why does \\DESKTOP\pubshare\readthis.txt not work but \\192.168.1.5\pubshare\readthis.txt work just fine?
On Fri, 13 Jul 2018 04:01:40 -0000 (UTC), Arlen Holder
wrote: NOTE: Yes I could figure out how to use tcpdump & wireshark to sniff out the packets, but it's crystal clear now what is happening since simply eliminating the outdoor transceiver temporarily solved the problem instantly. The outdoor transceiver is blocking the SMB NETBIOS broadcast packets! Meanwhile, sane people are left wondering what manner of misconfiguration led to you having an outdoor transceiver *inside* your LAN. Not connecting your LAN to the Internet, but connecting one part of your LAN to another part of your LAN. I'm always amazed at what people come up with when they don't really understand how to do something. I'm being serious. Sometimes the creativity is just something to behold. |
#5
|
|||
|
|||
Noob networking question - why does \\DESKTOP\pubshare\readthis.txt not work but \\192.168.1.5\pubshare\readthis.txt work just fine?
On 12 Jul 2018 20:53:48 GMT, Char Jackson wrote:
Meanwhile, sane people are left wondering what manner of misconfiguration led to you having an outdoor transceiver *inside* your LAN. Not connecting your LAN to the Internet, but connecting one part of your LAN to another part of your LAN. I'm always amazed at what people come up with when they don't really understand how to do something. I'm being serious. Sometimes the creativity is just something to behold. I didn't provide enough detail for you to know that there isn't a single device on my network outside the network (i.e., they're all on 192.168.1.x). You can tell, actually, if you look at the screenshot, which proves that the static IP address of the transceiver is on the same 192.168.1.x subnet: http://img4.imagetitan.com/img.php?image=18_pubshare07.jpg To be a bit more precise, there is one of the many rooftop antennas that picks up my Internet feed from a half-dozen miles away over the air from a visible mountaintop, which is, of necessity, configured by the WISP and which connects to the WISP's internal network of a 10.something address where it bounces among the WISP mountaintop towers until it finally gets to a fiber-optic cable in the ground). But you would have no way of knowing that I happen to have about a dozen transceivers scattered about my rather large house and property, which has buildings that are a thousand feet from the house, all of which have Internet access, and where here is a photo of just a handful of my radios, for example: http://img4.imagetitan.com/img.php?image=18_wifi.jpg Everyone in my area (which has no "cable") gets their Internet over the air, and we all have cellular repeaters or towers inside our homes (I have both a femtotower and a cellular repeater for example). So while I don't know Windows networking, you can't survive in these hills without some knowledge of transceivers (and water pumps, septic systems, poison oak removal, chain saws, etc.). As for this particular Windows PC setup, it's a desktop that doesn't have a WiFi card, but it has an Ethernet RJ45 port, and I have plenty of spare transceivers, so, I simply tied an Ethernet cable from the computer to an outdoor transceiver which is pointed back at the house, only a couple floors down. The transceiver acts no differently than a WiFi card with an external antenna would act, only if you look at the decibels in that screenshot, you'll see that the WiFi signal can go for miles. While this radio is set up as a bridge, almost all the other radios are set up as powerful access points, where they easily send and receive to the barn, for example, which is about a thousand feet away from the house. In short, I have a *lot* of WiFi radios set up as access points and one as a bridge, but all but the incoming Internet signal are on the same subnet, where this particular bridge must be set up with a static IP address because otherwise I wouldn't be able to easily log into it. |
#6
|
|||
|
|||
Noob networking question - why does \\DESKTOP\pubshare\readthis.txt not work but \\192.168.1.5\pubshare\readthis.txt work just fine?
On 13 Jul 2018 08:49:09 GMT, Arlen Holder wrote:
I'm always amazed at what people come up with when they don't really understand how to do something. BTW, do you have a *better* idea? How would you connect a desktop that has only an Ethernet RJ45 to the router, which is a bunch of floors away if you don't use WiFi (and if you don't snake more than a hundred feet of Cat5 cable through the walls)? And if you do use WiFi, bear in mind that you need to match or exceed my signal strength, where a dinky USB dongle or puny WiFi card wouldn't have even close to an order of magnitude the power of the solution I use now. Besides the fact that the dinky little USB dongles don't have the decibels needed, they are a pain anyway, because they break off as you walk by the case (ask me how I know) - and they're omni besides, which is a supreme waste of power when power is what you need and when they don't have much power to start with. A puny WiFi card plugged into the motherboard with a good external directional antenna attached would work, but the solution I'm using is, essentially, that anyway - and - it is far more powerful - hence fewer dropped packets. While a good WiFi card would likely work, the difference is that I already have plenty of spare radios, which can all transmit at (or even over) the legal limit if I wanted them to, so I have all the power I need to reach anywhere with a strong signal (which means better bandwidth). As you must be aware, the fewer dropped packets, the better the bandwidth, where those of you who have access to cable ISPs don't need to care about such things, but we who get our Internet out of the sky care about SNR, CCQ, and dBm/dBi ERP. *However, I'm always open to better, more powerful, free solutions.* If you think you have a *better* idea, let me know, but your "better" idea better have better signal strength and fewer dropped packets than mine does in order to qualify as "better". And I get all that power for free besides. The *only* drawback of my method, which I've been using for years, is that I just noticed that the transceiver doesn't seem to be passing SMB Netbios broadcasts. I'm certainly not going to buy a puny WiFi card to get worse bandwidth just to pass SMB broadcasts, since a single line in the LMHOSTS or HOSTS file will solve the netbios issues. In summary, if you have a *better* idea, then I'm all ears as I love good ideas from people who are purposefully helpful. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|