[SOLVED]network speed/stability ( GW, physically isolated)


I’m two days now into testing a physically isolated GW and I’m having big problems with network stability + speed. That is to say, I encounter a very bad network performance with both the GW and the connected workstation host. At times it works with acceptable Tor network performance (then it randomly stalls) but more often than not I have 1-2 KBit/s DL speed, going down to 500 Bit/s, so basically not usable.

I did thorough testing to isolate the issue:

  1. Booting the GW hardware from a Linux Live CD and downloading from the very same Debian mirror the GW is using as a repository -> fast (through clearnet). GW hardware is OK.
  2. I’m using Tails on a daily basis with the very same upstream connection -> fast (through Tor - via Tails).
  3. I tested the network performance between the GW and the workstation host utilizing iperf -> fast at 90-95 MBit/s.
  4. I switched Tor curcuits on the GW several times to make sure it’s not a particular Tor curcuit that’s failing.

I come to the conclusion that the GW implementation itself (and/or Debian) needs to be the issue here. Maybe the Whonix firewall (it feels like a clogged tube)? That is to say, even “apt-get update” takes forever to complete. I noticed that if it works for a minute or so, it just randomly stalls and is back to 1-2 KBit/s, going down to 500 Bit/s.

Now, I’m asking for support here. How may I troubleshoot this further? I read that at least one other community member has similar issues with network performance (with Whonix 7)*. I encounter the very same thing with the GW here.


(*) https://www.whonix.org/forum/index.php/topic,51.msg395.html#msg395 - Bullet point 4

UPDATE: I have a feeling that it could very well be the wireless driver (my uplink). While it works with a Linux Live CD, it could nevertheless be the case that the Debian kernel (kernel module) for that chipset isn’t playing as nice. I’m now trying to compile another driver from source and see if that improves the situation. Will keep you updated.

I guess that’s why I am not maintaining Linux distribution mainly targeting real hardware. Support of hardware is a real nightmare. Linux forums are full of it.

Testing with by wire, if that’s possible and see if it still happens would also be great to exclude possibility that Whonix itself is the cause.

Whonix-Gateway’s firewall hasn’t changed a lot during these versions. Please feel free to see the diff.

Whonix 0.5.6

Whonix 7/8

git diff 7 whonix_gateway/usr/bin/whonix_firewall

I couldn’t reproduce the issue the other user described and there are no other reports. The user didn’t reply to my follow up questions yet. Depending on these answers, I hope it’s a non-Whonix caused issue. Otherwise it would be really difficult to track, since I never experienced it myself.

As for debugging Whonix’s firewall, you could also completely disable it. Then you’d still be able to access ports Tor is providing (such as … 9153 etc. [https://www.whonix.org/wiki/Stream_Isolation]). (Transparent Proxying would be disabled then.) And then do Tor benchmarks.

Sdwdate could be a cause for Tor issues. It changes time and Tor may not cope up with that well. Sdwdate doesn’t run often on Whonix-Gateway, though. Sdwdate can be shut down (sudo service sdwdate stop) or you can watch when it runs (tail -f /var/log/sdwdate.log).

I might come up with more if needed.

I guess that's why I am not maintaining Linux distribution mainly targeting real hardware. Support of hardware is a real nightmare. Linux forums are full of it.
Yes. Please do not drop support for physical isolation though. You do not need to support this after all. That said, I'm almost certain in the meantime that it's the wireless card. The Linux Live CD I was using ships with a much older 2.6-something kernel and the chipset I'm using is known to have issues with most recent kernels.

Best thing is: While I have a replacement card, this very (other) chipset also seems to not work with most recent kernels - used to work great some years ago though - not sure what driver-amok that is? But I currently remember why I switched to other chipsets with my newest machines.

All that said, I doubt that the GW implementation is the issue here, i.e. I rule it out. It’s the network card and I have to come up with a solution here. I downloaded some driver sources that I remember used to work for the first card but they do not compile on Debian Wheezy. I fiddled with the C code for two hours now and while I got closer (less compiling errors), it still doesn’t build. Connecting by wire isn’t an option here as the GW is running on an old laptop machine (one ethernet interface).

Just wanted to get back to you quickly to say that it’s - almost certainly - not the GW. It’s shitty network hardware + lousy drivers. That most prominently explains the instabilities. I mean, a firewall issue would either clog the tube or not.

Please do not drop support for physical isolation though.
Dropping support isn't planed yet. Physical Isolation code is all set. Mostly just some "if physical isolation", then "don't do this if physical isolation". Simple to keep support.

Let me rephrase that :wink:

Please do not drop physical isolation support - ever! It’s so awesome to have it. Now, if we finally manage to convince you to switch from a HighFat KDE to a LowFat Xfce or LXDE Workstation VM + terminal-only Gateway by default, I’m totally happy. I know: there is still a lot of convincing work involved :stuck_out_tongue: I’m not giving up yet.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]