Packet loss in Espoo VPN, disappears by turning off

tasaista

Hi,

 

I'm seeing terrible packet loss yesterday and today in Espoo AP. Have you any plans to fix the AP?

 

Currently it seems to be easy to reproduce on a mac with an ADSL connection (ethernet via cable). Reconnecting to AP solves the problem only for a while. On an IOS device this does not happen that often but there the connection is turned off quite frequently due to inactivity. As (still) only one logged-in user can see the client, it's not trivial to reset the vpn connection.

 

Earlier I reported https://community.f-secure.com/t5/F-Secure/Espoo-access-points-not-capable/td-p/86028 and things were ok for a short while. 

 

An example ping session below. Please suggest better tools for checking connection quality.

 

-Tasaista

 

****

 

<###Freedome is on. Connected to Espoo>

PING ftp.funet.fi (193.166.3.2): 56 data bytes

64 bytes from 193.166.3.2: icmp_seq=0 ttl=247 time=201.570 ms

64 bytes from 193.166.3.2: icmp_seq=1 ttl=247 time=131.157 ms

64 bytes from 193.166.3.2: icmp_seq=2 ttl=247 time=124.983 ms

Request timeout for icmp_seq 3

Request timeout for icmp_seq 4

64 bytes from 193.166.3.2: icmp_seq=5 ttl=247 time=143.964 ms

Request timeout for icmp_seq 6

64 bytes from 193.166.3.2: icmp_seq=7 ttl=247 time=201.386 ms

Request timeout for icmp_seq 8

Request timeout for icmp_seq 9

Request timeout for icmp_seq 10

64 bytes from 193.166.3.2: icmp_seq=11 ttl=247 time=150.100 ms

Request timeout for icmp_seq 12

Request timeout for icmp_seq 13

Request timeout for icmp_seq 14

Request timeout for icmp_seq 15

64 bytes from 193.166.3.2: icmp_seq=16 ttl=247 time=191.419 ms

64 bytes from 193.166.3.2: icmp_seq=17 ttl=247 time=115.079 ms

Request timeout for icmp_seq 18

Request timeout for icmp_seq 19

Request timeout for icmp_seq 20

64 bytes from 193.166.3.2: icmp_seq=21 ttl=247 time=177.859 ms

64 bytes from 193.166.3.2: icmp_seq=22 ttl=247 time=184.205 ms

Request timeout for icmp_seq 23

<###Freedome OFF>

64 bytes from 193.166.3.2: icmp_seq=24 ttl=249 time=13.877 ms

64 bytes from 193.166.3.2: icmp_seq=25 ttl=249 time=14.343 ms

64 bytes from 193.166.3.2: icmp_seq=26 ttl=249 time=14.083 ms

64 bytes from 193.166.3.2: icmp_seq=27 ttl=249 time=14.620 ms

64 bytes from 193.166.3.2: icmp_seq=28 ttl=249 time=14.548 ms

64 bytes from 193.166.3.2: icmp_seq=29 ttl=249 time=15.302 ms

64 bytes from 193.166.3.2: icmp_seq=30 ttl=249 time=14.848 ms

64 bytes from 193.166.3.2: icmp_seq=31 ttl=249 time=14.276 ms

64 bytes from 193.166.3.2: icmp_seq=32 ttl=249 time=14.691 ms

<### Turn Freedome ON, connecting>

64 bytes from 193.166.3.2: icmp_seq=33 ttl=249 time=14.691 ms

64 bytes from 193.166.3.2: icmp_seq=34 ttl=249 time=14.688 ms

64 bytes from 193.166.3.2: icmp_seq=35 ttl=249 time=14.925 ms

64 bytes from 193.166.3.2: icmp_seq=36 ttl=249 time=14.196 ms

Request timeout for icmp_seq 37

Request timeout for icmp_seq 38

Request timeout for icmp_seq 39

<#Freedome is now connected. Packet loss gone for few minutes>

64 bytes from 193.166.3.2: icmp_seq=37 ttl=247 time=3054.569 ms

64 bytes from 193.166.3.2: icmp_seq=38 ttl=247 time=2051.498 ms

64 bytes from 193.166.3.2: icmp_seq=39 ttl=247 time=1060.286 ms

64 bytes from 193.166.3.2: icmp_seq=40 ttl=247 time=105.816 ms

64 bytes from 193.166.3.2: icmp_seq=41 ttl=247 time=30.670 ms

64 bytes from 193.166.3.2: icmp_seq=42 ttl=247 time=30.152 ms

64 bytes from 193.166.3.2: icmp_seq=43 ttl=247 time=30.672 ms

....

<#After 5 minutes the packet loss is back>

64 bytes from 193.166.3.2: icmp_seq=22 ttl=247 time=125.741 ms

64 bytes from 193.166.3.2: icmp_seq=23 ttl=247 time=160.028 ms

64 bytes from 193.166.3.2: icmp_seq=24 ttl=247 time=186.212 ms

Request timeout for icmp_seq 25

64 bytes from 193.166.3.2: icmp_seq=26 ttl=247 time=135.618 ms

64 bytes from 193.166.3.2: icmp_seq=27 ttl=247 time=127.689 ms

64 bytes from 193.166.3.2: icmp_seq=28 ttl=247 time=124.175 ms

64 bytes from 193.166.3.2: icmp_seq=29 ttl=247 time=91.114 ms

64 bytes from 193.166.3.2: icmp_seq=30 ttl=247 time=106.733 ms

64 bytes from 193.166.3.2: icmp_seq=31 ttl=247 time=81.921 ms

64 bytes from 193.166.3.2: icmp_seq=32 ttl=247 time=101.905 ms

64 bytes from 193.166.3.2: icmp_seq=33 ttl=247 time=86.667 ms

64 bytes from 193.166.3.2: icmp_seq=34 ttl=247 time=136.724 ms

64 bytes from 193.166.3.2: icmp_seq=35 ttl=247 time=149.360 ms

64 bytes from 193.166.3.2: icmp_seq=36 ttl=247 time=152.371 ms

64 bytes from 193.166.3.2: icmp_seq=37 ttl=247 time=108.419 ms

Request timeout for icmp_seq 38

64 bytes from 193.166.3.2: icmp_seq=39 ttl=247 time=123.504 ms

<### After another 5 minutes the quality is ok again>

 

 

[Deleted User]

Hello tasaita,

 

I'll contact you by Private message regarding this problem.

tasaista

Thank you for this. I provided the requested information.

 

Unfortunately I was not able to run the mtr tool in the mac. I had to use a linux box behind the same switch. I hope the information helps though.

bfish2006

 

Confirming speed issues again with Espoo server in the evenings.

Getting 1.7Mbps download from Espoo server when connecting

from Spain. At the same time Madrid server gives 8.2Mbps.

 

It's the same issue that was happening over month ago.

There is either something to fix again or increase the capacity.

Fuengirola is now full  of finns spending the winter months

on the sun and wanting to watch finnish tv streams - this peak

will last the next 7 months.

 

Please have a look at this asap.

[Deleted User]

Hello Everyone,

 

I forwarded your inputs to our Product team for more details. We see capacity issues now in Finland location because of the quickly increased use of our product. We are working on adding more servers as soon as we can.

tasaista

As a follow up: no improvement noticed on longer term. Nowadays I need to keep Freedome disabled unless I explicitly need it. Although I'm not looking for refund, I'm not very likely to continue subscription after the current period ends.