Issues with IPv6, Privoxy, and Tor Proxy After Updating to FreedomBox 23.20

Pioneer Support
1

My FreedomBox Setup

  • Connected to a router, operating behind NAT.
  • Owned for a couple of years (exact duration unclear).
  • Currently running FreedomBox version 23.20.

Hello everyone,

I’ve encountered some issues since updating to FreedomBox 23.20. The automatic diagnostics highlighted errors specifically related to IPv6 in conjunction with Privoxy and Tor Proxy. I’m not entirely sure of the technicalities involved, so I’ll lay out the issues below for better clarity.

Privoxy Issue

The diagnostic failure for Privoxy was: Access https://debian.org/ with proxy http://[xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:8118/ on tcp6 (I’ve replaced my actual IPv6 address above.)

From what I understand, this test seems to attempt accessing a website through Privoxy at an external IP. However, Privoxy should only be available for internal networks. Interestingly, a similar test using the local IPv6 address was successful. Is this external IP test really necessary, or is there an issue with my FreedomBox setup? The failed test seems a bit off to me, but I could be misunderstanding it.

Tor Proxy Issue

I also had failures with Tor Proxy, specifically: Access URL http://www.debian.org on tcp6 via Tor Confirm Tor usage at https://check.torproject.org on tcp6

Both issues are also related to tcp6, which makes me wonder if they are connected to the Privoxy problem, or if it’s a separate issue.

Could anyone shed some light on what might be going wrong here? Any advice or insights would be greatly appreciated!

1 Like
2

I’ll confirm that.

I received similar diagnostic notifications by the bell icon and reviewed the results. Tor was the least important service to me, so I tried the “Rerun Setup,” option that was there in the diagnostic results. I got the pink error box:

Error updating app: (“cannot access local variable ‘aug’ where it is not associated with a value”, b’‘, b’\x1b[97m INFO\x1b[0m \x1b[94mplinth.modules.torproxy.privileged\x1b[0m Performing first time setup for Tor Proxy\n\x1b[31m ERROR\x1b[0m \x1b[94m__main__ \x1b[0m Error executing action: cannot access local variable 'aug' where it is not associated with a value\nTraceback (most recent call last):\n File “/usr/share/plinth/actions/actions”, line 93, in _call\n return_values = func(*arguments['args'], **arguments['kwargs'])\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File “/usr/lib/python3/dist-packages/plinth/modules/torproxy/privileged.py”, line 29, in setup\n _first_time_setup()\n File “/usr/lib/python3/dist-packages/plinth/modules/torproxy/privileged.py”, line 37, in _first_time_setup\n _disable_apt_transport_tor()\n File “/usr/lib/python3/dist-packages/plinth/modules/torproxy/privileged.py”, line 187, in _disable_apt_transport_tor\n for uri_path in iter_apt_uris(aug):\n ^^^\nUnboundLocalError: cannot access local variable 'aug' where it is not associated with a value\n’)

I’m travelling and won’t get to additional diagnostics until I’m home.

1 Like
3

Please note that these probably aren’t new issues. The only difference in FreedomBox 23.20 is that it is running the diagnostics once a day, and letting you know about the failures. It’s very likely that the failures would have been there before, and you were simply not aware of them.

Also, it is possible that some of our diagnostic tests are faulty, and we will need to either repair or remove them. That is likely the case here.

2 Likes
4

Yes. I apologize for the poor wording. The issue probably wasn’t caused by the update. The update just but it brought it to my attention.

5

Is the intention that the user should do the “Re-run Setup” option from right there in diagnostics if a diagnostic fails? This is what I tried with Tor when getting the error message in the comment above. That felt like the way I was being led to go. I don’t see any treatment of this in the online manual yet, but am understanding that the doco may lag the software change - especially since I’m not stepping up to write that stuff yet.

6

Yes, that is the intention.

The issue with Tor setup seems to be the same as this one:

For some reason, it is not able to parse the apt sources files.

7

EDIT: Currently running FreedomBox version 24.7.

RE: Privoxy Issue

After further investigation, I’ve verified that my router does indeed support IPv6 and DHCP Prefix Delegation (DHCP-PD), as suggested in this reply. Consequently, devices within my network are being correctly assigned IPv6 addresses through PD.

Upon examining the Privoxy configuration on my FreedomBox, I noted that it retains the default settings. I observed that the permit-access directive in Privoxy’s configuration does not explicitly include IPv6-PD addresses. The current settings are limited to:

permit-access [::1]
permit-access [fc00::]/7
permit-access [fe80::]/10

My concern revolves around whether I need to manually add IPv6-PD ranges to Privoxy’s permit-access to enable proper functionality, given they aren’t covered by the default configuration.

8

I recently tried momentarily adding IPv6-PD ranges to Privoxy’s config file on my FreedomBox.
permit-access [xxxx:xxxx:xxxx:xxxx:xxxx::]/64 # replaced with x to obfuscate my IP address
I run the diagnostic tests and, this time, it passed. This prompted a few questions:

  1. Configuration Validity: Is it advisable to manually add IPv6-PD ranges to Privoxy’s settings? Since there is a diagnostics test for it, it seems like the line I have added is valid, but could there be security implications?
  2. Default Settings: Should FreedomBox include these permit-access settings by default for IPv6-enabled networks to avoid diagnostic failures?
  3. Diagnostic Tests: If these settings shouldn’t be default, is it useful to have a diagnostic test that will fail for most users, unless they change the configuration manually? This could be confusing, especially for new users.

Any guidance on these points would be greatly appreciated to help enhance the setup process and user understanding.

Thank you!