upnp

[KM]

so a user must either be knowledgeable or have a NAT router?

it sure would be quite a talked about feature, being the only p2p client to have "Must have a NAT router, those with a standard connection will need to reconfigure" as a requirement

I still don't understand why you are suggesting removing options - i think the current system is perfectly fine, if either no NAT or if ports are forwarded (basically connections are fine) then it will work fine, if not then it attempts to forward via upnp, if it succeeds then fine, if even after that it is unable to accept inbound connections then it sets itself to unable to receive connections, but with an option for advanced users to override that in settings later in case it is wrong - i really do not see why there is any problem at all with that way of doing it... anyone?

...why are you suggesting removing that option? ignoring the obvious fact that having it perform full connection tests every single time winmx starts up would cause huge delays as well as the obvious issues with servers to do the tests with, there wouldn't really be any benefit to that to justify the huge startup times and additional network operation costs (several dedicated servers would be required just to handle tests if every client started doing them all the time, a cache handling many queries is hardly anything, a test on install is hardly anything, but any substantial number of tests is quite a bit of work to handle - not to mention if the test servers had a failure then the entire network would shut down as every client started refusing connections it can actually handle fine if it wants)

random ports would be beneficial, but can not be done without editing that in winmx, yes it is possible to change the ports as winmx is starting up when it reads the settings file, but it wouldn't be practical or elegant, and would have the obvious problems with those not able to accept connections to arbitrary ports (those with manual forwarding or who have allowed connections by port numbers in firewalls etc) which would be complicated to deal with to say the least

[splashdown]

> so a user must either be knowledgeable or have a NAT router?

   No, that is not what i'm saying.  a knowledgable user will be able to set port forwarding in the router if it is required and the router does not support upnp. if users dont know how to do it, then they'll simply end up with a connection type that can't support incoming calls.


> it sure would be quite a talked about feature, being the only p2p client to have "Must have a N
> NAT router, those with a standard connection will need to reconfigure" as a requirement

I'm not sure what you think i'm suggesting but that's not it..

AT the moment, if upnp fails to map a port then, with the current default settings, the user will end up with a system that cannot make transfers, because winmx will continue to try to listen on those ports even though the router is not forwarding them. I am suggesting that, if upnp fails to map, that winmx fall back to the mode 'unable to receive incoming calls' where all connections are initiated by the client (provided that the other end can receive incoming calls). That gets the client working with the vast majority of other clients. It can be made to work better if the user knows how to manually forward ports.

With this change, the uninitiated user who knows nothing will get a working client; there is no full port test at every startup, merely an attempt to map using upnp which you'ld do anyway.

In the options, the only change would be when the user has set the port forwarding in the router manually. In which case, all they need do is turn off the upnp option (and strictly that's probably not a requirement).


>I still don't understand why you are suggesting removing options - i think the current system is >perfectly fine, if either no NAT or if ports are forwarded (basically connections are fine) then it will work >fine, if not then it attempts to forward via upnp, if it succeeds then fine, if even after that it is unable >to accept inbound connections then it sets itself to unable to receive connections, but with an option >for advanced users to override that in settings later in case it is wrong - i really do not see why there is >any problem at all with that way of doing it... anyone?

I dont think i was suggesting removing options. If i was, im sorry if i misled..

Yes, the problem is one of confusing settings and the need for SOME little knowledge on the part of the user about how his port forwarding works. You need to make the default behaviour result in a client works without the user needing to know anything about this (though it can be made to work BETTER if they do).

Also, I dont believe that it quite behaves as you say above...

In your reply, you say that it switches to 'unable to accept inbound...' if upnp fails. This is  what i'm suggesting it do. You say it already does it but, on mine anyway, it does not. if it cant force the router (using upnp)  to forward the ports, winmx still proceeds as if it is able to receive calls on the port. You get the 'waiting for incoming connection' message (indicating that it is listening on the port) which never succeeds, instead of the 'connecting to remote user' message (indicating that it is not using a port listener). it only goes into the 'unable to accept inbound' mode if you select this option in the tcp settings manually.

>...why are you suggesting removing that option? ignoring the obvious fact that having it perform full >connection tests every single time winmx starts up would cause huge delays as well as the obvious >issues with servers to do the tests with, there wouldn't really be any benefit to that to justify the >huge startup times and additional network operation costs (several dedicated servers would be >required just to handle tests if every client started doing them all the time, a cache handling many >queries is hardly anything, a test on install is hardly anything, but any substantial number of tests is >quite a bit of work to handle - not to mention if the test servers had a failure then the entire network >would shut down as every client started refusing connections it can actually handle fine if it wants)

 No way would i suggest this. The only test made is whether upnp succeeds or not.


>random ports would be beneficial, but can not be done without editing that in winmx, yes it is possible >to change the ports as winmx is starting up when it reads the settings file, but it wouldn't be practical >or elegant, and would have the obvious problems with those not able to accept connections to >arbitrary ports (those with manual forwarding or who have allowed connections by port numbers in >firewalls etc) which would be complicated to deal with to say the least

Given that winmx allows you to specify the listen port, does this not imply that the protocol has the ability to pass the port number to the connecting clients? Yes, for those with manual port forwarding, it's an issue but you make the use of random ports an option which could be off by default. elegant it certainly is; practical I dont know, given that ive not seen the source code to know how easy it would be to change what's there now.  Starting from scratch though, it would be both practical and elegant.

The problems you mention are quite easy to circumvent.  people who have manual port forwarding (the only ones who might have an issue with random ports) simply deselect the 'random ports' option and use a fixed port. If you make it off by default then the unitiated user gets a working system.

Regards

[KM]

how many years have you had winmx running playing about with settings? you seem to think your current winmx configuration is default - the default configuration is not what any operational winmx is set to, as soon as you run winmx the first time you are no longer the default blank configuration

when you first install winmx it runs a setup wizard, which performs the tests to see if you can accept connections, if not then it doesn't listen for them - this it did on your computer (assuming as you say your computer was unable to accept the connections), you then went and changed these settings to listen anyway even after winmx had set itself to not, this is not default behaviour this is you changing settings and nothing should be done to prevent you doing that, if you are prevented from changing settings then it means that people who do know better than some automated detection are unable to configure it properly - what the user says the configuration is should always take priority over guesstimates from automated tests

it would be trivial to modify the winmx source code to add a random port feature, you fancy sending us a copy of the source code so we can do it? nobody has it, that is why there is a patch to fix it and to add the relvant stuff that can be done by a patch (like filtering data) rather than just a new winmx version

making winmx listen on a different port is easy for a patch to do, making it actually use that other port is completely different as it would need to intercept every single type of communication where winmx sends out its port number and modify it, at the same time making sure in the case of primaries that it does not touch some of the data for secondary users connected through it but does other data for secondaries (which btw looks exactly the same if it came from your MX or from someone elses MX that s connected through you)... it is not practical to do

[splashdown]

I take the point about the software, though it is difficult to reconcile the fact that you say the source is unavailable yet manage to make substantial changes to it.  I assume there is some sort of callback mechanism that expects certain functions to reside in a DLL (and of course new dlls can be written). Is there a source of info that tells us which bits can be updated and which can't? otherwise it's pointless making suggestions for changes.

While I think you're doing a great job with updating winmx, i cant help thinking that it's a bit of a losing  battle if you dont have the sourcre code. its like plugging a massive leak with your thumb. A new client is undoubtedly needed (and im sure others have said similar things so please dont slag me off for suggesting it).

on the ongoing question of my upnp suggestion, i think it's clear that im banging my head too hard against the proverbial wall.  i believe what i said is sensible (though whether it's doable given the stgate of the source code availablity is another matter) and you don't so we reach an impasse. All I really need to establish is why my system doesnt handle the upnp as expected. the test shows that the router supports it (at least as far as utorrent is concerned) so i shall await my next winmx restart before proceeding with further tests. thanks for all your assistance and interesting discussions on upnp implementation.

regards.

[SamSeeSam]

Personally,
the fact that so may users have come back does show that the battle has not been lost.
Nor is it likely to be lost anytime soon.

Cheers

[Bearded Blunder]

What you said would disable many working setups, as KM pointed out, & leave many others who might actually seek assistance configuring in passive mode, unable to transfer files between each other (the notorious & misleading "both users firewalled" error) the current situation with upnp is in my opinion is the best that can be done.. either it works (many cases) or a user is in the exact SAME position they would be if it wasn't there....

Well actually they're way better off than under frontcode, as the online help button directs here.. rather than to an unhelpful "under construction" message.

[splashdown]

well, ive not had a chance to restart winmx and test ports. Although the router has upnp enabled and the upnp box is ticked in win,mx, together with the 'listen on specific ports' options being set, i stillo got no incoming calls. i used the canyouseeme.org tool to check the port and it was not accessible. so either the upnp support is incomplete (did i not read that it didnt confirm to the 'standard'??) or something external is blocking the data. i tried a random different port - 7301 - in case the isp was specifically blocking winmx but no joy there either.

Any other suggestions would be welcomed. Are there any other specific ports that can be used as an alternative?

thanks

[KM]

if you happen to have ethereal/wireshark/simiar installed then a dump of the traffic to/from the router when it's starting up may be able to locate a bug in the upnp forwarding code, however as i said it should be even more compatible than a per-specs implementation, as it sends requests that fit specs, but the responses are interpreted very loosely (looking for the thing it wants, rather than parsing the responses fully and looking for the thing it wants in the exact place it's meant to be)

the only case I've heard of where it didn't work was with the original XP firewall being enabled (which blocks the UDP packets used, causing it to not function) - in that case another program using the windows libraries may be able to forward ports (as windows allows itself through the firewall) whereas programs doing the upnp themselves can not, and yes there is a very simple reason it does it itself rather than asking windows to do it for it - because only certain windows configurations support upnp (XP or later as a bare minimum requirement, with several non-default settings), having it do it itself allows it to function on any system

[splashdown]

i have windows firewall enabled but the exceptions list clearly lists winmx (twice!). this is the firewall with SP2 on XP. it also shows the 'UPNP framework' as an exception if thats relevant...

i do not have ethereal etc. but i can doubtless install it and run whatever test or dump you suggest. what parameters would i need to look at the pnp protocol working?

thanks

[KM]

"host <router IP>" as the filter (for example i'd use "host 192.168.0.1" as the capture filter)

the SP2 firewall is normally fine with it as it does it by program not port, it's just the older one that does it by port, then it blocks the UDP replies (which are for a dynamic port)

[splashdown]

Having now done a few tests with winmx upnp support and completely failed to get it working right, ive become convinced the support in winmx is somehow buggy. I use a linksys wrt54g router where the upnp facility is enabled. At least two other applications work successfully and open the required port (tested with canyouseeme.org).

To summarise:
   winmx tcp port - 6699
   upnp switch     - enabled
 
symptom
   canyouseeme.org sees the port as unavailable.
   systems times out in a 'waiting for incoming call' state on EVERY transfer

If i try this with utorrent and soulseek applications, then the port is available as required and these applications work. I also use emule and various bittorrent clients which i think use upnp too and they all work.

Ive tried a range of ports on each application and each does the same thing so i dont think it's the isp blocking the port (though maybe there's a range of ports around winmx that are blocked - can someone recommend a list of other ports to try???)

Possible causes for this are:

  1. the winmx upnp support, which KM has already stated is not quite standard, is sufficiently non-standard that the wrt54G doesn't accept it.

  2. ISP blocking a range of ports around the 6699 one. If so, this might cause random failures for other applications (EG FTP's data transfer listener) that happen to select that port.

  3. My configuration is corrupted or incorrect. Ive reinstalled the app and triple checked everything so dont believe this is the problem.

  4. The wrt54G router is somehow buggy in its upnp support. Cant find anything about this on the web and it seems to work with other applications.

Have i missed any possible causes?

So any thoughts greatly appreciated.

BTW, sorry wasn't able to run ethereal. For some reason it displays no packets at all on my interface. I need to dive in and figure that one out before proceeding with a trace.

[KM]

a WRG routers work with the patch, being the most common it is well tested (the various varieties are pretty much identical apart from a few hardware changes)

did you try disabling any firewalls? as they could be blocking the upnp request, it is a possibility

and before you suggest if that were the case other programs wouldn't work, actually anything with a "only works on some XP systems" warning will work when blocked by a firewall as it contains no upnp code and makes no request for a firewall to block, instead windows does the forarding bypassing any firewalls - which is why it only works on some systems, and why it is completely useless for something that wants any hope of working on anything but a few systems (especially considering half of the time the required windows XP comes with it all disabled... so you need a specific OS and then still often need to change settings... making it useless)

there is the possibility of if upnp forwarding fails attempt to use the windows upnp if installed and enabled just for the very few cases where it is a firewall issue, however that is no simple task (as it uses COM which is not easy to try and implement, which is why most non-programmers just use MFC and other rubbish like that to do it all for them...) and would probably not benefit many people (as there are few cases where one may work but not the other)