feat(x) explicit timeout in psiphon-fetch start #402
Conversation
| @@ -80,7 +80,9 @@ func main() { | |||
|
|
|||
| // Start the Psiphon dialer. | |||
| dialer := psiphon.GetSingletonDialer() | |||
| if err := dialer.Start(context.Background(), config); err != nil { | |||
| ctx, cancel := context.WithTimeout(context.Background(), 30 * time.Second) | |||
There was a problem hiding this comment.
This is not a dial timeout. It's a start timeout.
It's not how Psiphon is intended to work. It's supposed to keep running in the background.
Though, it should fail quickly if the config is invalid. Can you file a bug on their repository?
There was a problem hiding this comment.
done.
From trawling their code I don't think it's a bug. The 5m timeout is set deliberately here. I guess they set it so high to allow for really adverse network condition. But our fetch tool doesn't need to be so accommodating.
I didn't spend too long looking at the psiphon design, but I'm assuming they simply don't respond to made up IDs because they want to avoid an adversary being able to enumerate all the IDs.
You've definitely spend more time looking at the psiphon design than I have, do you know something that would contradict that?
ohnorobo
changed the title
Currently the psiphon-fetch start defaults to psiphon's internal 5m start timeout, which seems too long. For any invalid but valid-enough (meaning containing any
PropagationChannelId+SponsorId) config it hangs for a long time.I'm not particularly married to the 30s
Current behavior
running
go run -C ./examples/fetch-psiphon -tags psiphon . -config minimal_config.json -v https://ipinfo.ioWhere the content of
minimal_config.jsonis{ "PropagationChannelId":"ID1", "SponsorId":"ID2" }hangs for 5 minutes before failing with the error
Could not start dialer: clientlib: tunnel establishment timeouterror linkAfter this change
It fails in 30s