LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-01-2018, 10:13 PM   #16
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled

Quote:
Originally Posted by abga View Post
My recommendation is to make sure that the new kernel is what breaks tor
I am pretty sure that with at least 2-3 previous kernel versions that came as updates for Slackware64-14.2 tor never had such an issue, just before this last kernel update same tor version worked fine. Is this not enough to be sure it's the kernel?

Quote:
Originally Posted by abga View Post
this will require a kernel downgrade
Why? Tor worked fine with previous kernel versions, as stated above.

Quote:
Originally Posted by abga View Post
I don't really know where (or if) the previous version of the Slackware kernel is available.
Yep, I never understood why Slackware keeps only the last version in patches/ and doesn't have some kind of fully versioned update history, but I suppose that's a question for another topic. Or, with a bit of luck, maybe Pat himself could answer when/if he will read this thread.

Quote:
Originally Posted by abga View Post
Report a bug at tor and point them to this thread.
That is probably the next thing that I'll be trying to do. Thank you very much for your assistance and valuable technical details.
 
Old 03-01-2018, 11:02 PM   #17
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled
https://trac.torproject.org/projects/tor/ticket/25401
 
Old 03-01-2018, 11:02 PM   #18
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 519

Rep: Reputation: 276Reputation: 276Reputation: 276
Quote:
Originally Posted by FlinchX View Post
Quote:
Originally Posted by abga
this will require a kernel downgrade

Why? Tor worked fine with previous kernel versions, as stated above.
With the downgrade I simply meant to go back to a previous kernel version, pre 4.4.118, that you know it was working fine with tor. Well, if you find one
Note that there were several netfilter modules related changes, nothing I could spot that might affect tor, in the 4.4.118 kernel:
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.118

In my last post I forgot to mention that I followed your setup but used the instructions and the SlackBuild from:
https://slackbuilds.org/repository/14.2/network/tor/
On my tor version switch from Tor 0.3.2.9 to Tor 0.2.9.14, I simply unpacked the tor-0.2.9.14.tar.gz, renamed the resulting directory into tor-0.3.2.9, packed it back into tor-0.3.2.9.tar.gz and fed it to the tor.SlackBuild - I'm lazy! (sincere too)

Something I also like to mention, I was always handling tor with care, given the nature of the "darknet" and always dedicated a disposable/unimportant system for it, using it as a remote transparent proxy. That's why I don't have experience with running it on the same host where it is needed, like in your case. If you cannot resolve this issue, I'd suggest to get a cheap ARM board, a Raspberry Pi 2-3 (even a $10 Pi0 will do it!) will do and join the biscuits conspiracy brotherhood (I'm still due for an oath ceremony) here:
https://www.linuxquestions.org/quest...kware-arm-108/
Load Slackware ARM and tor on your board and use it as your transparent (socks included) anonymization proxy. You'd also have more control over the traffic and potential leakages.

Last edited by abga; 03-01-2018 at 11:07 PM. Reason: added Pi0 alternative
 
Old 03-01-2018, 11:10 PM   #19
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
With the downgrade I simply meant to go back to a previous kernel version, pre 4.4.118, that you know it was working fine with tor. Well, if you find one
Keeping 4.4.118 for the sake of having a system not vulnerable to Spectre anymore or going back to a previous kernel version (which seems to be a challenge, as noted above) is a really hard choice for me. I will wait for a while for feedback on the bug I just reported on tor bugtracker, it looks like we posted to this forum at the same time, since my post with the bug report link there appeared just before yours.

Quote:
Originally Posted by abga View Post
Note that there were several netfilter modules related changes, nothing I could spot that might affect tor, in the 4.4.118 kernel:
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.118
I'm very much below the level of being comfortable with reading kernel changelogs, so my only option is to whine in forums/bugtrackers whenever something suddenly breaks like this.
 
Old 03-02-2018, 05:14 AM   #20
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled
Apparently I'm not the only one

This is the link to follow now: https://trac.torproject.org/projects/tor/ticket/25380
 
Old 03-07-2018, 06:09 PM   #21
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 519

Rep: Reputation: 276Reputation: 276Reputation: 276
Quote:
Originally Posted by FlinchX View Post
Apparently I'm not the only one

This is the link to follow now: https://trac.torproject.org/projects/tor/ticket/25380
I was following the development on that ticket and noticed that they consider now that there might be a kernel bug after all. I'm still suspecting the netfilter modules and I'm worried about this, as, again, I'm really relying heavily on them for my work and if they are broken in 4.4.118, then my whole "science" is broken too. I still find it weird that the udp packets, that's the DNS requests, didn't break tor but the tcp packets did. Additionally, I was following another kernel bug (USB related) recently and found out that the person who was slicing&dicing (bisecting) the kernel changes had issues compiling the netfilter changes that were added in the 4.9.x kernel in lower kernel versions, he finally disabled them:
https://forum.libreelec.tv/thread/42...5965#post75965

I was wondering if you have a Slackware -current system / VM image, with an actual kernel, on which you could try to replicate this tor issue.
 
Old 03-08-2018, 03:05 AM   #22
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
I was wondering if you have a Slackware -current system / VM image
No, but if things keep getting stuck at this point for a long time, I might try to install -current in a VM, as long as I can learn how to do it closest way possible as latest stable. I never touched -current before just because I know if I do I'm on my own and I'd have to expect less support from the community, but since I don't feel knowledgeable enough for being confident I can fix eventual issues, I have always preferred to stick with latest stable version. For example, I don't even know if there are daily .iso images for -current. If somebody makes those, then getting -current in a VM will probably be even faster, since I could do a full install the same way and won't even need to apply updates.


Quote:
Originally Posted by abga View Post
with an actual kernel
Define actual. Changelog for -current says kernel version is 4.14.23. Initially the bug report on the tor bugtracker was for kernel version 4.15.6, which is newer. So I have assumed that tor in -current would have the same problem, but I've never actually tried it. But if by actual kernel you mean an even newer version, with implications that I might need to run a much newer custom kernel in 14.2 and eventually in next stable version as well, just to have a fully functional tor, such a perspective doesn't look appealing to me at all.

Quote:
Originally Posted by abga View Post
on which you could try to replicate this tor issue.
Perhaps I will try closer to the weekend, if I can scramble some spare time, unless you can manage to do that first. Previous fiddling with 14.2 in a VM took less time than I've expected, so if there are daily .iso images available somewhere, I will try.
 
Old 03-08-2018, 03:26 PM   #23
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 519

Rep: Reputation: 276Reputation: 276Reputation: 276
Quote:
Originally Posted by FlinchX View Post
No, but if things keep getting stuck at this point for a long time, I might try to install -current in a VM, as long as I can learn how to do it closest way possible as latest stable. I never touched -current before just because I know if I do I'm on my own and I'd have to expect less support from the community, but since I don't feel knowledgeable enough for being confident I can fix eventual issues, I have always preferred to stick with latest stable version. For example, I don't even know if there are daily .iso images for -current. If somebody makes those, then getting -current in a VM will probably be even faster, since I could do a full install the same way and won't even need to apply updates.
Here you have the Slackware -current ISO image:
https://www.linuxquestions.org/quest...8/#post5824716
I'm only using the Slackware ARM -current but not the X86 one, that's why I asked you about it.
And I believe that you are getting support if you ask for it kindly here in the forum.
Quote:
Originally Posted by FlinchX View Post
Define actual. Changelog for -current says kernel version is 4.14.23. Initially the bug report on the tor bugtracker was for kernel version 4.15.6, which is newer. So I have assumed that tor in -current would have the same problem, but I've never actually tried it. But if by actual kernel you mean an even newer version, with implications that I might need to run a much newer custom kernel in 14.2 and eventually in next stable version as well, just to have a fully functional tor, such a perspective doesn't look appealing to me at all.
The other person who reported the same issue in the tor bugtrack system did not provide any technical info and his problem description (language) is a little too simplistic, if I'm allowed. Trying to replicate this on Slackware -current with an actual kernel, a newer one if you like, in the context of what I presented in my previous post about the netfilter modules, might add to the value of the investigation and give the tor guys more technical info - as they request it now - see the status of the tor ticket.
On the "implications", depending on the case, if the kernel is broken than the Slackware team will surely try to fix it and the kernel folks will be notified too, if tor itself is broken, then the tor devs will start to fix it.

I'm also short on time and again, I just asked if you have already a Slackware -current running somewhere, because it would have been easier to just compile tor & copy-paste the conf+firewall and try to replicate the issue (10 minutes). I'll do an installation myself anyway, since I've told you I'm really worried about the netfilter stuff and I'll come back with my findings.
 
1 members found this post helpful.
Old 03-09-2018, 01:02 AM   #24
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 519

Rep: Reputation: 276Reputation: 276Reputation: 276
Everything works better after a good coffee, isn't it FlinchX?

I got my Slackware -current VMware Workstation Player running and tried to replicate your reported issue with the setup from my post #15
It looks like tor is working well under Slackware -current with the 4.14.24 kernel, no issues observed.

The only thing left is to try to replicate this setup with another transparent proxy, in order to exclude tor from the equation and have a clear verdict. That will leave the 4.4.118 kernel solely responsible for the issue. The kernel component(s) that might cause this could be either the netfilter modules or the Spectre mitigation and investigating that is way over my time availability, maybe even over my knowledge.

You should try to get back to a previous kernel version for the moment, one that you know it was working fine. Ask specifically for it - open a new thread if you cannot get help here. I wish I could help myself, but I have no older kernel version as I'd updated all my Slackware X86 systems with the 4.4.118 recently.
Personally, I consider going to what I described recently here for a fellow Slacker and start using the kernel provided by the Slackware -current. I haven't tried that yet, but I do trust bassmadrigal's experience:
https://www.linuxquestions.org/quest...ml#post5828502

Setup & investigation:
- used the same dual core i3 system on which I did the previous test with Slackware 14.2
- installed in VMware Workstation Player the up-to-date Slackware -current, image that I took from here:
http://bear.alienbase.nl/mirrors/sla...4-current-iso/
slackware64-current-install-dvd.iso 2018-03-09 00:19 2.9G
- took the tor Slackbuild and followed the instructions from here:
https://slackbuilds.org/repository/14.2/network/tor/
- used the configuration from my previous post #15

And here are the results - note that there was a lot more tcp traffic captured by iptables and sent through the transproxy port on tor, the tor process was in a normal state and I was able to see under the user anon by running lynx https://torguard.net/whats-my-ip.php my anonymized IP (tor exit node):
Code:
root@slack-current:~# uname -r
4.14.24

root@slack-current::~# iptables --version
iptables v1.6.2

root@slack-current:~# id anon
uid=1001(anon) gid=100(users) groups=100(users)

root@slack-current:/home/test# finger anon
Login: anon                             Name:
Directory: /home/anon                   Shell: /bin/bash
Never logged in.
No mail.
No Plan.

- ps ax - tor & lynx related:
tor       22231  0.4  4.7  67592 34220 ?        S    07:03   0:04 /usr/bin/tor
anon      22516  0.0  0.5  20344  4156 tty1     Ss   07:11   0:00 -bash
anon      22534  0.6  1.2  28900  8848 tty1     S+   07:12   0:00  \_ lynx https://torguard.net/whats-my-ip.php

root@slack-current:~# iptables -vnL
Chain INPUT (policy DROP 3 packets, 152 bytes)
 pkts bytes target     prot opt in     out     source               destination
   51 14787 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
 2207 2521K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   27  2951 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1001 tcp dpt:9040
   12   738 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1001 udp dpt:53
    1    29 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1001
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            127.0.0.1
 1513  547K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW,RELATED,ESTABLISHED

root@slack-current:~# iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 3 packets, 152 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 13 packets, 758 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            10.192.0.0/10        tcp flags:0x17/0x02 redir ports 9040
    5   300 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 220
    1    29 RETURN     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
    0     0 RETURN     all  --  *      *       0.0.0.0/0            127.0.0.0/8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            10.0.0.0/8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            172.16.0.0/12
    7   429 RETURN     all  --  *      *       0.0.0.0/0            192.168.0.0/16
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            100.64.0.0/10
    0     0 RETURN     all  --  *      *       0.0.0.0/0            169.254.0.0/16
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.0.0.0/24
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.0.2.0/24
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.88.99.0/24
    0     0 RETURN     all  --  *      *       0.0.0.0/0            198.18.0.0/15
    0     0 RETURN     all  --  *      *       0.0.0.0/0            198.51.100.0/24
    0     0 RETURN     all  --  *      *       0.0.0.0/0            203.0.113.0/24
    0     0 RETURN     all  --  *      *       0.0.0.0/0            224.0.0.0/3
    4   240 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1001 tcp redir ports 9040
    0     0 REDIRECT   udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1001 udp dpt:53 redir ports 53

Chain POSTROUTING (policy ACCEPT 16 packets, 969 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
1 members found this post helpful.
Old 03-09-2018, 01:03 AM   #25
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
Here you have the Slackware -current ISO image:
https://www.linuxquestions.org/quest...8/#post5824716
Ah, nice, I have already found AlienBOB's iso making script but your hint allowed me to skip that part and just download a fresh -current iso.

I did install -current in a VM and I can't reproduce the problem with -current that has kernel 4.14.24 and tor-0.3.2.10. I have posted an update to the bug report on tor bugtracker as well.

Edit: this is funny, it looks like we posted at the same time again

Last edited by FlinchX; 03-09-2018 at 01:04 AM.
 
Old 03-09-2018, 01:20 AM   #26
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
You should try to get back to a previous kernel version for the moment
Actually, the free bonus of a working tor in the VM with -current is that I can use it for my daily routine while waiting for the next stable release. It's a bit clumsy, but it's a workaround.
 
Old 03-10-2018, 03:20 AM   #27
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 519

Rep: Reputation: 276Reputation: 276Reputation: 276
In my previous post I considered that a test with another transparent proxy might help to understand if the kernel is the component that is failing and maybe exclude tor from this scenario. I got some spare time now during this beautiful rainy day and tested this setup on Slackware 14.2 with tinyproxy instead of tor.
https://tinyproxy.github.io/
There's also a SlackBuild for it:
https://slackbuilds.org/repository/1...ork/tinyproxy/

I've used the same setup as in my previous tests and only substituted the tor process with tinyproxy, launched it as user/group tor (conf file options) and put it to listen on all available interfaces on port 9040. Now, tinyproxy is not able to forward HTTPS traffic, but that is not really important for the test, I was more concerned about the proper functionality of netfilter/kernel.
I was not able to reproduce the issue with tor, tinyproxy was running happy and transproxy-ing the anon user http (tcp) traffic. The DNS requests were resolved by the localhost, since, unlike tor, tinyproxy doesn't have this feature.

My view on this, now after the tinyproxy test, is that tor & the 4.4.118 kernel do not like each other and should be studied together for the reported problem. Unless some other reports about the 4.4.118 kernel will show up, I'm considering it stable and usable for the moment.

Test results with tinyproxy:
Code:
- ps ax :  anon & tinyproxy related
anon      9705  0.0  0.0  20624  3540 pts/3    S    09:12   0:00      \_ -su
anon      9852  0.1  0.1  36936  9444 pts/3    S+   09:19   0:00          \_ lynx www.slackware.com
tor       9839  0.0  0.0  17748  4720 ?        S    09:19   0:00 /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9842  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9843  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9844  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9845  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9846  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9847  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9848  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9849  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9850  0.0  0.0  17748  2856 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf
tor       9851  0.0  0.0  19824  4836 ?        S    09:19   0:00  \_ /usr/sbin/tinyproxy -c /etc/tinyproxy.conf

lsof -i
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
tinyproxy 9839  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9842  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9843  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9844  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9845  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9846  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9847  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9848  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9849  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9850  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)
tinyproxy 9851  tor    0u  IPv4  28363      0t0  TCP *:9040 (LISTEN)


iptables -vnL
Chain INPUT (policy DROP 12 packets, 384 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  753 52142 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
 2271 2228K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 7 packets, 280 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  376 21282 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 tcp dpt:9040
   54  3174 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 udp dpt:53
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            127.0.0.1           
 2217  151K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW,RELATED,ESTABLISHED

 iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 12 packets, 384 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 182 packets, 10872 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            10.192.0.0/10        tcp flags:0x17/0x02 redir ports 9040
   12   696 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 220
    0     0 RETURN     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            127.0.0.0/8         
    0     0 RETURN     all  --  *      *       0.0.0.0/0            10.0.0.0/8          
    0     0 RETURN     all  --  *      *       0.0.0.0/0            172.16.0.0/12       
  127  8112 RETURN     all  --  *      *       0.0.0.0/0            192.168.0.0/16      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/8           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            100.64.0.0/10       
    0     0 RETURN     all  --  *      *       0.0.0.0/0            169.254.0.0/16      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.0.0.0/24        
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.0.2.0/24        
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.88.99.0/24      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            198.18.0.0/15       
    0     0 RETURN     all  --  *      *       0.0.0.0/0            198.51.100.0/24     
    0     0 RETURN     all  --  *      *       0.0.0.0/0            203.0.113.0/24      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            224.0.0.0/3         
   20   960 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 tcp redir ports 9040
    0     0 REDIRECT   udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 udp dpt:53 redir ports 53

Chain POSTROUTING (policy ACCEPT 202 packets, 11832 bytes)
 pkts bytes target     prot opt in     out     source               destination

Last edited by abga; 03-10-2018 at 03:38 AM. Reason: typo
 
1 members found this post helpful.
Old 03-26-2018, 10:19 PM   #28
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by FlinchX View Post
Apparently I'm not the only one

This is the link to follow now: https://trac.torproject.org/projects/tor/ticket/25380
So the bug on the Tor bugtracker was marked as wontfix. For some reason they seem to still suspect the kernel, despite having info that other transparent proxy (tinyproxy) still works with this kernel version. Which makes me wonder if there will be another update of kernel 4.4.x in Slackware 14.2.
 
Old 03-27-2018, 01:23 AM   #29
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 519

Rep: Reputation: 276Reputation: 276Reputation: 276
If you'd like to try an older tor release as a temporary workaround, one "pre-hardening", by following what I've done in post #15 & #18 (unpacking and changing the name of the tor src folder + archive name), then you can try this old tor I've found on one of my archive HDDs. It was the latest tor I was playing with some 2 years ago. It's old, it doesn't have all the security fixes, but if it works, you should be fine with it running only as a client (no relay/exit node/hidden service).
https://blog.torproject.org/tor-0276-released
Get the source package (tor-0.2.7.6.tar.gz) from here:
http://www119.zippyshare.com/v/M0qdAWm7/file.html
And attached to this post you'll find the associated signature file: tor-0.2.7.6.tar.gz.asc.txt (cut the txt at the end)
The gpg key that was used to sign it is still valid (you're lucky):
https://pgp.mit.edu/pks/lookup?searc...9319A&op=index
Do the verification after you downloaded the files:
Code:
gpg --keyserver pgp.mit.edu --recv-keys 0x8D29319A
gpg --verify tor-0.2.7.6.tar.gz.asc
Wish you good luck!
Attached Files
File Type: txt tor-0.2.7.6.tar.gz.asc.txt (636 Bytes, 0 views)
 
Old 03-27-2018, 10:05 PM   #30
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 216

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
it doesn't have all the security fixes
Thanks for trying to help, but this is why I never tried a very old tor version as a workaround before. I'd rather use Whonix while -current is moving towards 15.0
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Getting "SIOCADDRT: No such process" when running "service network restart" cmlorentz Linux - Networking 1 11-26-2010 01:06 PM
"bad_pool_error" & "Your system is not fully acpi compliant get your Bios updated" errors in WinXP TheIndependentAquarius General 10 07-30-2010 11:27 AM
How do I disable "shutdown" and "restart" options in KDE logout screen for all users? maxgsp Linux - Distributions 1 12-12-2008 03:18 PM
Lost "Shutdown" and "Restart" From system menu in FC6 Nader1 Linux - Software 3 02-12-2007 04:40 PM
"Shutdown" and "Restart" option missing after upgrade hansalfredche Mandriva 8 11-02-2006 07:23 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:58 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration