Re: [tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

[Tor Bug Tracker & Wiki]

#33581: Restore bridge networkstatus checks in chutney
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33582| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-can
--+---
Description changed by teor:

Old description:

> This issue depends on the tor bridge descriptor upload fix in #33582, or
> robust reachability self-tests in #33222.
>
> In chutney networks, there's a race condition when bridges try to publish
> their descriptor to the bridge authority:
> * bridges try to publish their descriptors before bootstrapping
> * but bridges can't publish their descriptors, because they don't have
> enough directory info to build a circuit to the bridge authority
>
> Also, bridges do not retry publishing their descriptor immediately after
> they bootstrap.
>
> We can only do the networkstatus-bridges check on tor versions with the
> #33222 or #33582 fixes. So we'll need to check for:
> * the next tor 0.4.4-alpha version, or
> * an environmental variable that enables these tests.
>
> We don't have to do these fixes, because it should be enough to test
> relay reachability. But we would risk breaking bridge reachability tests,
> and not knowing about it until after a release.
>
> Also, the chutney workarounds seem to cause weird race conditions, which
> are time-consuming to diagnose and fix.

New description:

 This issue depends on the tor bridge descriptor upload fix in #33582,
 robust reachability self-tests in #33222, or bridge log checks in #34037.

 In chutney networks, there's a race condition when bridges try to publish
 their descriptor to the bridge authority:
 * bridges try to publish their descriptors before bootstrapping
 * but bridges can't publish their descriptors, because they don't have
 enough directory info to build a circuit to the bridge authority

 Also, bridges do not retry publishing their descriptor immediately after
 they bootstrap.

 We can only do the networkstatus-bridges check on tor versions with the
 #33222 or #33582 fixes. So we'll need to check for:
 * the next tor 0.4.4-alpha version, or
 * an environmental variable that enables these tests.

 We don't have to do these fixes, because it should be enough to test relay
 reachability. But we would risk breaking bridge reachability tests, and
 not knowing about it until after a release.

 Also, the chutney workarounds seem to cause weird race conditions, which
 are time-consuming to diagnose and fix.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

[Tor Bug Tracker & Wiki]

#33581: Restore bridge networkstatus checks in chutney
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33582| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-can
--+---

Old description:

> This issue depends on the tor bridge descriptor upload fix in #33582, or
> robust reachability self-tests in #33222.
>
> In chutney networks, there's a race condition when bridges try to publish
> their descriptor to the bridge authority:
> * bridges have AssumeReachable set
> * bridges try to publish their descriptors before bootstrapping
> * but bridges can't publish their descriptors, because they don't have
> enough directory info to build a circuit to the bridge authority
>
> Also, bridges do not retry publishing their descriptor immediately after
> they bootstrap.
>
> We can only do the networkstatus-bridges check on tor versions with the
> #33222 or #33582 fixes. So we'll need to check for:
> * the next tor 0.4.4-alpha version, or
> * an environmental variable that enables these tests.
>
> We don't have to do these fixes, because it should be enough to test
> relay reachability. But we would risk breaking bridge reachability tests,
> and not knowing about it until after a release.
>
> Also, the chutney workarounds seem to cause weird race conditions, which
> are time-consuming to diagnose and fix.

New description:

 This issue depends on the tor bridge descriptor upload fix in #33582, or
 robust reachability self-tests in #33222.

 In chutney networks, there's a race condition when bridges try to publish
 their descriptor to the bridge authority:
 * bridges try to publish their descriptors before bootstrapping
 * but bridges can't publish their descriptors, because they don't have
 enough directory info to build a circuit to the bridge authority

 Also, bridges do not retry publishing their descriptor immediately after
 they bootstrap.

 We can only do the networkstatus-bridges check on tor versions with the
 #33222 or #33582 fixes. So we'll need to check for:
 * the next tor 0.4.4-alpha version, or
 * an environmental variable that enables these tests.

 We don't have to do these fixes, because it should be enough to test relay
 reachability. But we would risk breaking bridge reachability tests, and
 not knowing about it until after a release.

 Also, the chutney workarounds seem to cause weird race conditions, which
 are time-consuming to diagnose and fix.

--

Comment (by teor):

 AssumeReachable isn't required to trigger this issue.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

[Tor Bug Tracker & Wiki]

#33581: Restore bridge networkstatus checks in chutney
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33582| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-can
--+---
Description changed by teor:

Old description:

> This issue depends on the tor bridge descriptor upload fix in #33582, or
> robust reachability self-tests in #33222.
>
> In chutney networks, there's a race condition when bridges try to publish
> their descriptor to the bridge authority:
> * bridges have AssumeReachable set
> * bridges try to publish their descriptors before bootstrapping
> * but bridges can't publish their descriptors, because they don't have
> enough directory info to build a circuit to the bridge authority
>
> Also, bridges do not retry publishing their descriptor immediately after
> they bootstrap.
>
> We can only do the networkstatus-bridges check on tor versions with the
> #33222 or #33582 fixes. So we'll need to check for:
> * the next tor 0.4.4-alpha version, or
> * an environmental variable that enables these tests.
>
> We don't have to do these fixes, because it should be enough to test
> relay reachability. But we would risk breaking bridge reachability tests,
> and not knowing about it until after a release.

New description:

 This issue depends on the tor bridge descriptor upload fix in #33582, or
 robust reachability self-tests in #33222.

 In chutney networks, there's a race condition when bridges try to publish
 their descriptor to the bridge authority:
 * bridges have AssumeReachable set
 * bridges try to publish their descriptors before bootstrapping
 * but bridges can't publish their descriptors, because they don't have
 enough directory info to build a circuit to the bridge authority

 Also, bridges do not retry publishing their descriptor immediately after
 they bootstrap.

 We can only do the networkstatus-bridges check on tor versions with the
 #33222 or #33582 fixes. So we'll need to check for:
 * the next tor 0.4.4-alpha version, or
 * an environmental variable that enables these tests.

 We don't have to do these fixes, because it should be enough to test relay
 reachability. But we would risk breaking bridge reachability tests, and
 not knowing about it until after a release.

 Also, the chutney workarounds seem to cause weird race conditions, which
 are time-consuming to diagnose and fix.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

[Tor Bug Tracker & Wiki]

#33581: Restore bridge networkstatus checks in chutney
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33582| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-can
--+---
Description changed by teor:

Old description:

> In chutney networks, there's a race condition when bridges try to publish
> their descriptor to the bridge authority:
> * bridges have AssumeReachable set
> * bridges try to publish their descriptors before bootstrapping
> * but bridges can't publish their descriptors, because they don't have
> enough directory info to build a circuit to the bridge authority
>
> Also, bridges do not retry publishing their descriptor immediately after
> they bootstrap.
>
> Once we fix #33582, we can fix this issue.

New description:

 This issue depends on the tor bridge descriptor upload fix in #33582, or
 robust reachability self-tests in #33222.

 In chutney networks, there's a race condition when bridges try to publish
 their descriptor to the bridge authority:
 * bridges have AssumeReachable set
 * bridges try to publish their descriptors before bootstrapping
 * but bridges can't publish their descriptors, because they don't have
 enough directory info to build a circuit to the bridge authority

 Also, bridges do not retry publishing their descriptor immediately after
 they bootstrap.

 We can only do the networkstatus-bridges check on tor versions with the
 #33222 or #33582 fixes. So we'll need to check for:
 * the next tor 0.4.4-alpha version, or
 * an environmental variable that enables these tests.

 We don't have to do these fixes, because it should be enough to test relay
 reachability. But we would risk breaking bridge reachability tests, and
 not knowing about it until after a release.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

[Tor Bug Tracker & Wiki]

#33581: Restore bridge networkstatus checks in chutney
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33582| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-can
--+---
Changes (by teor):

 * parent:  #33232 => #33582


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

[Tor Bug Tracker & Wiki]

#33581: Restore bridge networkstatus checks in chutney
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33232| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-can
--+---
Changes (by teor):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

[Tor Bug Tracker & Wiki]

#33581: Restore bridge networkstatus checks in chutney
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33232| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-can
--+---
Changes (by teor):

 * owner:  teor => (none)
 * sponsor:  Sponsor55-must => Sponsor55-can


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

[Tor Bug Tracker & Wiki]

#33581: Restore bridge networkstatus checks in chutney
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:
Parent ID:  #33232| Points:  0.1
 Reviewer:|Sponsor:  Sponsor55-must
--+
Description changed by teor:

Old description:

> In chutney networks, there's a race condition when bridges try to publish
> their descriptor to the bridge authority:
> * bridges have AssumeReachable set
> * bridges try to publish their descriptors before bootstrapping
> * but bridges can't publish their descriptors, because they don't have
> enough directory info to build a circuit to the bridge authority
>
> Also, bridges do not retry publishing their descriptor immediately after
> they bootstrap.
>
> Once we make bridges do reachability checks in chutney, they will wait to
> bootstrap, do reachability checks, then try to publish their descriptors.
>
> So we can enable the bridge networkstatus checks again.

New description:

 In chutney networks, there's a race condition when bridges try to publish
 their descriptor to the bridge authority:
 * bridges have AssumeReachable set
 * bridges try to publish their descriptors before bootstrapping
 * but bridges can't publish their descriptors, because they don't have
 enough directory info to build a circuit to the bridge authority

 Also, bridges do not retry publishing their descriptor immediately after
 they bootstrap.

 Once we fix #33582, we can fix this issue.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs