> On 6 May 2016, at 09:34, Xiaofan Li <[email protected]> wrote: > > Hi all, > We've finished building TOR on QUIC and everything works fine with chutney. > However, we have an issue with the node availability when we test on real > networks. We need this to work in order to evaluate the effect of HOL > blocking with QuicTor vs. Tor.
What do you mean by a "real network"? Do you mean a test network with your own authorities on non-localhost IP addresses? > Specifically: > • When using our QuicTor and normal TOR without path restriction, > warning messages like: [warn] Failed to find node for hop 1 of our path. > Discarding this circuit. Keeps showing up but the node would actually reach > 100% bootstrap and all file transfer functionalities work fine. That's not a normal error message. Perhaps you have found a bug in an unstable version of Tor - it might be wise to rebase on 0.2.7.6. Perhaps your Tor configuration or network configuration are broken. It's hard to tell without more information. Try telling your authorities to have your client only use 1 guard: ConsensusParams NumDirectoryGuards=1 NumEntryGuards=1 (Normally, a client won't re-use any of its 3 guards as a middle or exit. TestingTorNetwork disables this behaviour. These parameters make it so each client only selects 1 guard.) What other log messages does Tor give just before or after that message? What log messages does Tor give that mention "guard"? > • However, our real issue is when I restrict the path selection to 3 > pre-determined nodes for all exit circuits, the client will not reach 100% > anymore and keeps hanging at 85% (or 80% sometimes). Does this happen with both Tor and QuicTor? Perhaps you are using options that restrict path selection in a way that breaks on non-test networks. Perhaps your restrictions conflict with options that change between your chutney and "real" networks. (Or are you implementing these path restrictions in code?) Perhaps you have found a bug in an unstable version of Tor - it might be wise to rebase on 0.2.7.6. It's hard to tell without more information. What torrc options are you using on the client to restrict paths? EntryNodes, ExitNodes, StrictNodes? How do you restrict the middle node? What do "80%" and "85%" mean to your client? What other log messages does Tor give just before or after those messages? What are the proportions of Guard, Middle, and Exit relay descriptors that Tor logs as it bootstraps? Does Tor warn you about your path restrictions? I also wonder why you need to use path restrictions at all. Can't you just put 3 authorities and no relays in your network, and there will be only one possible path? (Of course, those relays could be selected in any order.) Or you could modify the functions that do path selection so they use the same 3 hard-coded relays every time. > • We've thoroughly tested path restriction with chutney and it works. > Our network has 11 nodes: 3 clients and 8 relays (2 of which are > authorities). We already have assumeReachable and I've tuned up voting > frequencies, just like chutney's default config. Any other configuration flag > that could help propagating router availability info? If you give one node the Guard flag, and only one node exits anywhere, then that's your path. Try using the following options on your authorities: TestingDirAuthVoteGuard <guard-fingerprint> TestingDirAuthVoteGuardIsStrict 1 TestingDirAuthVoteExit <exit-fingerprint> TestingDirAuthVoteExitIsStrict 1 You could try comparing the options that chutney sets with the "real network" options you're using, and switching one chutney option to a real network option until the bug occurs. Remember that "TestingTorNetwork" changes a lot of options at once. It's the one I'd try first. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
