If the OP is able to disconnect and then reconnect, then his DNS is obviously fine (especially since the widget no doubt uses the FQDNs of the exit nodes as opposed to the IP addresses).
touche112 wrote:Pardon my technical incompetence on the subject, but where are logs stored? I'm new to OpenVPN.
touche112 wrote:Just checked - no logs found. No report of anything past when I initially connected in the widget.
touche112 wrote:My bad, yes, I have those logs. But past the log of the initial connection, there's nothing further that it reports.
marzametal wrote:Another thread had a topic about Portugal, it's down for the time-being, and the CS staff are working on getting it rectified. You're better off hopping onto another node for the moment.
touche112 wrote:Any reason why browsing speeds are fine, but torrent speeds are slow? I'm seeing 1-2MBps HTTP downloads, but only 100-200kBps torrent downloads.
touche112 wrote:I can't get the OpenVPN client to connect. I have no clue why - it halts at "mute triggered" and then hangs. I gave up after an hour. The instructions are clear-cut, so I don't know why it won't work for me. But whatever.
Anyway, experienced the timeout again, after exactly 20 minutes, using chili. Nothing related to the incident reported in any logs. It's even configured to output in verbose mode.
Tealc wrote:touche112 wrote:Any reason why browsing speeds are fine, but torrent speeds are slow? I'm seeing 1-2MBps HTTP downloads, but only 100-200kBps torrent downloads.
I may have a "solution" for you...
Long time ago I had the same problem and after a lot of searching I found that due to the architecture that CS uses if someone is already torrenting in the same node as you and uses the same port you will not get a lot a speed since there will be a lot of conflict with the exit IP.
So just point your torrent program to a port high enough that nobody uses (and keep on trying, it took me a couple of hours) and don't use the random port in the config.
Just to show you that I can get easily 19.3 MB/s in the germany node right now with only 62 seeds
That's an interesting solution. It means that whether a torrent client is initiating a connection and receiving replies, or is fielding incoming requests initiated from another peer, it uses the same port. This is in stark contrast to - for example - a Tor relay, which might receive requests on port 9001, but when it initiates connections to another relay, it receives replies from that relay on a completely different (and random) port.
jdurne wrote:I have exactly the same problems and so far I have not been able to sort it.
Mine started when I changed my token to a new one and before that it have been running flawless since the start of Cryptostorm. Sent in a ticket and got a answer from PJ that the tech folks are looking at it so I hope for a fast resolution.
I believed that this is due to the limited public IP address CS has, but I can't confirm this.
I'm connected to brisa on both the Windows and raw instances, and both connections have been solid for over two hours. We've run into this issue before with the 20 minute fall-over - it was on Cantus for me - and if I remember rightly it was somehow related to the token, but I can't remember the exact details.
@TealcI believed that this is due to the limited public IP address CS has, but I can't confirm this.
Correct. It's called "port collision". Two clients effectively end up "sharing" a port at the clear side of the exit node; packets intended for one end up going to the other, and vice versa.
Users browsing this forum: No registered users and 15 guests