jpg153 wrote:Hi,
I thought I was specific enough..obviously not.
Hello,
I am sorry to say this, but I think you are not precise enough.
The problem is not with the package transfer from and to the distributed.net servers. This runs smooth.
I am crunching since many years and I started under OS/2. So I am a member of the "Team Warped (OS/2)" since long.
The team mate is running his own statistics server, giving some more details to each box and some graphical output.
So, it is exactly this connection, which I named "my.server.net" which got the problem.
It is a functionality/output of the dnetc client which is directed to "my.sever.net:250" - but which does not work
on this Salix-Box. It did in the past until I moved the machine and got a new ISP (including my incompetence to locate
You moved the machine or you moved your working Salix installation to an different machine? And then the statistic data transfer did not run anymore? Or was it after switching to a new ISP?
Maybe it has to do with ISP or so, but why does Windows7 do the thing?
[...]
Normal ping returns at least the IP address, but packages get lost.
ping returns the IP address only, if resolving works. Maybe you have a typo in the domain name.
Let me try another way:
The first approach:
You told about Salix14.1-64bit and Windows 7 in your first message.
Is it one computer with two OS installations on it? Do you use firewalls running on the OSes? The firewall on Salix could be configured differend (after moving).
Do you use proxies now?
Are it two computers? After your second message, I believe there are two. If so, do you use a (DSL-)router? Do you use a (/an addional) firewall on the router? The firewall on the router could be configured differend with respect to the two network port.
The firewall(s) could suppress your "dnet" packets. A firewall filters each packet based on some information from the packet. The port number is one of this information for e.g. TCP and UDP protcolls.
Your port 250 is not in the list of the system ports also called "well-known ports" (ports 0-1023). Neither is it in the list of registered ports (ports 1024-49151) nor in the list of dynamic ports (ports 49152–65535).
The firewalls and the ISP may filter out packets with unknown or unwanted port numbers. But you say, its running on your Windows 7 installation. Then it can not be the ISP, but a firewall or a proxy.
The second approach:
There may be a very different reason causing your problem.
With respect to your example "my.server.net", that is (almost) a fully qualified domain name (FQDN). After it is relovlved, it gets an IP address like 50.63.202.104 . A combination of FQDN and port number or a combination of IP address and port number is nothing. The port number needs to be assigned to a protocoll from the transport layer, like TCP or UDP. The port number then is used together with a protocoll from the application layer, like HTTP, FTP, SMTP, ...
Your webbrowser uses HTTP and a known port number automatically and can use HTTPS and FTP. But what does your dnet client use automatically to transfer the statistic data? If this progamm is simple enough, it will need an exact configuration for the URL. Have a lock to your Windows 7 dnet client configuration.
Is there something like
http://my.server.net:250 or
https://my.server.net:250 or
ftp://my.server.net:250 or smtp://my.server.net:250 or so on? How did you configure it for your Salix installation in comparison? If you only use my.server.net:250 and the dnet client has no default protocoll built in, then I think that is the reason.
There are other reasons possible, but that is already cluttered.
Good luck.