WireShare and Windows 10 - Not Connecting
 

I recently had to reinstall Windows due to a hard drive change and WireShare no longer connects to the network. I searched this forum hoping to find a fix but to no avail as none of the indicated fixes refer to WireShare. I tried the other clients (clones) and while some do work straight out of the box, others don't and you have to apply a fix suggested in the sticky threads.
I tried everything suggested in the fix threads but nothing works - it looks to me like the only solution would be a fix like the ones for the clone clients but there isn't one for WireShare even though it should be since WS is the successor of LWPE.

Windows 10 (1809) running as administrator.
Windows Firewall (I added WireShare to the exception but no avail)
Connection type: Cable (fiber)
TP-Link TL-WR940N (everything is set up as UPnP)
WireShare 5.6.6. & Java 8 update 191

You can download the gnutella.net file and replace the one you have. But WireShare needs to be closed and not sitting in the Tray whilst you do it.
http://www.gnutellaforums.com/connec...t-connect.html scroll down to the REPLACE gnutella.net FILE section and choose gnutella.net via MediaFire link as these days it's the easiest to download.

Hi,
Thank you for your reply.
I already tried that, I will try it once more since I'm not exactly sure which one I downloaded so I'll give it a try with your link.
Worth noting here - there was no gnutella.net file in the WS folder in %APPDATA% to begin with.

That's odd and should not be the case. The file should be inside \AppData\Roaming\WireShare
Did you have your WireShare port forwarded previously? If yes, it might be worth checking it is still valid after you reinstalled Windows. There's a minute possibility some routers might be affected by the OS reinstall, though in theory this should not happen. One exception might be the local LAN ip when a static ip is set, as this setting might have been lost.

Edit: oops you said it was set up as UPnP, my mistake.

I just reinstalled WireShare (as administrator) and still there is no gnutella.net file in the appdata folder. I will try to copy the file you suggested in there and see if that works.
EDIT: Still not working, stuck at Connecting...

So you definitely put the gnutella.net file into:
\AppData\Roaming\WireShare

WireShare has GWeb support so it should be gathering hosts from web caches to help it connect.

Are you doing this at home or work? If at work, there might be other reasons you cannot connect.

Yes, I put it in that folder. It's at home. Nothing changed in my setup except a new hard drive and a reinstalled Windows (I had Windows 10 before as well).

When you previously used WireShare did you ever check the Advanced Tools window and notice whether it said the program was firewalled or not behind a firewall?

Port forwarding is more reliable than UPnP but depending on the brand and model of router can require a few steps. If you wish to try port forwarding you first need to set up a static ip address:
1. https://portforward.com/networking/s...windows-10.htm
The first number will depend upon your router. It might begin with 192. or 10. or another number. So if for example your router uses 192.1.1.1 then you could set your computer to use 192.1.1.2 or 192.1.1.9 or 192.1.1.23, etc. and this LAN ip number will not change. But the static ip address must not clash with any other computers or devices on your LAN at the time you set up the static address.

2. Find your router brand and then model there: https://portforward.com/router.htm
Choose LimeWire as the program to install it for as the instructions are similar.

3. Whatever port you choose to port forward you will need to also put into WireShare's settings: Advanced > Listening Ports > Manual Port Forward section.

By the way, I just replaced the gnutella file at MediaFire with a larger version you can try.

I did not check. I went into Advanced Tools now but it doesn't show anything related to that. I remember Limewire had an icon in the bottom left which showed that info but WireShare doesn't.
I also checked the router and the ports seem to be forwarded correctly through UPnP both UDP and TCP. They point to LimeXXXD3667CBF18 (XXX-TCP/UDP respectively)
Also, I updated the gnutella file with the one you provided just now but still nothing.

Something I forgot to mention, double-check your other security programs to make sure WireShare is on their exception list on the chance they might be preventing the program connecting.

Did :/

It won't show the firewall status if it's unable to connect or contact another host.
hmm, that sounds like it's a rule set up for limewire. Do you think that's what the LimeXXXD represents?
If it were a port forward rule then a new one would need to set for WireShare.
Router rules set up for specific ports or applications can only be used for a specific computer on the network and only one specific program (a different port for each program.) A new rule needs to set for each program. Not too different to the Windows Firewall approach.

LimeXXXD - I replaced TCP and UDP with XXX. Here's how it shows up.
Note: it's not there by default - it only shows up when WireShare is running. I can do a test and set it manually for WireShare if you think it will make any difference but previously it was running on UPnP, I didn't touch the router's settings.
http://i68.tinypic.com/2n16z5u.png

Yes it might simply be the name of the rule rather than the application.

Have you checked your internal ip address to be sure you are actually running on the one listed? However as you said, if it only shows if WireShare is running then sounds like that part is fine.
A quick google: (1) Click the Start icon and select Settings. (2) Click the Network & Internet icon. (3) To view the IP address of a wired connection, select Ethernet on the left menu pane and select your network connection, your IP address will appear next to "IPv4 Address".

Perhaps try changing the port number you have listed in those rules. Also change it to the same port in WireShare's settings. Perhaps change to a port number in the 30000 or 40000 or 50000 range.

I can tell you from experience if any other program has run using the same port forwarded port earlier in the same computer session, then the router will make that port unavailable for any other program. (My suspicions you might have run LimeWire, etc. using same port prior to running WireShare.)

Note: I'm no doubt in a different timezone and might need to continue discussing this later if the problem is not solved. Super late here now. :D

Checked the IP Address, it's the same. Checked port in WireShare, same. I noticed the port changes every time you install/reinstall WireShare so I'm pretty sure that's not the culprit, I can do a test and change it and also make the manual forwarding rule.

Tested the manual port forwarding - no difference, and it doesn't link to a specific application, just IP address. The UPnP tab just shows which app is using that port so probably the name is hardcoded into WireShare (they didn't bother to change it or something) :)
Still no go...I can't for the life of me figure out what might have happened. The only thing that changed, basically, is Windows, so I'm pretty sure this is OS related.

Your experience has taught me a little (re: UPnP.) Windows is not my primary OS and only use it for testing.

Sometimes a reboot can help. That's as long as it does not affect anything else you are doing on the computer.

Is port forwarding out of the question? Just a suggestion. ;) I always port forward my p2p apps because it's far more reliable for long sessions.

As far as I know, Windows does have a habit of resetting some security settings to default during updates (including some firewall settings.) Have you checked Windows Defender or that another security app is not blocking WireShare to the outside world? Re-check any system setting that might possibly affect WSHR.

Talk later, I'm off to bed for now.

Thanks for your help.
Port forwarding is not out of the question but I did test it (manually set up port forwarding) and there is no change.
I checked the firewall settings again and again, everything is at it should be :/

Did you have any luck?

I did some kind of update for Win 10 and then installed WireShare. I had the identical problem with no hosts showing in advanced window. I set up port forwarding, added WSHR to the Windows firewall exceptions. I don't know why but the only thing that appeared to fix it was to go to the WireShare program folder & set the properties of WSHR to open as Admin. This then set the program to connect and non-firewalled. However you said you installed WSHR with admin permissions which should be the same thing. Perhaps you can re-check this.

Attachment 6960

Will give it a try and post update.
EDIT: Okay, here's an interesting take - I tried a previous version of WireShare (5.6.4.2) and it worked straight out of the box, no firewall exception needed, no run as administrator, nothing, just install and run - worked. I thought about trying this earlier but I couldn't find previous versions for some reason, but now when I checked the Google Drive link, I noticed there were 2 previous versions available so I gave it a try.
Any idea why this one works out of the box and 5.6.6 doesn't?
I tried what you suggested with the version and setup I had from yesterday but it didn't work. Firewall exceptions were added (both outgoing and incoming), I changed the default listening port and made sure it was being forwarded from the router, I ran the program as an administrator after which I set its properties to always open as administrator...still nothing. I thought that maybe something was off with the installation so I thought I should redownload the installer from a different source and start clean - that's when I came about the older versions.
Below you have the advanced tools coonections that are showing up right now, does everything look good to you?
http://i67.tinypic.com/mqyww.png
http://i67.tinypic.com/s3359y.png

That's good to hear you at least found a version to work for you. I'm not sure why this would be the case. However on Windows there has been a (LimeWire) history of something like this happening where one version works better than another.

The only thing that is not working properly is either your UPnP or port forwarding or you have not given a Windows firewall exception, however this rule should already exist from your previous version. "You are behind a firewall and support firewall transfers." You will get better search and overall performance if you can instead get it to be like mine "You are not behind a firewall"; your WireShare would be able to join the DHT for superior searches and communicate via UDP which is where most communication between programs happens. 70% dropped messages via your connected ultrapeers is notably high. There will also be some other firewalled hosts you will not be successful for downloading from when your WireShare is firewalled.

I suspect your port forwarding might have an error somewhere. Does the port forwarded match with WireShare's connection port? Did you set up a static ip address? Did you set the port forward rule to your computer and not accidentally set it to another device on your LAN? (I've made this error a few times, mainly because my multiple Windows & Linux have obscure ID's) :D

I removed the previous exceptions to start fresh, probably that's the reason. The screenshot shows the window after starting wireshare right after installation, not adding anything to firewall exception.
However, I found this while looking at Windows 10's firewall exception list from
Control Panel\System and Security\Windows Defender Firewall\Allowed apps
Note this is not the advanced settings page where all the rules are showing.
Also a question here - do I have to allow for both Outgoing and Incoming connections? Or just outgoing?
http://i65.tinypic.com/28guqsj.png
EDIT: The checkbox is left for PRIVATE and right for PUBLIC. Only private is checked.

AFAIK you don't need Public, even if I did enable it for WSHR. Inbound Rules are sufficient. Check to be sure there's two for WireShare; one will be for UDP and the other for TCP as can be seen in the rule's properties, Protocols & Ports. It will also say it applies to all ports which is handy if you choose to change the port.

Alright, I'll set it up.
EDIT: I must be doing something wrong...
I checked the inbound rules - there were 2, one for each protocol, UDP and TCP. So I set an outbound rule, for any protocol - still behind a firewall.
I deleted all the rules and created a new one, inbound, any protocol and I'm still behind a firewall. The only firewall running is Window's.

EDIT2: I added manual port forwarding on the router, still shows behind firewall.
I also tried running WSHR as admin, no luck.

EDIT3: So, the issue is not Window's firewall, I turned it off just for testing purposes and it still shows me behind a firewall...

EDIT4: Tried WSHR 5.6.5 - working (same issue though, behind firewall)
WSHR 5.6.6 - still not working xD
I think the issue is the installer - the 5.6.6. installer has the shield icon from Windows while the 5.6.5 and previous don't. Even though I did run the installer as administrator. But I might be wrong about this assumption.

May I ask what connection equipment you are using? Brand and model router, etc.

Sorry, been away for a couple of hours.
The router is TP-Link TL-WR940N

According to https://portforward.com/tp-link/ that model is not listed but the others appear similar to each other referring to the process as Virtual Server. Double-check the setting to be sure it includes both UDP and TCP or All (protocols.)

Have you checked the UPnP section in the router's control panel to be sure it's enabled? You can switch WSHR between either UPnP and Manual PF to see if either works to fix the firewalling issue.

Are you certain you set up a static address?
https://portforward.com/networking/s...windows-10.htm the first three segments of the address need to match the router's address, but the last number must be different. In your case it looks like your present internal address is 192.168.0.104 and the router's address is 192.168.0.1 which looks fine. Without a static address, if there is more than one device on the LAN utilising the router, then each time you reboot your computer you can potentially get a different address and the port forward rule no longer works. Port forward rules are set to specific addresses.

Do you use any other 3rd party security software such as firewall or anything that might be affecting WSHR's performance? At least your WSHR can connect, but something is probably blocking the incoming UDP messages.

I don't use any 3rd party software that might block WSHR.
I double checked the UPnP and it has 2 forwards for both protocols.
The IP is correct, it doesn't change....
I think the router has a built in firewall...I might try to disable that and see if that works...but isn't the port forwarding made for that situation specifically?

EDIT: I disabled the SPI Firewall in the router's settings but I'm still showing behind a firewall....now it's starting to get frustrating because I don't know what can cause this...
I disabled Windows Firewall....I disabled router firewall and I'm still behind one? what the hell.

Lets hope my question is easier than evils ; is wireshare 5.6.6 compatible with my hp windows 10 desktop computer .

I recall having a firewall issue with Win 10 after Win OS update earlier last year. I cannot recall what I did to fix it though. It is looking like a Win 10 issue with the firewalling.

My ignorance: I found this note about allowing apps through Win 10 firewall online:
"Select Private if want the app to communicate in the local network. Or select Public when the app needs to communicate through the firewall on the internet. You can select both options as needed."
My firewall rules are Private & Public. However since you tried disabling the firewall, this is obviously not the issue.

No reason why it should not be compatible with any Win 10 system. I tested WSHR out on Win 10 with both failure and success as mentioned in post #19. Though there's apparently different Win 10 variations. However evil4ever's experience is 5.6.6 would not connect. Different hardware, Win 10 variations including 32 & 64-bit, & desktop/laptop, and personally customised variations between everybody's system can sometimes mean different results for running particular versions of software.

There is an off-chance that 5.6.6 does not work due to the same firewall problem which 5.6.5 has but not "fully" if that makes sense.
I don't know what else I can do...honestly.

There is one last thing you could try ; if possible ,please go to update and security in your windows 10 settings , click on troubleshoot ,click on incoming connections ,select the last option which is something else ; this is where i am stuck and going batty ; they want wireshare in some exe form or format ; good luck

All you have to do is point it to the wireshare exe file which by default is located in Program Files (x86) -> WireShare.
Good idea, sadly it didn't solve anything...
I think the problem is between Windows 10 and WSHR...for sure.

I received a message about someone's experience with Win 10.

She reinstalled Win 10 a few months ago. Two out of three apps connected beautifully straight away after setting the forwarded port within these program's options. But one was problematic with firewalling.

In the end, to fix the program with firewall issues she removed that program's rules within the router firewall settings & within port forward settings, apply the changes, re-do the Windows firewall & Port Forward settings (using the same port number used previously), apply the changes, restart the program & it worked happily.

She installed WSHR 5.6.6 & set to UPnP and had a turbo connection within about 2 mins. Switched to manual PF using a port already forwarded within the router... turbo again. Removed the small gnutella.net & replaced it with the larger MediaFire download... turbo again.

Note: When you install WSHR it will most likely ask whether you want to allow WSHR to make changes to your computer. Clicking 'Yes' will make an exception in the Windows Firewall for WSHR.

So removing both Windows firewall and port forward rule(s) for WSHR and re-adding them might fix the issue.

Yes, that was me lurking in the background :lmao:


evil4ever - slight differnces here: I didn't have WS running successfully before reinstalling Win 10 (use other Gnutella clients mostly).


When I did download WS yesterday as a test, it had a gnutella.net file. Almost half the size of the gnutella.net file hosted on MediaFire but nonetheless something there. I wondered whether maybe the WS that you originally downloaded was a bit corrupted (hence you had no gnutella.net file to begin with)? Did you download your version of WS after reinstalling Windows or did you have the installer saved?



And my problematic app was uTorrent. Phex & GTK-Gnutella connected without a problem but for some reason uTorrent was stuck despite going through all options several times. Even though it's not WS, still a p2p app with stubborn connection failure!



And as LOTR said, my fix was completely removing all rules within router config (didn't tuch Win firewall at all), rebooting the router & starting from scratch.

I already tried all of that :/
My router's firewall doesn't have any settings, just an Enable/Disable function.
I recreated WSHR's firewall (windows) exceptions a few times....
uTorrent works out of the box with UPnP...

How about the virtual server section? https://portforward.com/tp-link/tl-wr940n/

(portforward.com did not have this specific model on the TP-Link list but I found it via google. Not the first time this has happened, it's happened a few times. I presume they sometimes forget to add new models to the main list.)

This is the actual port forwarding method. Don't use the xbox port mentioned, select a port of your own choosing and ensure both TCP and UDP are enabled for the process.
If ... ... then it might be worth re-trying. :)

Also ensure you have a static internal ip address as noted in post #8. Otherwise the next time you start your computer the computer might have a different internal address and the port forward rule no longer works. Port forward rules are set to specific LAN addresses.

Sorry for the lack of a reply, I got sidetracked by more important stuff.
I re-did the settings, the port forwarding, everything, I'm still showing behind a firewall but the dropped messages % dropped close to 0%...
I don't know if there is a fix for this...
Initially I removed everything, the port forwarding, the firewall exception.
Started up WSHR and after a while of trying to connect it prompted me for the firewall exception so I clicked allow, after that it managed to connect - a note here, the port forwarding was not set to UPnP, it was set to manual but the actual rule in the router's settings was not set either....I went ahead and set that up as well.
Here is how the connections look like:
Attachment 6963

Thanks for going to the effort of the snapshot hosting. I apologise and hope you don't mind but decided to edit the image so that it does not list the entire address of the hosts for their privacy. I also shrunk the image slightly.

Glad to see you are able to connect. However it would be preferable if you were able to fix the firewalling issue. Something is amiss. Either the UPnP is not working as it should or the port forwarding process is not properly set-up or something else on the computer's set-up is causing the firewalling. The question is to figure out what is causing the firewalling. It's my guess it is purely UDP firewalling and TCP is ok.

Keeping in mind UPnP and port forwarding are two different independent approaches to battling the NAT issue with routers. Only one can be used at a time.

If UPnP is used then it needs to be enabled within WireShare and if the router has a UPnP on or off option then it needs to be enabled.

Portforwarding requires the manual port setting within WireShare, and a TCP and UDP port forward rule set within the router. With your router I believe the port forwarding rule is referred to as a 'virtual server' rule. Some routers you can set both TCP and UDP within the same rule. But for some routers it is sometimes better to set each of TCP and UDP as separate port forward rules for the same port.

Did you try setting up a virtual server rule?

Hi,
Yes, I did and I also changed WSHR's settings from UPnP to manual port forwarding when I did that. I didn't create 2 separate rules for TCP and UDP as the option enabled me to set the rule for both protocols. My uTorrent is set on UPnP and is running just fine...no issues....
What baffles me is the fact that I disabled both the router's firewall as well as Window's and yet WSHR was still showing behind a firewall....unless it has something to do with the ISP's equipment...I don't know what could cause this. I'm 100% sure the ISP is not blocking the network because if it did, I wouldn't have been able to connect at all...

Just a wild thought, maybe try logging into your computer using a different user account & then running WS. Any difference?

Some ISPs provide their own firewall ( & so people can end up inadvertently using 2 firewalls) but if that was the case then I think you'd see issues with uTorrent as well. I can't find any info to suggest that your ISP interferes with P2P traffic.

I'll give that a try, don't have the time right now to set it up though.

Just tried that, unfortunately I have the same issue....basically it's connecting, TurboCharged connection but the downloads are either stalling out right after I start the download or work with an abysmal speed of under 50kb/s.....

Right click on the search tab > find more results.


Change ultrapeers that you're connected to. In WS, go Tools > Advanced Tools. You'll see the list of your ultrapeers - right click on the UP that you've been connected to for the longest time > Remove. Now repeat your search. If no differnce, remove the next UP and so on...

Ultrapeers are unfirewalled users with fast connections who handle lots of search traffic, so changing UPs can change the search results that you see.


Don't forget that the network's dynamic - as users in different time zones log on & off, files being shared (and hosts' bandwidth) will change. So try searching at different times of day.


Try varying your search terms. If you're searching for music, search for artist or album, rather than song title.

Same issue? You were firewalled and unable to connect. Then firewalled but able to connect. You made no mention of download speeds prior to your last post.

Do you share files?

Keep in mind not everybody has a fast internet connection particularly for uploads. Download speeds depends on the upload capacities and upload bandwidth the uploader has remaining.

There's still some people in the world using dial-up connections which means downloading from them at speeds ranging from 0.1 to 5 KB/s. Some satellite and other wireless types of connections whilst offering ok download speeds for the host have abysmal upload capacities not much better than dial-up.

Some hosts might be uploading to anywhere between three to 25+ hosts and their bandwidth divided unequally between them. Their upload speeds will also fluctuate for varying reasons.

If your WireShare is firewalled then it will mean your WireShare will not be receiving UDP messages.

Search and download speeds can be hampered by firewalling. Relying on TCP connections for most communications will mean a lot more overhead as TCP is not the ideal communication protocol.

An example of something different: the speeds between USB-2 which in theory has a speed of 480 mb/s versus the now obsolete FireWire 400. FireWire was actually faster due to USB-2's heavy overhead, in practice somewhere between 15-35+% overhead loss of speed which means it falls lower than FireWire (30-40 MB/s versus about 50.) Sounds like a strange comparison right!? Actually not so strange because TCP also has an overhead and is a notably slower process than UDP. As a general rule, TCP requires a greater amount of communications traffic for the same result as UDP (which has far less overhead and has a faster communication protocol overall.)

I've been using WSHR for some time, thanks for the pointers, I'm aware of how it works :) I'm just puzzled as to why this is happening, it was working fine before I reinstalled my Windows.
The issue I'm having right now is that the search works, SOME downloads work, but most of them just end up stalled, I did a quick test, searched for a song, got like 300 results, I started to download all of them, only 3 downloads actually worked, but the speed was abysmal to say the least.
And yes, I do share files obviously :)

Shared files on the network are cached by ultrapeers. If a host leaves the network or removes some or all of the files they are sharing it can take a notable amount of time before the cached the files are removed by all involved ultrapeers. This can mean one or more hours. That is one downside of DHT for example (though the advantages of DHT outweigh its downside.) So there's a high chance a percentage of all search results are redundant (the host sharing the file is no longer on the network or sharing the file.)

I am aware some people remove their shares mid-way through sessions. They obviously have their program set to automatically share downloaded files (the default of most programs.) I've witnessed this first-hand many times after browsing them. I was able to download one or a few or maybe only a part of a file then it stops. A re-browse of the host shows them no longer sharing the file. This always annoyed the life out of me. :( These are people who probably don't really wish to share files but they are ignorant how to properly configure their program. (I've also witnessed this whilst they were presently downloading from me & has happened many times over the years.)

It appears browse-host can also be affected by DHT as it does not always update the host's shares properly between browses.

Hello,

Some time ago WireShare (version 5.6.6.0) stopped connecting. It was white-listed in the Windows Firewall, anyway I removed it and re-added it again. It did not help. I uninstalled it and re-installed it afresh but to no avail. There is no gnutella.net file in WireShare profile folder:

and I think there has never been such a file. WireShare had been working fine for years but now it simply cannot connect. This happens under Windows 8 x64. Any suggestions how to cure this connectivity problem? If the problem persists I will have to switch to Shareaza.

Download a fresh gnutella.net host file from https://sabercathost.com/folder/117312/gnut_file and copy-paste the file into C:\Users\UserAccountName\AppData\Roaming\WireShare
Keep a copy of the file in case you need it over the next 12 months. After that if needed, download a fresh copy as it should have been updated by then.

Did you not use WireShare for a month or more?
I can't remember which WSHR version but bigjx decided to re-add the code to delete the gnutella.net file if WSHR has not been used for 28 or more days. I don't agree with his approach but that's it. His idea is that WSHR would then download hosts from web cache to create a fresh file but unfortunately the main webcache WSHR uses has been misbehaving over the past year.

Since WSHR last connected for you, have you installed or updated any security softwares? One of them might be blocking the connections.