Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:52:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16AttributeError: 'NoneType' object has no attribute 'getLastHop'2020-06-13T14:52:42Zweasel (Peter Palfrader)AttributeError: 'NoneType' object has no attribute 'getLastHop'[Moved from bugzilla]
Reporter: peter@palfrader.org (Peter Palfrader)
Description:
Opened: 2003-10-27 20:33
latest CVS (as of now).
weasel@valiant:~/mixminion/bin$ ./mixminion generate-surb -t
peter-mm@palfrader.org -P 'test1' >...[Moved from bugzilla]
Reporter: peter@palfrader.org (Peter Palfrader)
Description:
Opened: 2003-10-27 20:33
latest CVS (as of now).
weasel@valiant:~/mixminion/bin$ ./mixminion generate-surb -t
peter-mm@palfrader.org -P 'test1' > mm1
Oct 27 20:31:49.836 [WARN] This software is newer than any version on the
recommended list.
Oct 27 20:31:49.849 [INFO] Selected path is :test1
Enter password for keyring:
weasel@valiant:~/mixminion/bin$ echo bla | ./mixminion send -R mm1 -P 'test1'
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Oct 27 20:32:03.836 [WARN] This software is newer than any version on the
recommended list.
Traceback (most recent call last):
File "./mixminion", line 10, in ?
mixminion.Main.main(sys.argv)
File "/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/Main.py",
line 282, in main
func(commandStr, args[2:])
File "/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/
ClientMain.py", line 1017, in runClient
parser.parsePath()
File "/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/
ClientMain.py", line 871, in parsePath
self.startAt, self.endAt)
File "/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/
ClientDirectory.py", line 712, in validatePath
lh = exitAddress.getLastHop()
AttributeError: 'NoneType' object has no attribute 'getLastHop'
------- Additional Comments From Nick Mathewson 2003-11-07 08:29 -------
This should be fixed in 0.0.6 CVS.
[Automatically added by flyspray2trac: Operating System: Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15can't even start 0.0.6alpha12020-06-16T00:58:34Zweasel (Peter Palfrader)can't even start 0.0.6alpha1[Moved from bugzilla]
Reporter: qumqats@outel.org (Joel M. Baldwin)
Description:
Opened: 2003-10-27 11:25
as you can see from the following, I can't even get the latest CVS of 0.0.6 to
start.
bash-2.05b# /usr/local/etc/rc.d/minion...[Moved from bugzilla]
Reporter: qumqats@outel.org (Joel M. Baldwin)
Description:
Opened: 2003-10-27 11:25
as you can see from the following, I can't even get the latest CVS of 0.0.6 to
start.
bash-2.05b# /usr/local/etc/rc.d/minion.sh start
mixminion
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Reading configuration from /home/minion/etc/mixminiond.conf
Silencing the console log; look in /home/minion/log/log instead
Oct 27 02:17:37.553 [DEBUG] Configuring server
Oct 27 02:17:37.554 [INFO] Starting server in the background
bash-2.05b# Oct 27 02:17:37.571 [INFO] Enabling statistics logging
Oct 27 02:17:37.575 [DEBUG] Syncing statistics to disk
Oct 27 02:17:37.577 [INFO] Statistics logging enabled
Oct 27 02:17:37.579 [INFO] Setting entropy source to '/dev/urandom'
Oct 27 02:17:37.581 [DEBUG] Initializing server
Oct 27 02:17:37.586 [DEBUG] Scanning server keystore at /home/minion/keys
Oct 27 02:17:37.772 [DEBUG] Found 1 keysets: 0 were incomplete or invalid.
Oct 27 02:17:37.774 [INFO] Last expiry at 2003/11/25 16:00:00; next keygen at
2003/11/09 03:00:00
Oct 27 02:17:37.786 [WARN] Some generated keysets do not match current
configuration...
Oct 27 02:17:37.787 [WARN] Keyset 0002 (2003/08/27 17:00:00--2003/11/25 16:00:
00):
Oct 27 02:17:37.788 [WARN] Mismatched versions: running 0.0.6alpha1; Mixminion
0.0.5.1 in unpublished descriptor.
Oct 27 02:17:37.789 [WARN] Mismatched hostnames: privacy.outel.org guessed; None
in unpublished descriptor
Oct 27 02:17:37.790 [WARN] Mismatched platform summary
Oct 27 02:17:37.900 [INFO] Regenerating descriptor for keyset 0002 (2003/08/27
17:00:00--2003/11/25 16:00:00)
Oct 27 02:17:38.983 [WARN] No Hostname configured; guessing privacy.outel.org
Oct 27 02:17:39.002 [INFO] Module MBOX: enabled for types ['0x101']
Oct 27 02:17:40.471 [INFO] Module DROP: enabled for types ['0x0']
Oct 27 02:17:40.471 [DEBUG] Disabling module SMTP
Oct 27 02:17:40.472 [DEBUG] Disabling module SMTP_MIX2
Oct 27 02:17:40.473 [INFO] Module FRAGMENT: enabled for types ['0x103']
Oct 27 02:17:40.529 [DEBUG] Opening fragment database at
/home/minion/work/queues/deliver/FRAGMENT_db
Oct 27 02:17:41.097 [INFO] Publishing 1 keys to directory server...
Oct 27 02:17:50.345 [INFO] Directory accepted descriptor: 'Accepted.'
Oct 27 02:17:50.347 [INFO] All keys published successfully.
Oct 27 02:17:50.348 [DEBUG] Initializing packet handler
Oct 27 02:17:50.349 [DEBUG] Initializing MMTP server
Oct 27 02:17:50.350 [FATAL] Exception while configuring server
Oct 27 02:17:50.368 [FATAL] Traceback (most recent call last):
File "/home/minion/lib/python2.3/site-packages/mixminion/server/ServerMain.
py", line 1093, in runServer
server = MixminionServer(config)
File "/home/minion/lib/python2.3/site-packages/mixminion/server/ServerMain.
py", line 673, in __init__
self.mmtpServer = _MMTPServer(config, None)
File "/home/minion/lib/python2.3/site-packages/mixminion/server/ServerMain.
py", line 359, in __init__
mixminion.server.MMTPServer.MMTPAsyncServer.__init__(
File "/home/minion/lib/python2.3/site-packages/mixminion/server/MMTPServer.
py", line 1072, in __init__
ip4_supported, ip6_supported = mixminion.NetUtils.getProtocolSupport()
NameError: global name 'mixminion' is not defined
Oct 27 02:17:50.369 [FATAL] Shutting down because of exception: exceptions.
NameError
------- Additional Comments From Nick Mathewson 2003-11-05 07:49 -------
I'll fix this (inevitibly) as I work on minion this week.
------- Additional Comments From Nick Mathewson 2003-11-07 09:12 -------
Fixed in 0.0.6 CVS.
[Automatically added by flyspray2trac: Operating System: FreeBSD]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/14This server's files are stored in an older format2020-06-16T00:58:34Zweasel (Peter Palfrader)This server's files are stored in an older format[Moved from bugzilla]
Reporter: peter@palfrader.org (Peter Palfrader)
Description:
Opened: 2003-10-19 23:46
After copying the mixminiond.conf config file from the etc directory of the
tarball and modifying it to set local settings, ...[Moved from bugzilla]
Reporter: peter@palfrader.org (Peter Palfrader)
Description:
Opened: 2003-10-19 23:46
After copying the mixminiond.conf config file from the etc directory of the
tarball and modifying it to set local settings, when one tried to start the
server one is told to run server-upgrade.
weasel@valiant:~/mixminion/bin$ ./mixminion server-start -f
../etc/mixminiond.conf
Mixminion version 0.0.5.1
This software is for testing purposes only. Anonymity is not guaranteed.
Reading configuration from ../etc/mixminiond.conf
Oct 19 23:44:42.841 [WARN] Mode specification is not yet supported.
Oct 19 23:44:42.842 [WARN] Dangerously low MixInterval
This server's files are stored in an older format, and are not compatible
with this version of the mixminion server. To upgrade, run:
'mixminion server-upgrade'.
Same happens with current CVS.
Maybe the shipped sample mixminiond.conf file should have a current format.
------- Additional Comments From Nick Mathewson 2003-10-20 20:47 -------
Actually, this is not the bug you think it is. The problem isn't with
mixminiond.conf, but with a file named 'version' in your server's homedir: it is
supposed to contain the current version of the directory layout. Currently,
this is the string "1001". It has been "1001" since about 0.0.4, IIRC.
One of two things is the case:
1) You are upgrading from 0.0.3. (Not too likely.)
2) You somehow managed to get a directory created with no version file. (More
likely; I'll try to figure out how this could happen.)
Also, it is definitely the case that you got an error message not helpful to
you. Can you suggest a more useful one?
------- Additional Comments From Peter Palfrader 2003-10-20 21:01 -------
Ah, now I know what I was doing.
I was starting from scratch, so there was nothing in that dir before. Only a
bin, lib and etc file. I didn't realize that mixminion expected an empty dir as
its homedir.
Here's transcript of what I did:
weasel@valiant:~$ mkdir mixminion2
weasel@valiant:~$ ( cd projects/mixminion/src/minion; make install
PREFIX=/home/weasel/mixminion2 )
(...)
weasel@valiant:~$ cd mixminion2
weasel@valiant:~/mixminion2$ mkdir etc
weasel@valiant:~/mixminion2$ cp ~/projects/mixminion/src/minion/etc/mixminiond.c etc
<edit config file>
weasel@valiant:~/mixminion2$ grep \!^Homedir etc/mixminiond.conf
Homedir: /home/weasel/mixminion2
weasel@valiant:~/mixminion2$ bin/mixminion server-start -f etc/mixminiond.conf
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Reading configuration from etc/mixminiond.conf
This server's files are stored in an older format, and are not compatible
with this version of the mixminion server. To upgrade, run:
'mixminion server-upgrade'.
weasel@valiant:~/mixminion2$ ls -l
total 12
drwxr-xr-x 2 weasel weasel 4096 Oct 20 20:52 bin/
drwxrwxr-x 2 weasel weasel 4096 Oct 20 20:54 etc/
drwxr-xr-x 3 weasel weasel 4096 Oct 20 20:52 lib/
Maybe mixminion should say that it expects an empty directory as serverhome, or
a directory with a version file if none is found.
------- Additional Comments From Nick Mathewson 2004-02-21 01:45 -------
Okay. The bug seemed to be:
1 User configures server.
2 User creates home directory for server.
3 User starts server for the first time.
4 Server starts, notices that the directory doesn't have a "version" file
5 Server decides that it is looking at an obsolete directory.
6 Server freaks out and tells user to upgrade.
7 Recursively, user freaks out.
Now, there is a new step:
4.5 Since there is no version file, the server checks for "work" and "keys"
directories. If they were there, it would decide that it had an obsolete
direcotry. But since thay aren't, it decides that it just has an
uninitialized empty directory.
5' The server goes on to initialized a new file layout.
So I can't make the bug happen anymore, and I think it's gone.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/13IOError: [Errno 2] No such file or directory: '/home/weasel/mixminion/keys/ke...2020-06-16T00:58:34Zweasel (Peter Palfrader)IOError: [Errno 2] No such file or directory: '/home/weasel/mixminion/keys/key_0001/ServerDesc'[Moved from bugzilla]
Reporter: peter@palfrader.org (Peter Palfrader)
Description:
Opened: 2003-10-19 23:36
after generating keys failed (see bug#12), another ivocation of server-start
gives the following traceback. Maybe a missing...[Moved from bugzilla]
Reporter: peter@palfrader.org (Peter Palfrader)
Description:
Opened: 2003-10-19 23:36
after generating keys failed (see bug#12), another ivocation of server-start
gives the following traceback. Maybe a missing ServerDesc file should be
handled more gracefully, or different.
weasel@valiant:~/mixminion/bin$ ./mixminion server-start -f ../etc/mixminiond.conf
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Reading configuration from ../etc/mixminiond.conf
Oct 19 23:33:58.246 [WARN] Mode specification is not yet supported.
Oct 19 23:33:58.252 [WARN] Dangerously low MixInterval
Oct 19 23:33:58.256 [DEBUG] Configuring server
Oct 19 23:33:58.258 [INFO] Enabling statistics logging
Oct 19 23:33:58.270 [DEBUG] Syncing statistics to disk
Oct 19 23:33:58.284 [INFO] Statistics logging enabled
Oct 19 23:33:58.286 [INFO] Setting entropy source to '/dev/urandom'
Oct 19 23:33:58.299 [DEBUG] Initializing server
Oct 19 23:33:58.304 [DEBUG] Scanning server keystore at /home/weasel/mixminion/keys
Oct 19 23:33:58.311 [FATAL] Exception while configuring server
Oct 19 23:33:58.345 [FATAL] Traceback (most recent call last):
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerMain.py",
line 1093, in runServer
server = MixminionServer(config)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerMain.py",
line 647, in __init__
self.keyring = mixminion.server.ServerKeys.ServerKeyring(config)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 78, in __init__
self.configure(config)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 89, in configure
self.checkKeys()
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 130, in checkKeys
t1, t2 = keyset.getLiveness()
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 629, in getLiveness
info = self.getServerDescriptor()
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 621, in getServerDescriptor
self.serverinfo = ServerInfo(fname=self.descFile)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/ServerInfo.py",
line 137, in __init__
mixminion.Config._ConfigFile.__init__(self, fname, string, assumeValid)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/Config.py", line
651, in __init__
contents = mixminion.Common.readPossiblyGzippedFile(filename)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/Common.py", line
1392, in readPossiblyGzippedFile
f = open(fname, 'r')
IOError: [Errno 2] No such file or directory:
'/home/weasel/mixminion/keys/key_0001/ServerDesc'
Oct 19 23:33:58.352 [FATAL] Shutting down because of exception: exceptions.IOError
------- Additional Comments From Nick Mathewson 2003-10-20 20:49 -------
Hm. This is probably because generating keys last time failed in between making
a key directory and writing the server descriptor. I think I have a fix in CVS now.
[Automatically added by flyspray2trac: Operating System: Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/12AttributeError: 'module' object has no attribute 'getIPs'2020-06-16T00:58:34Zweasel (Peter Palfrader)AttributeError: 'module' object has no attribute 'getIPs'[Moved from bugzilla]
Reporter: peter@palfrader.org (Peter Palfrader)
Description:
Opened: 2003-10-19 23:33
Fresh cvs installation as of Sun, 19 Oct 2003 23:31:30 +0200
copying etc/mixminiond.conf file from minion/cvs, changed nick...[Moved from bugzilla]
Reporter: peter@palfrader.org (Peter Palfrader)
Description:
Opened: 2003-10-19 23:33
Fresh cvs installation as of Sun, 19 Oct 2003 23:31:30 +0200
copying etc/mixminiond.conf file from minion/cvs, changed nickname,
identitykeybits, homedir, and loglevel:
weasel@valiant:~/mixminion/bin$ ./mixminion server-upgrade -f
../etc/mixminiond.conf
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Reading configuration from ../etc/mixminiond.conf
Oct 19 23:28:36.986 [WARN] Mode specification is not yet supported.
Oct 19 23:28:36.988 [WARN] Dangerously low MixInterval
No server keys to upgrade.
Dropping obsolete messages from queues (no upgrade; sorry!)
Homedir is upgraded
weasel@valiant:~/mixminion/bin$ ./mixminion server-start -f ../etc/mixminiond.conf
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Reading configuration from ../etc/mixminiond.conf
Oct 19 23:28:40.720 [WARN] Mode specification is not yet supported.
Oct 19 23:28:40.721 [WARN] Dangerously low MixInterval
Oct 19 23:28:40.726 [DEBUG] Configuring server
Oct 19 23:28:40.733 [INFO] Enabling statistics logging
Oct 19 23:28:40.743 [DEBUG] Syncing statistics to disk
Oct 19 23:28:40.753 [INFO] Statistics logging enabled
Oct 19 23:28:40.755 [INFO] Setting entropy source to '/dev/urandom'
Oct 19 23:28:40.758 [DEBUG] Initializing server
Oct 19 23:28:40.765 [DEBUG] Scanning server keystore at /home/weasel/mixminion/keys
Oct 19 23:28:40.772 [INFO] Creating server keystore at /home/weasel/mixminion/keys
Oct 19 23:28:40.778 [DEBUG] Found 0 keys.
Oct 19 23:28:40.779 [INFO] Creating 1 keys
Oct 19 23:28:40.781 [INFO] Generating key 0001 to run from 2003/10/19 through
2003/11/08 (GMT)
Oct 19 23:28:40.782 [INFO] Generating identity key. (This may take a while.)
Oct 19 23:30:21.266 [INFO] Generated 4096-bit identity key.
Oct 19 23:30:27.700 [WARN] No IP configured; guessing 172.22.118.2
Oct 19 23:30:27.704 [WARN] No Hostname configured; guessing valiant
Oct 19 23:30:27.705 [FATAL] Exception while configuring server
Oct 19 23:30:27.719 [FATAL] Traceback (most recent call last):
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerMain.py",
line 1093, in runServer
server = MixminionServer(config)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerMain.py",
line 664, in __init__
self.keyring.createKeysAsNeeded()
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 271, in createKeysAsNeeded
self.createKeys(num=nKeys)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 314, in createKeys
validAt=startAt)
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 968, in generateServerDescriptor
AndKeys
_checkHostnameIsLocal(fields['Hostname'])
File
"/home/weasel/mixminion/lib/python2.3/site-packages/mixminion/server/ServerKeys.py",
line 1148, in _checkHostnameIsLocal
r = mixminion.server.DNSFarm.getIPs(name)
AttributeError: 'module' object has no attribute 'getIPs'
Oct 19 23:30:27.722 [FATAL] Shutting down because of exception:
exceptions.AttributeError
------- Additional Comments From Nick Mathewson 2003-10-20 20:16 -------
Oops; I moved a function from DNSFarm.py to NetUtils.py, and missed one of its
users.
Should be fixed now.
[Automatically added by flyspray2trac: Operating System: Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/11flush command deletes all messages in client queue and doesn't deliver them.2020-06-16T01:08:35Zweasel (Peter Palfrader)flush command deletes all messages in client queue and doesn't deliver them.[Moved from bugzilla]
Reporter: qumqats@ouDescription:
Opened: 2003-10-19 04:44
the latext CVS trunk code appears to not be able to send messages to
the 0.0.5.1 nodes. and even worst it deletes the messages out of the
client queue...[Moved from bugzilla]
Reporter: qumqats@ouDescription:
Opened: 2003-10-19 04:44
the latext CVS trunk code appears to not be able to send messages to
the 0.0.5.1 nodes. and even worst it deletes the messages out of the
client queue when it can't deliver them. these are messages that were
put into the client queue using 0.0.5.1 if I try sending a message
in 0.0.6 I still get an error and the message isn't in the queue.
$ ../bin/mixminion flush
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Oct 18 19:32:25.690 [INFO] Flushing message queue
Oct 18 19:32:25.728 [INFO] Found 913 pending messages
Oct 18 19:32:25.728 [INFO] Flushing 913
Oct 18 19:32:26.997 [INFO] Sending 29 messages to 213.130.163.34:48099...
Oct 18 19:32:27.030 [INFO] Connecting...
Oct 18 19:32:27.393 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:27.394 [INFO] Error was: TLSClosed error while connecting to 213.
130.163.34:48099:
Oct 18 19:32:29.764 [INFO] Sending 9 messages to 62.109.74.123:48099...
Oct 18 19:32:29.766 [INFO] Connecting...
Oct 18 19:32:30.190 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:30.191 [INFO] Error was: TLSClosed error while connecting to 62.
109.74.123:48099:
Oct 18 19:32:30.753 [INFO] Sending 26 messages to 69.55.238.167:48099...
Oct 18 19:32:30.754 [INFO] Connecting...
Oct 18 19:32:30.836 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:30.837 [INFO] Error was: TLSClosed error while connecting to 69.55.
238.167:48099:
Oct 18 19:32:33.585 [INFO] Sending 27 messages to 62.245.184.24:48099...
Oct 18 19:32:33.586 [INFO] Connecting...
Oct 18 19:32:34.050 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:34.051 [INFO] Error was: TLSClosed error while connecting to 62.
245.184.24:48099:
Oct 18 19:32:35.761 [INFO] Sending 27 messages to 18.244.0.188:48099...
Oct 18 19:32:35.762 [INFO] Connecting...
Oct 18 19:32:35.963 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:35.963 [INFO] Error was: TLSClosed error while connecting to 18.
244.0.188:48099:
Oct 18 19:32:37.660 [INFO] Sending 119 messages to 66.92.65.81:48099...
Oct 18 19:32:37.662 [INFO] Connecting...
Oct 18 19:32:37.774 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:37.775 [INFO] Error was: Error connecting: (61, 'Connection
refused')
Oct 18 19:32:44.879 [INFO] Sending 120 messages to 208.210.149.14:48100...
Oct 18 19:32:44.881 [INFO] Connecting...
Oct 18 19:32:44.962 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:44.963 [INFO] Error was: Error connecting: (61, 'Connection
refused')
Oct 18 19:32:52.608 [INFO] Sending 27 messages to 64.142.31.83:48099...
Oct 18 19:32:52.609 [INFO] Connecting...
Oct 18 19:32:52.742 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:52.743 [INFO] Error was: TLSClosed error while connecting to 64.
142.31.83:48099:
Oct 18 19:32:54.451 [INFO] Sending 27 messages to 193.111.87.14:48099...
Oct 18 19:32:54.452 [INFO] Connecting...
Oct 18 19:32:54.539 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:54.540 [INFO] Error was: TLSClosed error while connecting to 193.
111.87.14:48099:
Oct 18 19:32:56.250 [INFO] Sending 28 messages to 24.62.130.57:48100...
Oct 18 19:32:56.252 [INFO] Connecting...
Oct 18 19:32:57.705 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:57.706 [INFO] Error was: TLSClosed error while connecting to 24.62.
130.57:48100:
Oct 18 19:32:59.415 [INFO] Sending 27 messages to 69.9.134.82:48099...
Oct 18 19:32:59.416 [INFO] Connecting...
Oct 18 19:32:59.534 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:32:59.535 [INFO] Error was: TLSClosed error while connecting to 69.9.
134.82:48099:
Oct 18 19:33:01.003 [INFO] Sending 25 messages to 140.247.60.128:48099...
Oct 18 19:33:01.005 [INFO] Connecting...
Oct 18 19:33:01.196 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:01.197 [INFO] Error was: TLSClosed error while connecting to 140.
247.60.128:48099:
Oct 18 19:33:02.836 [INFO] Sending 27 messages to 80.177.168.205:48099...
Oct 18 19:33:02.837 [INFO] Connecting...
Oct 18 19:33:03.240 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:03.241 [INFO] Error was: TLSClosed error while connecting to 80.
177.168.205:48099:
Oct 18 19:33:04.979 [INFO] Sending 30 messages to 18.244.0.188:48100...
Oct 18 19:33:04.981 [INFO] Connecting...
Oct 18 19:33:05.170 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:05.171 [INFO] Error was: TLSClosed error while connecting to 18.
244.0.188:48100:
Oct 18 19:33:07.045 [INFO] Sending 120 messages to 213.73.91.34:48099...
Oct 18 19:33:07.046 [INFO] Connecting...
Oct 18 19:33:27.052 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:27.052 [INFO] Error was:
Oct 18 19:33:34.952 [INFO] Sending 26 messages to 207.36.86.132:48099...
Oct 18 19:33:34.953 [INFO] Connecting...
Oct 18 19:33:35.175 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:35.176 [INFO] Error was: TLSClosed error while connecting to 207.
36.86.132:48099:
Oct 18 19:33:36.818 [INFO] Sending 27 messages to 80.0.174.191:48099...
Oct 18 19:33:36.819 [INFO] Connecting...
Oct 18 19:33:37.205 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:37.205 [INFO] Error was: TLSClosed error while connecting to 80.0.
174.191:48099:
Oct 18 19:33:38.728 [INFO] Sending 27 messages to 66.79.46.86:48099...
Oct 18 19:33:38.729 [INFO] Connecting...
Oct 18 19:33:38.995 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:38.995 [INFO] Error was: TLSClosed error while connecting to 66.79.
46.86:48099:
Oct 18 19:33:40.682 [INFO] Sending 27 messages to 65.31.179.120:48099...
Oct 18 19:33:40.683 [INFO] Connecting...
Oct 18 19:33:40.898 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:40.899 [INFO] Error was: TLSClosed error while connecting to 65.31.
179.120:48099:
Oct 18 19:33:42.559 [INFO] Sending 26 messages to 216.218.240.134:48099...
Oct 18 19:33:42.560 [INFO] Connecting...
Oct 18 19:33:42.624 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:33:42.625 [INFO] Error was: TLSClosed error while connecting to 216.
218.240.134:48099:
Oct 18 19:33:44.180 [INFO] Sending 29 messages to 213.146.114.96:48099...
Oct 18 19:33:44.182 [INFO] Connecting...
Oct 18 19:34:43.817 [INFO] ... messages sent
Oct 18 19:34:45.681 [INFO] Sending 29 messages to 24.62.130.57:48099...
Oct 18 19:34:45.681 [INFO] Connecting...
Oct 18 19:34:47.342 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:34:47.343 [INFO] Error was: TLSClosed error while connecting to 24.62.
130.57:48099:
Oct 18 19:34:49.101 [INFO] Sending 27 messages to 66.93.100.200:48099...
Oct 18 19:34:49.102 [INFO] Connecting...
Oct 18 19:34:49.343 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:34:49.344 [INFO] Error was: TLSClosed error while connecting to 66.93.
100.200:48099:
Oct 18 19:34:50.967 [INFO] Sending 27 messages to 208.42.19.154:39287...
Oct 18 19:34:50.968 [INFO] Connecting...
Oct 18 19:34:51.195 [INFO] Error while delivering messages; leaving in queue
Oct 18 19:34:51.196 [INFO] Error was: TLSClosed error while connecting to 208.
42.19.154:39287:
Oct 18 19:34:52.743 [INFO] Queue flushed
$ ../bin/mixminion flush
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Oct 18 19:35:32.820 [INFO] Flushing message queue
Oct 18 19:35:32.826 [INFO] Found 0 pending messages
Oct 18 19:35:32.827 [INFO] Flushing 0
Oct 18 19:35:32.828 [INFO] Queue flushed
$
$ bin/mixminion send -t qumqats@outel.org
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Oct 18 19:39:08.500 [WARN] This software is newer than any version on the
recommended list.
Enter your message now. Type Ctrl-D when you are done.
sdf
sdf
sda
asd
.
Oct 18 19:39:17.144 [INFO] Generating payload(s)...
Oct 18 19:39:17.169 [INFO] Selected path is moria1,chicago,cside,Tonga:typhaon,
moria1,mercurio,aarg
Oct 18 19:39:17.636 [INFO] Message queued
Oct 18 19:39:17.637 [INFO] Connecting...
Oct 18 19:39:17.828 [INFO] Error while delivering message; leaving in queue
Oct 18 19:39:17.829 [INFO] Error was: TLSClosed error while connecting to 18.
244.0.188:48099:
$
$
$ ls -al .mixminion/queue
total 58
drwx------ 2 minion minion 22528 Oct 18 19:39 .
drwx------ 16 minion minion 512 Oct 18 19:39 ..
-rw------- 1 minion minion 32906 Oct 18 17:22 inp_y-wLWCF0
$
$ bin/mixminion flush
Mixminion version 0.0.6alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Oct 18 19:41:55.952 [INFO] Flushing message queue
Oct 18 19:41:55.958 [INFO] Found 0 pending messages
Oct 18 19:41:55.959 [INFO] Flushing 0
Oct 18 19:41:55.960 [INFO] Queue flushed
$
------- Additional Comments From Nick Mathewson 2003-10-20 20:51 -------
I'm pretty sure that this was because of a TLS bug fixed by the checkin of
2003/10/19 to tls.c. From the CVS log:
The spec says that we should support an alternative (and more common)
crypto suite for client-to-server communications. The alternative
suite is only present in SSL3; the preferred one is in TLS1.
Older versions of the code are configured to generate only TLS1
connections -- and (previously unknown to me) accept only TLS1
connections. To do the right thing, we need to accept TLS1 and SSL3,
but generate only TLS1. This patch does that.
Please verify that this bug is gone for you. :)tel.org (Joel M. Baldwin)
[Automatically added by flyspray2trac: Operating System: FreeBSD]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/10flush command terminates with this traceback2020-06-16T00:58:34Zweasel (Peter Palfrader)flush command terminates with this traceback[Moved from bugzilla]
Reporter: qumqats@outel.org (Joel M. Baldwin)
Description:
Opened: 2003-10-19 04:15
flush command terminates with this traceback. portion of contents of queue
never gets processed.
Oct 18 19:07:23.408 [INFO...[Moved from bugzilla]
Reporter: qumqats@outel.org (Joel M. Baldwin)
Description:
Opened: 2003-10-19 04:15
flush command terminates with this traceback. portion of contents of queue
never gets processed.
Oct 18 19:07:23.408 [INFO] Error while delivering messages; leaving in queue
Traceback (most recent call last):
File "/home/minion/bin/mixminion", line 10, in ?
mixminion.Main.main(sys.argv)
File "/home/minion/lib/python2.3/site-packages/mixminion/Main.py", line 281,
in main
func(commandStr, args[2:])
File "/home/minion/lib/python2.3/site-packages/mixminion/ClientMain.py", line
2828, in flushQueue
client.flushQueue(count)
File "/home/minion/lib/python2.3/site-packages/mixminion/ClientMain.py", line
1672, in flushQueue
self.sendMessages(msgs, routing, noQueue=1, warnIfLost=0)
File "/home/minion/lib/python2.3/site-packages/mixminion/ClientMain.py", line
1620, in sendMessages
timeout)
File "/home/minion/lib/python2.3/site-packages/mixminion/MMTPClient.py", line
247, in sendMessages
con.connect(connectTimeout=connectTimeout)
File "/home/minion/lib/python2.3/site-packages/mixminion/MMTPClient.py", line
69, in connect
self._connect(connectTimeout)
File "/home/minion/lib/python2.3/site-packages/mixminion/MMTPClient.py", line
123, in _connect
self.tls.connect()
mixminion._minionlib.TLSWantWrite
[Automatically added by flyspray2trac: Operating System: FreeBSD]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/9Client MMTP timeouts don't really work2020-06-16T00:58:34Zweasel (Peter Palfrader)Client MMTP timeouts don't really work[Moved from bugzilla]
Reporter: nickm@alum.mit.edu (Nick Mathewson)
Description:
Opened: 2003-10-17 13:28
Right now, client MMTP connections only timeout while the connect(2) call is in
progress. But there is no good way (other th...[Moved from bugzilla]
Reporter: nickm@alum.mit.edu (Nick Mathewson)
Description:
Opened: 2003-10-17 13:28
Right now, client MMTP connections only timeout while the connect(2) call is in
progress. But there is no good way (other than alarm(2)) to have blocking TLS
connections timeout.
The symptom is: connect to server that accepts a TCP connection, but that never
completes any TLS operations. The client will block forever.
For now, I'm implementing alarm() for a quick fix. But that will penalize slow
servers, and isn't a good long-term solution.
The real answer is probably to rewrite the client and server connection to both
use a common set of nonblocking IO calls.
------- Additional Comments From Nick Mathewson 2004-01-27 01:57 -------
This has been fixed by the MMTP rewrite in 0.0.7.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/8List of servers has names right justified2020-06-16T00:58:34Zweasel (Peter Palfrader)List of servers has names right justified[Moved from bugzilla]
Reporter: colin@tuckley.org (Colin Tuckley)
Description:
Opened: 2003-09-28 13:16
When you run the "mixminion list-servers" command the resulting list of server
information has the names of the servers right j...[Moved from bugzilla]
Reporter: colin@tuckley.org (Colin Tuckley)
Description:
Opened: 2003-09-28 13:16
When you run the "mixminion list-servers" command the resulting list of server
information has the names of the servers right justified (with the trailing
colons aligned).
This makes it very difficult to spot a server with a short name.
------- Additional Comments From Nick Mathewson 2003-10-06 16:06 -------
Will fix in 0.0.6.
------- Additional Comments From Nick Mathewson 2003-11-07 10:23 -------
0.0.6 CVS has a brand-spanking new list-servers implementation that no longer
has this problem. It doubtlessly has others. It needs documentation, and it
isn't 100% backward compatible, but it's at least an order of magnitude more
flexible.
It may still suck, but not in the same way as before. :)lin@tuckley.org (Colin Tuckley)
[Automatically added by flyspray2trac: Operating System: Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/7client 'flush' takes too much memory2020-06-16T00:58:34Zweasel (Peter Palfrader)client 'flush' takes too much memory[Moved from bugzilla]
Reporter: qumqats@outel.org (Joel M. Baldwin)
Description:
Opened: 2003-09-19 13:43
I there any way you can reduce the memory used by by the client 'flush' command?
When I have thousands of messages in my c...[Moved from bugzilla]
Reporter: qumqats@outel.org (Joel M. Baldwin)
Description:
Opened: 2003-09-19 13:43
I there any way you can reduce the memory used by by the client 'flush' command?
When I have thousands of messages in my client queue the 'flush' command creates
such a large memory footprint that the process causes my system to starts
swapping.
------- Additional Comments From Nick Mathewson 2003-11-07 08:18 -------
This should be fixed in 0.0.6 CVS; we now lazy-load queued messages as we flush
them. [We still use space proportional to the number of pending messages to
compute which messages are going where, but this should now be a few dozen bytes
per message, not 32KB per message.]
[Automatically added by flyspray2trac: Operating System: FreeBSD]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/6Confused server clocks can screw up timing2022-03-22T13:04:03Zweasel (Peter Palfrader)Confused server clocks can screw up timing[Moved from bugzilla]
Reporter: nickm@alum.mit.edu (Nick Mathewson)
Description:
Opened: 2003-08-29 20:44
Some users have reported that the mixminion server has a nasty failure mode when
a server's clock moves backwards by a large i...[Moved from bugzilla]
Reporter: nickm@alum.mit.edu (Nick Mathewson)
Description:
Opened: 2003-08-29 20:44
Some users have reported that the mixminion server has a nasty failure mode when
a server's clock moves backwards by a large interval. When the server asks
"when did we last (do something)", the answer "tomorrow" can cause crashes or
weird behavior.
I'm deferring this for a while, because (a) I want to get 0.0.5 put to bed, and
(b) the workaround is trivial: keep your clock set right.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/5Can't start new server-- get fatal exception while configuring server2020-06-16T00:58:34Zweasel (Peter Palfrader)Can't start new server-- get fatal exception while configuring server[Moved from bugzilla]
Reporter: geckox@keller-heikkila.org
Description:
Opened: 2003-07-31 02:22
Linux system, Python 2.3, Openssl 0.9.7
Here's the traceback:
root@xxx:/home/minion/etc# /etc/rc.d/mixminion.init start
root@xxx:/hom...[Moved from bugzilla]
Reporter: geckox@keller-heikkila.org
Description:
Opened: 2003-07-31 02:22
Linux system, Python 2.3, Openssl 0.9.7
Here's the traceback:
root@xxx:/home/minion/etc# /etc/rc.d/mixminion.init start
root@xxx:/home/minion/etc# This software is for testing purposes only.
Anonymity is not guaranteed.
Reading configuration from /home/minion/etc/mixminiond.conf
Jul 30 19:17:13.979 [FATAL] Exception while configuring server
Jul 30 19:17:13.989 [FATAL] Traceback (most recent call last):
File
"/usr/local/lib/python2.3/site-packages/mixminion/server/ServerMain.py", line
1031, in runServer
mixminion.Common.LOG.configure(config, keepStderr=1)
File "/usr/local/lib/python2.3/site-packages/mixminion/Common.py", line 722,
in configure
self.addHandler(_FileLogHandler(logfile))
File "/usr/local/lib/python2.3/site-packages/mixminion/Common.py", line 629,
in __init__
self.reset()
File "/usr/local/lib/python2.3/site-packages/mixminion/Common.py", line 638,
in reset
createPrivateDir(parent)
File "/usr/local/lib/python2.3/site-packages/mixminion/Common.py", line 305,
in createPrivateDir
raise MixFatalError("Unable to create directory %s: %s" % d, e)
TypeError: not enough arguments for format string
Jul 30 19:17:13.990 [FATAL] Shutting down because of exception: exceptions.TypeError
root@xxx:/home/minion/etc#
------- Additional Comments From Nick Mathewson 2003-07-31 03:44 -------
This is fixed in CVS---or at least, the error message is better. It's a symptom
of an underlying problem -- for some reason, you don't have permissions or
ability to create the directory the log files are supposed to be in.
[Automatically added by flyspray2trac: Operating System: Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/4Incorrect node routing with mbox2020-06-16T00:58:34Zweasel (Peter Palfrader)Incorrect node routing with mbox[Moved from bugzilla]
Reporter: colin@tuckley.org (Colin Tuckley)
Description:
Opened: 2003-06-23 20:44
sending a message using:
mixminion send -t mbox:fred@cside -P sushi,cside
results in the Selected path being sushi:cside,cside...[Moved from bugzilla]
Reporter: colin@tuckley.org (Colin Tuckley)
Description:
Opened: 2003-06-23 20:44
sending a message using:
mixminion send -t mbox:fred@cside -P sushi,cside
results in the Selected path being sushi:cside,cside
which is not sensible.
------- Additional Comments From Nick Mathewson 2003-08-29 20:46 -------
I'm deferring a fix for this bug until 0.0.6. It's not a showstopper, and I
need to rework the path selection logic pretty heavily in 0.0.6 anyway.
------- Additional Comments From Nick Mathewson 2003-11-07 10:27 -------
Fixed in 0.0.6 CVS. If you specify the same last hop in your path and in an
exit address, it now counts only once.
[Automatically added by flyspray2trac: Operating System: Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/3changing PublicKeyLifetime to smaller values isn't good2020-06-16T01:00:35Zweasel (Peter Palfrader)changing PublicKeyLifetime to smaller values isn't good[Moved from bugzilla]
Description:
Opened: 2003-05-30 16:12
I had the default PublicKeyLifetime of 3 months and already had generated keys.
Now I wanted to set it to a lower value (1 month or 1 week) but when I start
the server I g...[Moved from bugzilla]
Description:
Opened: 2003-05-30 16:12
I had the default PublicKeyLifetime of 3 months and already had generated keys.
Now I wanted to set it to a lower value (1 month or 1 week) but when I start
the server I get the following:
Reading configuration from /home/minion/etc/mixminiond.conf
May 30 16:11:33.651 [DEBUG] Configuring server
May 30 16:11:33.651 [INFO] Starting server in the background
May 30 16:11:33.657 [INFO] Enabling statistics logging
May 30 16:11:33.659 [WARN] Directory /home is writable by group staff (mode 775)
May 30 16:11:33.661 [DEBUG] Syncing statistics to disk
May 30 16:11:33.662 [INFO] Statistics logging enabled
May 30 16:11:33.663 [INFO] Setting entropy source to '/dev/urandom'
May 30 16:11:33.665 [DEBUG] Initializing server
May 30 16:11:33.666 [DEBUG] Scanning server keystore at /home/minion/miniond/keys
May 30 16:11:33.671 [TRACE] Found key key_0001 (valid from 2003/05/30 to 2003/08/28)
May 30 16:11:33.671 [DEBUG] Found 1 keys.
May 30 16:11:33.672 [INFO] Last expiry at 2003/08/28 02:00:00; next keygen at
2003/08/11 13:00:00
May 30 16:11:33.673 [ERROR] Some generated keysets do not match current
configuration...
May 30 16:11:33.673 [ERROR] Keyset 0001 (2003/05/30 02:00:00--2003/08/28 02:00:00):
May 30 16:11:33.674 [WARN] Published lifetime does not match PublicKeyLifetime
May 30 16:11:33.675 [WARN] (This problem will go away in a while).
May 30 16:11:33.678 [INFO] Regenerating descriptor for keyset 0001 (2003/05/30
02:00:00--2003/08/28 02:00:00)
May 30 16:11:33.733 [DEBUG] Disabling module MBOX
May 30 16:11:33.734 [INFO] Module DROP: enabled for types ['0x0']
May 30 16:11:33.734 [DEBUG] Disabling module SMTP
May 30 16:11:33.735 [DEBUG] Disabling module SMTP_MIX2
May 30 16:11:33.765 [FATAL] Exception while configuring server
May 30 16:11:33.771 [FATAL] Traceback (most recent call last):
File
"/home/minion/lib/python2.2/site-packages/mixminion/server/ServerMain.py", line
1045, in runServer
server = MixminionServer(config)
File
"/home/minion/lib/python2.2/site-packages/mixminion/server/ServerMain.py", line
648, in __init__
self.keyring.checkDescriptorConsistency()
File
"/home/minion/lib/python2.2/site-packages/mixminion/server/ServerKeys.py", line
172, in checkDescriptorConsistency
ks.regenerateServerDescriptor(self.config, identity)
File
"/home/minion/lib/python2.2/site-packages/mixminion/server/ServerKeys.py", line
621, in regenerateServerDescriptor
useServerKeys=1)
File
"/home/minion/lib/python2.2/site-packages/mixminion/server/ServerKeys.py", line
960, in generateServerDescriptorAndKeys
assert ok
AssertionError
May 30 16:11:33.771 [FATAL] Shutting down because of exception:
exceptions.AssertionError
------- Additional Comments From Nick Mathewson 2003-05-30 21:13 -------
The crash is a shallow logic error: the code double-checks that any new
descriptors it generates must produce no consistency errors. I'm going to make
an exception for public key lifetime, because (as the warning notes) we don't
automaticly propagate those changes.
Why not? Because pmce a descriptor is published, we want the set of keys to
remain valid for as long as promised, so that reply blocks will continue to
work. When you set a new publicKeyLifetime, it applies to _new_ keys, not to
existing ones.
If you really want to go to a shorter lifetime, stop your server, edit
PublicKeyLifetime, run 'mixminion server-DELKEYS', and restart the server.
------- Additional Comments From Peter Palfrader 2003-05-30 21:18 -------
That a change of PublicKeyLifetime only affects new keys is probably The Right
Thing. So for current keys the lifetime should stay the same and mixminion
should start as usual.
------- Additional Comments From Nick Mathewson 2003-05-30 21:23 -------
Okay, the fix in CVS should solve it.
[Automatically added by flyspray2trac: Operating System: Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/2Key rotation crashes server (sample)2022-03-22T13:21:19Zweasel (Peter Palfrader)Key rotation crashes server (sample)[Moved from bugzilla]
Description:
Opened: 2003-05-29 08:26
(This is a sample bug so I can get used to using the tracker, and see whether
bugs get assigned to me properly.)
When key rotation happens (at midnight GMT), the server go...[Moved from bugzilla]
Description:
Opened: 2003-05-29 08:26
(This is a sample bug so I can get used to using the tracker, and see whether
bugs get assigned to me properly.)
When key rotation happens (at midnight GMT), the server goes into an infinite
loop, exhausts its fds, then dies.
------- Additional Comments From Nick Mathewson 2003-05-29 08:29 -------
The bug seemed to be that we'd reschedule the next key generation before the
current one was complete. Obviously, before the keygen is done, the server will
think that a new keygen needs to happen immediately. (ick!) I think I squashed
this, but it's hard to be sure. I'll know at midnight GMT tomorrow.
------- Additional Comments From Nick Mathewson 2003-05-30 21:09 -------
None of my servers died at midnight; I think we're ok.
[Automatically added by flyspray2trac: Operating System: Linux]Nick MathewsonNick Mathewson