Opened 6 years ago

Closed 6 years ago

#9771 closed defect (fixed)

Torflow logs hint that it's crazily misparsing control protocol lines

Reported by: arma Owned by: aagbsn
Priority: Medium Milestone:
Component: Core Tor/Torflow Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Here's a line from my data/scanner.1/bw.log file:

DEBUG[Wed Sep 18 18:50:22 2013]:0.000684022903442 CIRC 1048265 BUILT $4D8AB52858C08B65CD9119592F2C4A0AC295A167,$68EB5D04D9E81B3EF07B30E6A1710478F3BE50C6 REASON=EATED=2013-09-18T22:50:22.246008

EATED? For real? and that's the REASON?

And here's another

DEBUG[Wed Sep 18 19:03:43 2013]:57.2632410526 CIRC 1048359 CLOSED $8DC59FB04EA3EC881D14E1CD806E9CF5B63EFA9E,$CDE18EB5FF62D741681F779CEA483C67A09C675F REASON=EATED=2013-09-18T22:58:56.688748 REMOTE_REASON=ED

ED, huh?

Child Tickets

Change History (5)

comment:1 Changed 6 years ago by aagbsn

It looks like the TIME_CREATED field is unexpected by pyTorCtl.

torspec.git commit 2f040bc03e61d1eef482e6e170ba9de1a3fd434a adds new fields

The _decode1 function in pytorctl/ isn't very flexible and doesn't comply with the control spec:

" Clients SHOULD NOT depend on the order of keyword=value arguments,

and SHOULD NOT depend on there being no new keyword=value arguments
appearing between existing keyword=value arguments, though as of this
writing (Jun 2011) some do.

So, I guess we've known about this for some time :\

comment:2 Changed 6 years ago by aagbsn

Here's an potential fix:

Doesn't seem to explode and I am not getting EATED any more :)

comment:3 Changed 6 years ago by aagbsn

Resolution: fixed
Status: newclosed


comment:4 Changed 6 years ago by arma

Resolution: fixed
Status: closedreopened

I don't think you changed torflow to think that it should use a newer pytorctl.

comment:5 Changed 6 years ago by aagbsn

Resolution: fixed
Status: reopenedclosed

Good catch. Updated.

Note: See TracTickets for help on using tickets.