Netspace Causing more problems.

Porkster · Unread post by **Porkster** » Sat Apr 12, 2003 9:57 pm

Looks like Netspace's Proxy is causing a lot of hassles for everyone.

The share group may not return to normal until the problem is resolved.

Makes the idea of moving to another provider very tempting.

johnd · Unread post by **johnd** » Sun Apr 13, 2003 7:56 pm

Porkster wrote:Looks like Netspace's Proxy is causing a lot of hassles for everyone.

And the problem is...?

Anach · Unread post by **Anach** » Sun Apr 13, 2003 10:26 pm

Porkster · Unread post by **Porkster** » Mon Apr 14, 2003 12:48 am

johnd wrote:
Porkster wrote:Looks like Netspace's Proxy is causing a lot of hassles for everyone.

And the problem is...?

1 of 2 problems, I think.

1.) A local subnet mask issue that stops people seeing other netspace users in the same network, which doesn't explain why IP's are resolving to the wrong ones.

2.) Yet another proxy web server problem. For a "web proxy server" to work it needs to have all traffic worked out before it get to it or or works on the data itself. That work is to determine if data is web based or not, and if it is then check the cache to see if the requested data already exists for RESALE.

The tech people in tassy that work on behalf of netspace proxy, seem very bad when it comes to setting up proxy setting.

When the proxy works on the hijacked packets, it might be attaching the wrong IP's to the IP headers or incorrectly doing its own tunneling methods.

As far as I'm concerned it time to get rid of the proxy. It's only slowing ping times down for ALL DATA and also it's not worth having a proxy in this day and age with the amount of web content consumed, compared to other data requests.

.

johnd · Unread post by **johnd** » Mon Apr 14, 2003 1:06 am

Transparent proxies only catch http traffic, not P2P traffic such as DC or Shareaza

johnd · Unread post by **johnd** » Mon Apr 14, 2003 1:32 am

Porkster wrote:
johnd wrote:
Porkster wrote:Looks like Netspace's Proxy is causing a lot of hassles for everyone.

And the problem is...?

1 of 2 problems, I think.

My last reply crossed with Porkster's comments, so.....

1.) I presume you are talking about the issue where you can't see everyone in Shareaza's neighbours window. This is normal. Shareaza, and other peer-to-peer discovery-type clients, such as gnutella, will never be able to guarantee this. It is simple...routed peer-to-peer discovery mechanisms never return 100% of clients. This has nothing to do with subnets, or proxies, or any similar thing. It is a fact of life. And becomes much more apparent with small, closed networks such as the Tassy Netspace-restricted Shareaza group. For instance, open your netbios ports to the internet, and see how many peers your can see. Not many, if any. This is because routed protocols do not do peer discovery well. If you do a netbios port scan you will discover many more, but only because you test each and every address.
DC, and similar P2P applications show every member because they are specifically registered in a central location, and do not use discovery mechanisms.
IP's are resolving to the wrong ones because of delays in dynamic DNS services picking up changes.

2.) I can't really understand what you are saying here. Transparent proxies work by traffic classification, and then routing to the proxy server. The proxy server does not see all traffic, just web request traffic. As for "RESALE"?????

Your next two comments make no sense. I can't reply in your terms. I have no idea what you are talking about as you are making up or using terminology to suit yourself.

Your last comment is self-contradictory. Web traffic is increasing enormously. This means that proxy servers are essential for any ISP to maintain reasonable response times and ensure prompt request handling. If anything, we need more proxies located at suitable points in the network topology. This "day and age" require more proxies, not less.

There, I've had my say. Please ensure you understand how these things work before making ridiculous statements like this.

BTW, it is still trace ROUTE, not trace ROOT.

[EDIT] Ths is not an argument about which is better, Shareaza or DC. It is simply an attempt to make people understand that these two applications work in very different ways. If you understand this, then you will understand why things look different in terms of a list of "neighbours".

Anach · Unread post by **Anach** » Mon Apr 14, 2003 11:36 am

ah.. whirlpool.. i love it..

It feels just like home..

Sponge09 · Unread post by **Sponge09** » Mon Apr 14, 2003 10:59 pm

ok Johnd I dont even pretend to know how all these proxies and every thing works I dont really need to know either, but as from last friday shareaza has not been working at all not just a few users not working I can not see anybody send or receive any thing at all had been working fine for 1 month prior I did not change a single setting, a few others user I asked have not changed a single thing yet it wont work. so from this fact all I can say is somewhere some how netspace has changed something !!!

johnd · Unread post by **johnd** » Tue Apr 15, 2003 1:15 am

Sponge...

I think one of the problems is the discovery service
http://cgi-bin.spaceports.com/~tassy/gcache.php

Should this have entries in it pointing to bigpond users in Victoria? It also has some huge ranges in some of the entries, such as 144.137.*.*
This is almost certainly wrong.

Looking at the system log shows a lot of "connection refused" messages, which means that the client at the other end is specifically denying you access to their machine. Probably a problem with the security settings.

There are also some "timed out" messages, but I've always seen these to some degree and have put it down to network traffic on one or other end of the connection.

What messages are you getting in the system window? It might be helpful to include some rather than a rambling message venting your bad experiences on me.

I happy to help, but I really won't spend the time on people who act like it is my personal fault that their connection is not working.

Porkster · Unread post by **Porkster** » Tue Apr 15, 2003 1:29 am

johnd wrote:My last reply crossed with Porkster's comments, so.....

1.) I presume you are talking about the issue where you can't see everyone in Shareaza's neighbours window. This is normal. Shareaza, and other peer-to-peer discovery-type clients, such as gnutella, will never be able to guarantee this. It is simple...routed peer-to-peer discovery mechanisms never return 100% of clients. This has nothing to do with subnets, or proxies, or any similar thing. It is a fact of life. And becomes much more apparent with small, closed networks such as the Tassy Netspace-restricted Shareaza group. For instance, open your netbios ports to the internet, and see how many peers your can see. Not many, if any. This is because routed protocols do not do peer discovery well. If you do a netbios port scan you will discover many more, but only because you test each and every address.
DC, and similar P2P applications show every member because they are specifically registered in a central location, and do not use discovery mechanisms.
IP's are resolving to the wrong ones because of delays in dynamic DNS services picking up changes.

Sorry, but in my understanding this is not true.

The point I was making had nothing to do with Shareaza as a sole problem. The Netspace problem concerned all areas of Tassie Netspace. Users were getting wrong IP when they were being referenced by others.

I suggested that a subnet mask problem may exisit but I had my bets on Netspace's proxy cache. Now a web proxy server's job is mainly to work on web content but it has to determine what is web requests, therefore it still works with normal requests. The altnerative to the main web proxy doing all the work is to have another proxy layer working out which is non web content. Any EXTRA processing is a fact to cause delays in our data, other words bad pings.

Now regarding Gnutella and decentralised servers / IP web caches. It is a fact that a firewalled user will be very limited in what can be achieved when requesting from another firewalled person. This F<>F problem is a fact and affects all p2p software, be it dc, Shareaza, eMule. On emule this is termed as LowID.

On DC you get an illusion that your working in that you can connect to the main, non firewalled server. There you can chat and so called see others connected and also search for files, but that's where it stops. The next level is can two communciate on a peer to peer level and if the users are F<>F, then there is a good chance data connections wont establish and flow.

johnd wrote:2.) I can't really understand what you are saying here. Transparent proxies work by traffic classification, and then routing to the proxy server. The proxy server does not see all traffic, just web request traffic. As for "RESALE"?????.

If you can't understand the concept of; >??

* A user requesting data off a world location that consumes PAID data allocations.
* Then Netspace stores that users data and re-issues the data to other users, consuming their PAID allocation as well....
* Therefore, Netspace is RESELLING.

?then should I reply anymore to your points? Please, spare me your insults (as below).

johnd wrote:Your next two comments make no sense. I can't reply in your terms. I have no idea what you are talking about as you are making up or using terminology to suit yourself.

Your last comment is self-contradictory. Web traffic is increasing enormously. This means that proxy servers are essential for any ISP to maintain reasonable response times and ensure prompt request handling. If anything, we need more proxies located at suitable points in the network topology. This "day and age" require more proxies, not less.

As internet speeds improve, it doesn't mean the average internet browser user will view more browsing windows. A slight increase in browsing may occure as pages come in quicker and therefore the users can move onto the next topic of browsing.

A Web Proxy only dishes up web pages, not the multimedia and other addins that DSL has made people increase their data usage.

Some where in between OUR LINES and Netspace's HUB to the Internet Backbone is a proxy that doesn't need to be there and it's causing increase delays in our data transits. It need to be closed down.

Yes there was need for proxy web servers in the days of 56K'ing but they are no longer needed. I bet Netspace is selling our cached web content to existing 56K'ers...!

johnd wrote:BTW, it is still trace ROUTE, not trace ROOT.

Actually I stick to my guns on this one. I got a letter from the creator of Trace Route. He said that it was named Trace Route but he agrees that Trace Root would have been more correct name for the routine.

The problem is in language translation. You can't persume that ROUTE in german/dutch is the same as route in english which the computer industry has done. Also more points are in my favor.

You have to realise I'm not swayed by populations/opinion, I go by sheer facts, what is seen in experiments, and logic.

johnd wrote:[EDIT] Ths is not an argument about which is better, Shareaza or DC. It is simply an attempt to make people understand that these two applications work in very different ways. If you understand this, then you will understand why things look different in terms of a list of "neighbours".

You have to realize that DC is arcane. It was created in Napster era an has had near to zero improvements.

People need to grip that sharing files isn't hard drive images, it's shared zips/compressed files and executables that you use to install. Also media file shares. It is VERY BAD practice to share literal hard drive folders as in what dc does. Why? Because you can reproduce bad collections of files used to install software. You also can adopt bad file stamps that software protection may detect and hinder an install or exec.

The Neigbourhood Page in Shareaza in merely a display of the close connections. Being listed in that page doesn't indicate you can share, download and search!

If people do the settings recommend then they will have the bonues to all that Shareaza offers, currently.

Shareaza can do anything any other peer 2 peer utility can do. It only needs a chat room to gather the connected users.

.

Porkster · Unread post by **Porkster** » Tue Apr 15, 2003 1:44 am

johnd wrote:Sponge...

I think one of the problems is the discovery service
http://cgi-bin.spaceports.com/~tassy/gcache.php

Should this have entries in it pointing to bigpond users in Victoria? It also has some huge ranges in some of the entries, such as 144.137.*.*
This is almost certainly wrong.

No it doesn't point to anything if you are concluding that. That IP only refers to who can use the DCache. It is a RULE that allows Telstra users on ip's 144.137.*.* which I agree is broad and may allow Victorian Telstra to use the cache and also the Launceston Network the Nations.

It is impossible for other ISP customers to download off you as your client will block them if you have only netspace/keypoint client rules active. We have not had any Telstra people use the cache so far and it was placed in to support the Launceston Network the Nations people.

johnd wrote:Looking at the system log shows a lot of "connection refused" messages, which means that the client at the other end is specifically denying you access to their machine. Probably a problem with the security settings.

There are also some "timed out" messages, but I've always seen these to some degree and have put it down to network traffic on one or other end of the connection.

Some Shareaza users may not have their Default Rule to DENY, which will allow them to see world data, and that is their choice. The "connection refused" are world IP's that are distributed to other clients from those users that open for world data. Yet again it is impossible for those world IP's to download off you if you have your rules set. Also to note, refused links use near to zero bytes to manage.

johnd wrote:I happy to help, but I really won't spend the time on people who act like it is my personal fault that their connection is not working.

He wasn't being rude from what I can gather, he was saying there is a clear fact that Shareaza wasn't the problem to OUR WOE's. A problem that was in all areas of Tassie Netspace when regarding Netspace to Netspace requests. IP conflicts were the result.

Example, you would try to goto the Forums here and you got a WebCam hosted from another IP, or you could reference a IP on a DNS look up facility and got someone elses IP. Users has to hammer DC server to get in, as every once in a while you got the correct ip.

John I think you have mis-understood what we were discussing in this thread.

S. Traaken · Unread post by **S. Traaken** » Tue Apr 15, 2003 4:45 pm

Porkster wrote:Now a web proxy server's job is mainly to work on web content but it has to determine what is web requests, therefore it still works with normal requests. The altnerative to the main web proxy doing all the work is to have another proxy layer working out which is non web content. Any EXTRA processing is a fact to cause delays in our data, other words bad pings.

It checks if it's port 80 - if so, it's web content, else not.

johnd wrote:BTW, it is still trace ROUTE, not trace ROOT.

Actually I stick to my guns on this one. I got a letter from the creator of Trace Route. He said that it was named Trace Route but he agrees that Trace Root would have been more correct name for the routine.

I'd be interested to see a copy of exactly what you wrote him and how he replied.

People need to grip that sharing files isn't hard drive images, it's shared zips/compressed files and executables that you use to install. Also media file shares. It is VERY BAD practice to share literal hard drive folders as in what dc does. Why? Because you can reproduce bad collections of files used to install software. You also can adopt bad file stamps that software protection may detect and hinder an install or exec.

You can do this in any file sharing app - just mark the dirs as shared.

Shareaza can do anything any other peer 2 peer utility can do. It only needs a chat room to gather the connected users.

It uses much more memory (and cpu) than dc++.

Porkster · Unread post by **Porkster** » Tue Apr 15, 2003 7:54 pm

S. Traaken wrote:It checks if it's port 80 - if so, it's web content, else not.

Hmm I agree and never said any thing different. The point was that this is a process that is delaying pings and that it's not important to have web proxy servers for DSL users, especially when they are setup wrong.

S. Traaken wrote:You can do this in any file sharing app - just mark the dirs as shared.

True but other p2p software promote proper sharing, where dc promotes the bad practice shares.

S. Traaken wrote:It uses much more memory (and cpu) than dc++.

Much more? No it does not. DC's CPU USAGE peaks seem very high, like downloading and getting file lists.

Memory usage seem about average. I have alot shared at times and my Shareaza is consuming 8meg. Whoopie.. 8meg. After sharing on dc I noticed it used more.

Shareaza is close to Zero cpu usage. The only high cpu demand is when a file is being hashed and this is only when you first installed Shareaza and share.

.

Sponge09 · Unread post by **Sponge09** » Tue Apr 15, 2003 11:23 pm

Yeah Sorry if it came across as I was blaming you Johnd I had no intention of doing so, as porkster wrote I was just mentioing we had the problem without going into the technical side of things. Plus pointing out that is was working and now all of a sudden stoped. Im happy to just sit back and try every day to see if it is back working

r0lf · Unread post by **r0lf** » Wed Apr 16, 2003 2:48 am

wow what an explosive thread... I think i might go searching for a landmind or two myself...

before I rant
<-- it says newbie there, this post comes with a free grain of salt.

As for terminology, any thing that links two networks and might cache data could be called a 'proxy', but the 'netspace web proxy' is a specific machine at a specific address. For our p2p stuff I don't see that proxy as an issue. A few people here have other unrelated problems with netspace's proxy server, but i serious doubt it has anything to with the current shareaza problems. Remember we're not link networks here, we're activing trying to stay within the local netspace network.

Look at a trace between two of the members, it usualy consists of three hops. The one in the middle being lns-something.Hobart.netspace.net.au.

A good test for problems in a p2p sense would surely be traces between each other, some ips in the shareaza list work, others died after the first hop outside my lan (I'd guess those people were running firewalls). Could someone who can't connect to shareaza post a trace to me? my redirect is: butwhowill.redirectme.net

pretty please...!

Over the weekend;
The forum timed out on friday for me, some websites misreported my IP address, and Shareaza only reported three clients till about sunday. Otherwise I didn't notice any other distruptions.. but then again, I was playing postal alot.

I have noticed that the shareaza population is now 5 clients, so I'm a little confused about that. Previous posts go a long way to describe the mechanism for client discovery, but the point I'm stuck on is, it wasn't that long ago there were 10 or 11 clients in the list!! what happened to you all?

just my 0.20$ worth... <puts on flame proof suit and goes to bed>

johnd · Unread post by **johnd** » Wed Apr 16, 2003 7:39 pm

Porkster, ridiculous statements like this:

Porkster wrote:
Actually I stick to my guns on this one. I got a letter from the creator of Trace Route. He said that it was named Trace Route but he agrees that Trace Root would have been more correct name for the routine.

are exactly why I can't be bothered having this conversation any more. You need to stick to the main game. There is a problem with Shareaza. Pointing at the Netspace proxy server will never fix that problem. You need to do some careful research and try to fix the actual problem.

And that's all I have to say about that....

johnd · Unread post by **johnd** » Wed Apr 16, 2003 7:49 pm

r0lf wrote: I have noticed that the shareaza population is now 5 clients, so I'm a little confused about that. Previous posts go a long way to describe the mechanism for client discovery, but the point I'm stuck on is, it wasn't that long ago there were 10 or 11 clients in the list!! what happened to you all?

Have a look at the system window. You'll see that a lot of connections are being refused or timing out. The population seems to be there, but you can't connect to them.

If I was Porkster, I would investigate what people see during a single session. Are people all seeing the same population at the same time, or do different people see a different population mix.
Get someone to disconnect and reconnect. Do they see exactly the same population?
Do some trace routes (roots???) to see if people you can't connect to have anything in common. You can get the IP's from the system window.

This would go a long way to identifying the problem.

However, Porkster seems content to just blame the proxy server and leave it at that.

(BTW, I lied. My previous comment wasn't my last, but that's life...)

r0lf · Unread post by **r0lf** » Thu Apr 17, 2003 12:12 am

johnd wrote:
Have a look at the system window. You'll see that a lot of connections are being refused or timing out. The population seems to be there, but you can't connect to them.

FWIW:
Aside from the startup message and "Sending Upload -blahblah" "Finished Upload -blahblah" the system window is clean.. no reported time outs no reported refusals.

sorry to post someone's ip....

Code: Select all

C:\>tracert 203.113.244.230

Tracing route to dsl-203-113-244-230.TAS.netspace.net.au [203.113.244.230]
over a maximum of 30 hops:

  1   <10 ms   <10 ms   <10 ms  trollbert [192.168.0.42]
  2    31 ms    16 ms    31 ms  lns1.Hobart.netspace.net.au [203.17.101.71]
  3  1109 ms  1141 ms  1375 ms  dsl-203-113-244-230.TAS.netspace.net.au [203.113.244.230]

Trace complete.

C:\>tracert 203.113.244.6

Tracing route to dsl-203-113-244-6.TAS.netspace.net.au [203.113.244.6]
over a maximum of 30 hops:

  1   <10 ms   <10 ms   <10 ms  trollbert [192.168.0.42]
  2    94 ms    31 ms   125 ms  lns1.Hobart.netspace.net.au [203.17.101.71]
  3     *        *        *     Request timed out.
  4     *        *     ^C

I can browse both of these machines from shareaza...and before you mention the ping times, there is a bunch of traffic here atm.

Lastly, I have tried reconnects, but always seem to get the same list in the neighbours panel.

I would like to see traces from those who *can't* connnect to shareaza atm.
Are packets lost before or after the lns-something.hobart.netspace.net.au node.
If after, is it lns1 or lns-someothernumber?
Are packets being routed outside of the local netspace network? ie to a victorian node and back again (a problem that once existed for Pigbond)?

To trace to me, use: tracert butwhowill.redirectme.net

If you can connect to Shareaza, but don't see me or porkster in the neighbours list, could you post a trace to one of your neighbours as well as to me?

:?:

Sponge09 · Unread post by **Sponge09** » Thu Apr 17, 2003 8:43 am

Her you go rolf I get refused connections from everyone in my neighbours list
my ip is 203.113.245.55

Code: Select all

C:\Documents and Settings\Sponge>tracert 203.113.244.119

Tracing route to dsl-203-113-244-119.TAS.netspace.net.au [203.113.244.119]
over a maximum of 30 hops:

  1    42 ms    29 ms    22 ms  lns1.Hobart.netspace.net.au [203.17.101.71]
  2    23 ms    48 ms   353 ms  core2-fastether-0-0-11.Hobart.netspace.net.au [2
03.17.102.65]
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9  ^C
C:\Documents and Settings\Sponge>tracert 203.113.244.97

Tracing route to dsl-203-113-244-97.TAS.netspace.net.au [203.113.244.97]
over a maximum of 30 hops:

  1    24 ms    25 ms    24 ms  lns1.Hobart.netspace.net.au [203.17.101.71]
  2    59 ms    64 ms   683 ms  dsl-203-113-244-97.TAS.netspace.net.au [203.113.
244.97]

Trace complete.

C:\Documents and Settings\Sponge>tracert butwhowill.redirectme.net

Tracing route to butwhowill.redirectme.net [203.113.244.128]
over a maximum of 30 hops:

  1    23 ms    24 ms    25 ms  lns1.Hobart.netspace.net.au [203.17.101.71]
  2    80 ms   750 ms   132 ms  dsl-203-113-244-128.TAS.netspace.net.au [203.113
.244.128]

Trace complete.

Porkster · Unread post by **Porkster** » Fri Apr 18, 2003 11:09 pm

r0lf wrote:As for terminology, any thing that links two networks and might cache data could be called a 'proxy', but the 'netspace web proxy' is a specific machine at a specific address. For our p2p stuff I don't see that proxy as an issue. A few people here have other unrelated problems with netspace's proxy server, but i serious doubt it has anything to with the current shareaza problems. Remember we're not link networks here, we're activing trying to stay within the local netspace network.

Our IP cache is off shore, so there can be conflicts on how the netspace web proxy works with world data html requests.

Also, somewhere before the web proxy main process, is the task area to figure what is html or non html data, that task could also be a problem.

I was alerting the the web proxy as it's caused problems in the past and still doesn't seem properly setup.

Porkster · Unread post by **Porkster** » Fri Apr 18, 2003 11:12 pm

johnd wrote:Porkster, ridiculous statements like this:

are exactly why I can't be bothered having this conversation any more. You need to stick to the main game. There is a problem with Shareaza. Pointing at the Netspace proxy server will never fix that problem. You need to do some careful research and try to fix the actual problem.

And that's all I have to say about that....

Your the one being ridiculous.

Shareaza works fine. The only problems we get is when ALL other netspace users are getting problems in general. This is what brought this thread up.

I just corrected your misunderstanding on how a Gwebcache works and also your lack of understanding the possibilities in the cause of the NEtspace problem of recent.

Porkster · Unread post by **Porkster** » Fri Apr 18, 2003 11:22 pm

johnd wrote:Have a look at the system window. You'll see that a lot of connections are being refused or timing out. The population seems to be there, but you can't connect to them.

Regards to so called non connections
-------------------------------------------
There isn't a problem, it's you not understanding the process and what has already been told to you.

IP's in the DCache take an hour to clear. So if a user leaves the p2p group to go something else, then their IP will still be in the DCache for an hour. In that hour, other clients still connected will try that ip, this is how you get the IP's not connecting. No problem at all.

Now there are other user that have just installed Shareaza and have not configured their firewall channels correctly. These people will have problems on any PEER to PEER applications, be it DC, eMule, Kazaa, ANY..

I don't think you understand the limitations of data travel from firewalled users to firewalled user.

Regards to Seeing Users
----------------------------
I will say this again. The Network Page is only a imaginbe of who you have made an established network connection. This don't not mean you can't communicate with others connected!

The idea is that when you make a search, the search request is sent through the WHOLE MESH, even though you can't maybe see a complete mesh. When a user has a file you are searchign for then you will make a PEER to PEER connection after picking the file to download.

Browsing from the Network Page is only a bonus to people who are trapped in serial link days, people who think that file sharing is sharing literal directorys, no matter how back the practice is.

Regards to numbers
-----------------------
Regular users share all the time, whilst others come and go depending on popular games releases. Numbers in the group will sway here and there, not a problem at all.

What I download I share, plain and simple. If there is someone on that has a file I want, then it's a bonus, especially when it's coming down multisourced. I'm making the most of the exisiting time of my contract, before I re-assess the better DSL plan.

CONCLUSION
----------------
Currently no problems. The only issues are when Netspace's internal network settings are foobarred, which recently happened and the effect was to all netspace people in Hobart.

Firewalling setup problems? well people shouldn't buy things they don't understand, like router modems. Then expect to have 100 percent bridging power. I've done alot of help when possible, but the share group is OUR group not mine.

The share situation is in perfect working order, you just have to work out your own equipment setup and hope Netspace is allowing proper networking. (last week it was IP conflicts between users, the other month it was their proxy server was incorrectly tunneling the data.)

.

Porkster · Unread post by **Porkster** » Fri Apr 18, 2003 11:49 pm

r0lf wrote:[Aside from the startup message and "Sending Upload -blahblah" "Finished Upload -blahblah" the system window is clean.. no reported time outs no reported refusals.

Code: Select all

C:\>tracert 203.113.244.230

Tracing route to dsl-203-113-244-230.TAS.netspace.net.au [203.113.244.230]
over a maximum of 30 hops:

  1   <10 ms   <10 ms   <10 ms  trollbert [192.168.0.42]
  2    31 ms    16 ms    31 ms  lns1.Hobart.netspace.net.au [203.17.101.71]
  3  1109 ms  1141 ms  1375 ms  dsl-203-113-244-230.TAS.netspace.net.au [203.113.244.230]

Trace complete.

C:\>tracert 203.113.244.6

Tracing route to dsl-203-113-244-6.TAS.netspace.net.au [203.113.244.6]
over a maximum of 30 hops:

  1   <10 ms   <10 ms   <10 ms  trollbert [192.168.0.42]
  2    94 ms    31 ms   125 ms  lns1.Hobart.netspace.net.au [203.17.101.71]
  3     *        *        *     Request timed out.
  4     *        *     ^C

Yep, Rolf, there isn't a problem, it was just last weekend when Netspace went haywire. The problem was for example , "tracert 203.113.245.6" and you would have info returned for "dsl-203-113-244-133.TAS.netspace.net.au" It was a very wierd problem. Like many would reference Anachronous IP number for this Forum and get a webcam linked to another IP.

The people that work at Netspace/Telstra Tassy level are totally hopeless.

If users still have problems connecting then the Netspace problem still exists to some degree.

.

Porkster · Unread post by **Porkster** » Sat Apr 19, 2003 12:09 am

Some reference to Firewalled to Firewalled user, conflicts.

DC
----
Taken from their Web Page http://www.neo-modus.com/?page=Help

quote-(
Q: Direct Connectâ„¢ says that not everything works in passive mode. What doesn't work in passive mode?

A: Users of passive mode cannot connect to other users who are in passive mode. The ping times will be left blank in the search results, and multi-hub searching will not work.
)

eMule
-------
Taken from the file "readme.txt" in eMule Dir.

quote-(
"What does high and low ID mean anyway?"

When your ID is high (green arrow), everything is fine When it's low (orange arrow), you are behind a firewall or router, and other clients can't connect to you directly (which is a bad thing). Plz read the FAQ or search the forums on how to configure your firewall/router for eMule.
)

So, if you're firewalled then you will have problem when connecting to other firewalled users on any PEER situation!!!!

If you connect to internet through a network device then you are firewalled. Setting bridging modes or mapping ports and ip's will help.

You can only improve your situation by removing as many restrictions on your firewall as possible, noting that also your as good as the next person firewalled.

.

r0lf · Unread post by **r0lf** » Mon Apr 21, 2003 1:37 am

<humble pie>
Okays, we (porkster n myself) have located a problem with
a *gulp* netspace proxy-looking-thing *gulp*.... that is passing an incorrect ip value to the dcache script.... and is being denied.

This may / maynot be causing the present shareaza problems.

By way of a test, Porkster has removed ip blocking from the dcache script which should allow more people to connect... i think, in theory, maybe, perhaps...

during the next few days, Porkster may alter the dcache script again to allow the real ips to written to the cache.
</humble pie>

i am groveling here today to ask people to try shareaza during the next few days and post their results.

there is a chance the dcache entry might have removed itself thru repeated failures, so make sure your dcache setting is:

http://cgi-bin.spaceports.com/~tassy/gcache.php

(get more info from previous 'how to setup' type threads)

Now part two:

The dcache issue would have caused problems to the inital connection stage. There might be another issue relating to the gnutella leaf and hub modes... so under tools -> shareaza settings -> network
for Hub permissions try :

Allow this node to become a Hub = true
Force this node to become a Hub = true
Allow this node to become a Leaf = false
Only accept Hub connections = false (prolly greyed out)

Once altered, you'll be needin' to restart your Shareaza client. This is just something to *try*. See the original setting work, let us know, see if these settings work, let us know, etc, etc. I think, in theory, the above tweak is unnessacary (??)

There are still a few other un-tested ideas on the loose, so stay tuned for a post from a non-n00b.

Porkster · Unread post by **Porkster** » Mon Apr 21, 2003 10:32 pm

r0lf wrote:<humble pie>
Okays, we (porkster n myself) have located a problem with
a *gulp* netspace proxy-looking-thing *gulp*....

As far as I'm concerned I will be making head roads into getting Netspace TAXED by the Government for their proxy. In the long run they will probably win the right not to be taxed like banks aren't but the trouble will maybe have the proxies removed. We don't need our data resold to 56K'er as it's only slowing us DSL users down and we don't currently have an option to deny this. This is a hidden area that technically should be taxed, until the ISP's get a reprieve.

I'm sick of Netspace's lack of knowledge when it comes to setting up our local routers and proxies.

For Shareaza to work it requires a user to be able to access a cache of IP's somewhere in the world and return that cache list. If Netspace network ruins the IP of the person requesting by their proxy tunnelling then it will not supply or return the IP cached list.

.

johnd · Unread post by **johnd** » Tue Apr 22, 2003 6:35 pm

Porkster, you are too stupid for your own good. I have put at least 10 hours into trying to fix your problems with shareaza, a client I don't even use, and the best you can do is call me stupid in another forum.

Take this to treasury. You will only be laughed at. You seem incapable of recognising when someone is willing to spend time and resources to help you.

[EDIT: I've removed some of my more "intemperate" language written in the heat of the moment. However, the salient points remain. Apologies to anyone offended (not that anyone complained).]

Netspace Causing more problems.

Re: Netspace Causing more problems.

Re: Netspace Causing more problems.

Re: Netspace Causing more problems.

still problems with shareaza

Re: Netspace Causing more problems.

Re: Netspace Causing more problems.

Re: Netspace Causing more problems.

Sorry

Re: Netspace Causing more problems.

Re: Netspace Causing more problems.