Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:47:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33929Tor relay appears offline in Metrics after some times2020-06-27T13:47:51ZTracTor relay appears offline in Metrics after some timesSince at least December 20, my relay appears offline in Metrics after few hours to few days (typically between 3h to 3d). In nyx, all flags disappears. After restarting the service, flags are coming back after few hours and the relay app...Since at least December 20, my relay appears offline in Metrics after few hours to few days (typically between 3h to 3d). In nyx, all flags disappears. After restarting the service, flags are coming back after few hours and the relay appears online again. There is nothing in the log.
My fingerprint:
33D88F331408141F2A2CC563239E54E48F7A211B
Notice that this happens to at least another person, its fingerprint
DAA806E9529D77EF94685FC0E513386EF65B83F8
**Trac**:
**Username**: clementhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33925Can't compile Tor master as of 2020-04-162020-06-27T13:47:51ZTracCan't compile Tor master as of 2020-04-16I can compile 0.4.3.4-rc without problem now.
Master not so great, though:
```
Ld
/Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug/Tor.framework/Versions
/A/Tor normal x86_64 (in...I can compile 0.4.3.4-rc without problem now.
Master not so great, though:
```
Ld
/Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug/Tor.framework/Versions
/A/Tor normal x86_64 (in target 'Tor-Mac' from project 'Tor') cd
/Users/berhart/workspace/gp/Tor.framework
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.
/xctoolchain/usr/bin/clang -target x86_64-apple-macos10.9
/-dynamiclib -isysroot
//Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
/platform/Developer/SDKs/MacOSX10.15.sdk
/-L/Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug
/-F/Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug -filelist
//Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Intermediates.noindex/Tor.build/
/Debug/Tor-Mac.build/Objects-normal/x86_64/Tor.LinkFileList
/-install_name @rpath/Tor.framework/Tor -Xlinker -rpath -Xlinker
/@executable_path/../Frameworks -Xlinker -rpath -Xlinker
/@loader_path/../Frameworks -Xlinker -object_path_lto -Xlinker
//Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Intermediates.noindex/Tor.build/
/Debug/Tor-Mac.build/Objects-normal/x86_64/Tor_lto.o -Xlinker
/-export_dynamic -Xlinker -no_deduplicate -fobjc-arc
/-fobjc-link-runtime -fapplication-extension -framework CFNetwork
/-ltor-app -ltor-compress -ltor-evloop -ltor-tls -ltor-crypt-ops
/-lkeccak-tiny -ltor-pubsub -ltor-confmgt -led25519_ref10
/-led25519_donna -lcurve25519_donna -ltor-geoip -ltor-process
/-ltor-buf -ltor-time -ltor-fs -ltor-encoding -ltor-sandbox
/-ltor-container -ltor-net -ltor-thread -ltor-memarea -ltor-math
/-ltor-meminfo -ltor-osinfo -ltor-dispatch -ltor-log -ltor-lock
/-ltor-fdio -ltor-string -ltor-term -ltor-smartlist-core
/-ltor-malloc -ltor-wallclock -ltor-err -ltor-version -ltor-intmath
/-ltor-ctime -lor-trunnel -ltor-trace -lssl -lcrypto -levent
/-levent_core -levent_extra -levent_pthreads -llzma -lz -Xlinker
/-dependency_info -Xlinker
//Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Intermediates.noindex/Tor.build/
/Debug/Tor-Mac.build/Objects-normal/x86_64/Tor_dependency_info.dat
/-o
//Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug/Tor.framework/
/Versions/A/Tor
/
Undefined symbols for architecture x86_64: "_sys_winprocess", referenced
from: _tor_subsystems in libtor-app.a(subsystem_list.o) ld: symbol(s)
not found for architecture x86_64 clang: error: linker command failed
with exit code 1 (use -v to see invocation)
```
See legacy/trac#33837 for more context.
**Trac**:
**Username**: tlaTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33924Tor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOS2020-06-27T13:47:52ZTracTor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOSOk, so it seems Tor doesn't honor SIGNAL SHUTDOWN anymore. The first Tor version I tested was 0.4.1.5 (first stable of 0.4.1).
Sending it with 0.4.0.6, I see this in the logs:
```
Apr 16 16:31:58.000 [notice] Interrupt: exiting cleanly....Ok, so it seems Tor doesn't honor SIGNAL SHUTDOWN anymore. The first Tor version I tested was 0.4.1.5 (first stable of 0.4.1).
Sending it with 0.4.0.6, I see this in the logs:
```
Apr 16 16:31:58.000 [notice] Interrupt: exiting cleanly.
```
With later Tor versions, this message disappears and the TorThread still hangs around after app wake up.
**Trac**:
**Username**: tlaTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33918Stop truncating IPv6 addresses in channel logs2020-06-27T13:47:52ZteorStop truncating IPv6 addresses in channel logschannel_tls_get_remote_desc_method() formats IP addresses and ports, but its buffer is only 32 characters. IPv6 addresses can be up to 41 characters long, and the port is an extra 6 characters.channel_tls_get_remote_desc_method() formats IP addresses and ports, but its buffer is only 32 characters. IPv6 addresses can be up to 41 characters long, and the port is an extra 6 characters.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33917Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL2021-09-16T14:21:51ZteorMake IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33900Check for invalid zero IPv4 addresses and ports in extend cells2021-09-16T14:21:51ZteorCheck for invalid zero IPv4 addresses and ports in extend cellsWhen we send and parse extend cells, we check that their IPv4 address field is not AF_UNSPEC.
But we should also check for zero IPv4 addresses and zero ports. (Which are both invalid.)
Code and points in legacy/trac#33817, I just neede...When we send and parse extend cells, we check that their IPv4 address field is not AF_UNSPEC.
But we should also check for zero IPv4 addresses and zero ports. (Which are both invalid.)
Code and points in legacy/trac#33817, I just needed a separate bug number.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33899Allow IPv6 addresses to be canonical2020-06-27T13:47:53ZteorAllow IPv6 addresses to be canonicalIn legacy/trac#17604, we allowed IPv6 connections to set is_canonical_to_peer. But we did not let them set is_canonical.
So channel_tls_process_netinfo_cell() handles IPv6 addresses, but connection_or_check_canonicity() does not.
This ...In legacy/trac#17604, we allowed IPv6 connections to set is_canonical_to_peer. But we did not let them set is_canonical.
So channel_tls_process_netinfo_cell() handles IPv6 addresses, but connection_or_check_canonicity() does not.
This inconsistency could be one cause of the logging issues in legacy/trac#24841.
We should allow IPv6 connections to be canonical. We should also do some cleanup of the related connection address logging in legacy/trac#33898.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33898Stop modifying addr on connections, and delete real_addr2021-09-16T14:21:51ZteorStop modifying addr on connections, and delete real_addrIn connection_or_check_canonicity(), we overwrite conn.addr with the canonical address of the relay in the consensus. That makes accurate logging impossible.
And so we also need channel.real_addr, to store the actual address of the remo...In connection_or_check_canonicity(), we overwrite conn.addr with the canonical address of the relay in the consensus. That makes accurate logging impossible.
And so we also need channel.real_addr, to store the actual address of the remote peer. And for some reason, we also have conn.address, a string copy of the peer's canonical address and port.
See:
https://github.com/torproject/tor/blob/7f9eaec538b7d01e0d1b130dc4cf2ec634252d46/src/core/or/connection_or.c#L920
This is... a mess.
Here's the high-level interface I'd like to see:
* use a function to format a connection or channel addresses for loogging
* use exactly as many address and port variables as needed in connection and channel (no extras!)
* qualify each address and port variable's name with its purpose
For example, here's one possible design:
* delete addr, port, address, and real_addr
* add remote_ap, a tor_addr_port_t that is the remote address and port of the TCP connection to the remote peer
* implement connection_describe(), which:
* formats remote_ap,
* formats is_canonical (and any other useful info), and
* calls node_describe() to format the canonical IPv4 and IPv6 addresses and ports of the remote peer.
We may also need separate fields for reverse proxied addresses, see the comment at:
https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339
If we need separate variables or functions for channels, we can use a similar design. (But ideally, re-using as many functions and variables as possible.)
This is important for Sponsor 55: getting accurate connection information will make diagnosing bugs much easier.
Current subtasks:
* [x] #40040 Document behavior of addr/address/real_addr fields
* [x] #40041 Add "describe connection" and "describe peer" functions.
* [ ] #40042 Give `or_connection_t` "canonical addr" instead of "real addr"Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33883Fix typo in router_build_fresh_unsigned_routerinfo() comment2020-06-27T13:47:53ZNeel Chauhanneel@neelc.orgFix typo in router_build_fresh_unsigned_routerinfo() commentThis comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```This comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33880Confusing "Your relay has a very large number of connections to other relays"...2021-07-09T17:22:52ZRoger DingledineConfusing "Your relay has a very large number of connections to other relays" relay messageA new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relay...A new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relays. Found 13 current canonical connections, in 0 of which we were a
non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and
0 had more than 4 connections.
```
I checked, and their outbound address was the same as their relay address.
Upon investigation, it looks like the redundant connections are to directory authorities.
My theory is that the change from legacy/trac#17592 (which went into 0.3.1.1-alpha, commit d5a151a0) is responsible: while before that canonical relay-to-relay connections would expire after either side first reached its randomized "15 to 22.5 minute" timeout, now they expire after either side reaches its "45 to 75 minute" timeout. And since directory authorities test reachability every 1280 seconds (around 21.3 minutes), that means it is expected that most relays will have duplicate canonical connections with directory authorities.
Possible fixes:
(A) Change the notice-level log to make it clearer that it's not scary, or at least it's not actionable. Maybe that means making it info-level so nobody will see it. Probably not the best option, assuming there *are* cases where we do want relay operators to hear it.
(B) In channel_check_for_duplicates(), change `MIN_RELAY_CONNECTIONS_TO_WARN 5` to a high enough number that even if we have 2 canonical conns per authority, plus a bit more, the log message still doesn't trigger.
(C) In channel_check_for_duplicates(), skip over connections to directory authorities in some way, since we know they will be special.
(D) Make connections to or from directory authorities expire quicker, on the theory that they don't really need the same level of padding protection as other connections.
(E) Your idea here?
I'd be fine with any of B,C,D. Whichever one can be done with an easy, short, and non-invasive patch is my favorite. Maybe that's "B, raise it to 30"? That would make the message trigger when we have connections to more than 30 relays and also we have more than 45 connections open. Or we could pick the more conservative "raise it to 40", on the theory that small numbers are more likely to have edge cases and less indicative of major network problems anyway.
And while we're at it, it might be smart to say in the log message what action we want the relay operator take, e.g. "Please report:".Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33873client: Send back SOCKS extended error F6 in case of bad hostname2021-06-23T17:22:42ZDavid Gouletdgoulet@torproject.orgclient: Send back SOCKS extended error F6 in case of bad hostnameWith the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoie...With the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoieqw.onion`.
Problem is that we only send back the `F6` code if the address was identified, by length, as a v3. We should handle the `BAD_HOSTNAME` error code from `parse_extended_hostname()` and thus send back that extended error.Tor: 0.4.4.x-finalGuinnessGuinnesshttps://gitlab.torproject.org/tpo/core/tor/-/issues/33870vanguards: Vanguards silently fail on certain condition2020-07-30T18:47:31Zcypherpunksvanguards: Vanguards silently fail on certain condition1. Configure torrc file (add some HiddenService lines)
2. Edit vanguards.conf like below:
```
# IP address that the Tor control port is listening on:
control_ip =
# TCP port the control port is listening on:
control_port =
# If set,...1. Configure torrc file (add some HiddenService lines)
2. Edit vanguards.conf like below:
```
# IP address that the Tor control port is listening on:
control_ip =
# TCP port the control port is listening on:
control_port =
# If set, use this filesystem control socket instead of IP+Port:
control_socket = /run/tor/control
# If set, use this as the control port password:
control_pass =
```
```
# The current loglevel:
loglevel = NOTICE
# If specified, log to this file instead of stdout:
logfile = /tmp/vandebugger
```
3. Restart vanguards (service vanguards stop;service vanguards start)
4. Run 'ps axu|grep pypy' - you'll find vanguards is running
5. Now wait 1 minute
---
What will happen:
1. Vanguards silently exit itself. /tmp/vandebugger logged nothing.
2. However if you read syslog you'll find this line:
```
Specified config file /meow/vanguards.conf can't be read: invalid literal for int() with base 10: ''
```
How to fix:
Setting 'control_port = ' to 'control_port = 9876' fixed this.
What do I want:
Error should not be raised if the user set 'control_port' empty string.
#NoGithub #ILikeYourAddonMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33850log rotation for /var/log/tor/debug.log did not close handle to old file afte...2020-10-29T15:21:31ZTraclog rotation for /var/log/tor/debug.log did not close handle to old file after compressionso / ran full after a week or so. I found the culprits with:
find /proc/*/fd -ls | grep '(deleted)'
Version: tor 0.4.2.7-1~d8.jessie+1
Config:
Standard torrc with one Hidden service, using an HTTPSProxy and notice+debug logging enabl...so / ran full after a week or so. I found the culprits with:
find /proc/*/fd -ls | grep '(deleted)'
Version: tor 0.4.2.7-1~d8.jessie+1
Config:
Standard torrc with one Hidden service, using an HTTPSProxy and notice+debug logging enabled:
Log notice file /var/log/tor/notices.log
Log debug file /var/log/tor/debug.log
**Trac**:
**Username**: MaKoTorTor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33843Write detailed priority queue scheduler design on the proposal2022-10-11T23:39:34ZGeorge KadianakisWrite detailed priority queue scheduler design on the proposalTor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33839Correct 'was not internal' to 'was internal' in test_external_ip()2020-06-27T13:47:55ZTracCorrect 'was not internal' to 'was internal' in test_external_ip()source: https://github.com/torproject/tor/pull/1856
Fixing a typo in a string that is printed on event of a test failing, in `src/test/test_addr.c`.
**Trac**:
**Username**: kimimarosource: https://github.com/torproject/tor/pull/1856
Fixing a typo in a string that is printed on event of a test failing, in `src/test/test_addr.c`.
**Trac**:
**Username**: kimimaroTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33837Tor.framework Unknown type name 'dispatch_queue_t'2020-06-27T13:47:55ZteorTor.framework Unknown type name 'dispatch_queue_t'From https://trac.torproject.org/projects/tor/ticket/33522#comment:2
>
> Replying to [tla](legacy/trac#33522):
> > It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
> >
> > https://github.c...From https://trac.torproject.org/projects/tor/ticket/33522#comment:2
>
> Replying to [tla](legacy/trac#33522):
> > It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
> >
> > https://github.com/iCepa/Tor.framework/blob/master/.travis.yml
> >
> >
> > Currently, we have issues in getting past Tor 0.4.0.6 on iOS. When I try to use a newer core, I get this error message:
> >
> > > Unknown type name 'dispatch_queue_t'
> >
> > in CFStream of Apple's CoreFoundation framework.
> >
> >
> > But "dispatch_queue_t" is actually a valid symbol from Apple's Foundation libraries.
> >
> > So somehow, it gets cancelled out through something which changed in Tor recently.
>
> This looks like a bug in tor's code, or perhaps in the Tor.framework embedding scripts.
>
> We'd be happy to help you diagnose this issue.
>
> Can you tell us the first release that has this issue? Is it 0.4.1, 0.4.2, or 0.4.3 ?
> Have you done a git bisect, to track down the commit that introduced the issue?
>
> Let's open a separate ticket, so we can fix this bug in tor's code.
> Or help you find a workaround when you embed tor.
I can't see dispatch_queue_t in Tor's code.
Perhaps we're defining some preprocessor symbols, or including a header that conflicts with dispatch_queue_t's header.
We don't know which release this bug was introduced in. But Tor 0.4.0.6 does not have this error.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33804Defer "PreferIPv6 by default" to 0.4.42020-06-27T13:47:56ZteorDefer "PreferIPv6 by default" to 0.4.4In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement ...In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-only resolves for torsocks.
Since legacy/trac#32637, we have also merged:
* legacy/trac#33608, which removes a forced PreferIPv6 for non-SOCKSPorts
* legacy/trac#32994, which puts the PreferIPv6 default in port_parse_config(), rather than in 2 different places in the code
So it should be very easy to change the default for PreferIPv6.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33796socks: Prefer IPv6 by default on SOCKS port broke torsocks: re-enable a bette...2021-09-07T20:13:48ZDavid Gouletdgoulet@torproject.orgsocks: Prefer IPv6 by default on SOCKS port broke torsocks: re-enable a better version after 0.4.4?In commit `bf2a399fc0d90df76e091fa3259f7c1b8fb87781` we made all SocksPort to prefer IPv6 which means that any DNS resolution answer will pick IPv6, if exists, over IPv4.
For torsocks, this is a problem because by default it tries to re...In commit `bf2a399fc0d90df76e091fa3259f7c1b8fb87781` we made all SocksPort to prefer IPv6 which means that any DNS resolution answer will pick IPv6, if exists, over IPv4.
For torsocks, this is a problem because by default it tries to resolve an IPv4. This can be fixed _except_ when the libc call (ex: `getaddrinfo()`) is specifically requesting an IPv4 (`hints.ai_family = AF_INET`).
There is currently no way for torsocks to ask tor, via the SocksPort, a specific INET family and thus torsocks receives back the IPv6 and can't handle it because the application was expecting an IPv4.
So this example fails often as we have more and more Exits are able to resolve IPv6:
```
wget -4 some.url
```
And still many applications by default will request an IPv4 because they don't handle IPv6.
Bottom line is that torsocks use case is broken for when an application is specifically requesting an INET family...
As a reminder, torsocks can _not_ pass the hostname directly in the SOCKS connection because it hijacks libc calls and thus flow can only be 1) DNS resolution, 2) `connect()` with an IP address.
I'm not sure what to do here... I think the ideal scenario would be to have a way for our "resolve" SOCKS extension to specify an address family value.
For instance, the `F0` (`RESOLVE` command) would be "return whatever" and then we could extend to have `RESOLVE4` and `RESOLVE6`..... HACK-ish but those extensions are already a hack so...
(That prefer IPv6 change went in 043)David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33794hs-v3: OnionBalance backend instances all fail after more introductions by hi...2021-06-23T17:22:42Zs7rhs-v3: OnionBalance backend instances all fail after more introductions by hitting descriptor upload time limitsWe fixed legacy/trac#33762 and thought that was the problem (which it also was) but after fixing that I have discovered that all onionbalance backend instances continue to die after testing and testing (establishing successful RP circuit...We fixed legacy/trac#33762 and thought that was the problem (which it also was) but after fixing that I have discovered that all onionbalance backend instances continue to die after testing and testing (establishing successful RP circuits with the frontend) and never heal unless Tor processes of the backends are restarted.
I was instructed by asn on IRC to look between the time of SIGHUP (logrotate log file change) and time of:
```
[warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_circuit.c:987: get_subcredential_for_handling_intro2_cell: Non-fatal assertion !(!service->ob_subcreds) failed. (on Tor 0.4.4.0-alpha-dev )
```
for the message
```
log_info(LD_REND, "Hidden service %s next descriptor successfully "
"built. Now scheduled for upload.",
```
Which meant that it eventually recovered by itself. I can see two of those messages in ~24 hours, but the backend instances continue to be unavailable. Frontend does not work, and even if you try to connect to the backend address directly instead of the frontend one it does not work.
It looks like it is never able to upload further descriptors at some point, flooding the log file with:
```
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585748071. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585748071. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585748671. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585748671. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585749271. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585749271. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585749871. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585749871. [598 similar message(s) suppressed in last 600 seconds]
```
I have info log level files from 2 backend instances of like ~47 MB each.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33788Check the return value of tor_inet_ntop() and tor_inet_ntoa()2021-08-23T15:12:44ZteorCheck the return value of tor_inet_ntop() and tor_inet_ntoa()The following functions don't check the return value of tor_inet_ntop() or tor_inet_ntoa():
IPv6, could be serious:
* evdns_callback(), multiple times
IPv4 only, unlikely to be a serious bug:
* tor_dup_ip()
* fmt_addr32()
* evdns_wildc...The following functions don't check the return value of tor_inet_ntop() or tor_inet_ntoa():
IPv6, could be serious:
* evdns_callback(), multiple times
IPv4 only, unlikely to be a serious bug:
* tor_dup_ip()
* fmt_addr32()
* evdns_wildcard_check_callback()
These functions should log a bug log using BUG() or tor_assert_nonfatal(), and return an error. (Or for the formatting functions, a sensible placeholder string.)
We will also need to make their callers check for the error.Tor: 0.4.4.x-final