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.
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.
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!
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.
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.
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.
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.
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.