Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:57:14Zhttps://gitlab.torproject.org/legacy/trac/-/issues/82tor opens too many file descriptors2020-06-13T13:57:14Zgoodelltor opens too many file descriptorsFor those of us with systems with high-bandwidth connections, running a
Tor router causes the Tor process to open many file descriptors. So
many, in fact, that Tor routinely runs into the ceiling specified by
ulimit -n. Thus, either (a...For those of us with systems with high-bandwidth connections, running a
Tor router causes the Tor process to open many file descriptors. So
many, in fact, that Tor routinely runs into the ceiling specified by
ulimit -n. Thus, either (a) the init script included with the tor
package should manually set a large value for ulimit -n, or (b) Tor
itself should somehow set its own ulimit to be large, perhaps based upon
a configuration parameter.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/83show which dirserver said we have a skewed clock/are unverified2020-06-13T14:20:11Zweasel (Peter Palfrader)show which dirserver said we have a skewed clock/are unverifiedIn
Jan 30 00:39:44.266 [warn] connection_dir_client_reached_eof(): http
status 403 (unapproved server) response from dirserver. Is your clock
skewed? Have you mailed us your identity fingerprint? Are you using the
right key? Are you usi...In
Jan 30 00:39:44.266 [warn] connection_dir_client_reached_eof(): http
status 403 (unapproved server) response from dirserver. Is your clock
skewed? Have you mailed us your identity fingerprint? Are you using the
right key? Are you using a private IP address? See
http://tor.eff.org/doc/tor-doc.html#server.
it would be nice if tor said which dirserver said we are unverified/have a skewed clock.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/84we should handle the case where the client has no cert2020-06-13T13:57:14ZRoger Dingledinewe should handle the case where the client has no certCurrent cvs refuses connections from clients that don't have a cert chain. We ought to handle
clients that don't have one, just to be more generally compatible, and to deal with JAP
clients that apparently don't provide them.
[Automatic...Current cvs refuses connections from clients that don't have a cert chain. We ought to handle
clients that don't have one, just to be more generally compatible, and to deal with JAP
clients that apparently don't provide them.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/85Doc/Installer mismatch on MacOS X2020-06-13T13:57:14ZTracDoc/Installer mismatch on MacOS XThe website documents that you need to click "install TOR startup script," but its pre-selected in latest builds.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667The website documents that you need to click "install TOR startup script," but its pre-selected in latest builds.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667https://gitlab.torproject.org/legacy/trac/-/issues/86No logs in default mac package2020-06-13T13:57:14ZTracNo logs in default mac packageI installed the new mac package, and it doesn't log at all.
I suppose there may be a security argument for this, but it makes it hard to figure out what's going wrong.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 ...I installed the new mac package, and it doesn't log at all.
I suppose there may be a security argument for this, but it makes it hard to figure out what's going wrong.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/87Our clock skew allowances differ, leading to problems2020-06-13T13:57:14ZRoger DingledineOur clock skew allowances differ, leading to problemsdirserv_set_cached_directory(): Ignoring future directory; not caching.
This happens, causing dir mirrors to not have anything to give out, if they're more than
ROUTER_ALLOW_SKEW (30 minutes) in the past.
Yet they need to be ROUTER_MAX...dirserv_set_cached_directory(): Ignoring future directory; not caching.
This happens, causing dir mirrors to not have anything to give out, if they're more than
ROUTER_ALLOW_SKEW (30 minutes) in the past.
Yet they need to be ROUTER_MAX_AGE (24 hours) in the past before we flag any warnings
about their time skew.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/88please free all memory before shutting down2020-06-13T13:57:14Zweasel (Peter Palfrader)please free all memory before shutting downI've been playing with dmalloc, a library that checks for leaks (and other stuff).
It's a lot lighter than for instance valgrind, but unfortunately Tor does not
play very nice with it.
It would be great if you could clean up all the mem...I've been playing with dmalloc, a library that checks for leaks (and other stuff).
It's a lot lighter than for instance valgrind, but unfortunately Tor does not
play very nice with it.
It would be great if you could clean up all the memory you think you are using
before shutdown, so that tools like dmalloc can tell you what you missed.
For instance now dmalloc gives me
1107411810: 73044: total-size count source
1107411810: 73044: 81920 5 buffers.c:37
1107411810: 73044: 65360 1634 routerparse.c:1066
1107411810: 73044: 36864 9 buffers.c:112
1107411810: 73044: 31234 1634 routerparse.c:1068
1107411810: 73044: 17568 122 routerparse.c:804
1107411810: 73044: 6528 24 aes.c:74
1107411810: 73044: 6454 1 dirserv.c:789
1107411810: 73044: 6452 1 torgzip.c:111
1107411810: 73044: 6144 24 container.c:45
1107411810: 73044: 4800 122 routerparse.c:908
1107411810: 73044: 3920 245 crypto.c:177
...
after I shutdown tor. This isn't very useful yet, but it could be :)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/89patch to optionally build tor with dmalloc2020-06-13T13:57:14Zweasel (Peter Palfrader)patch to optionally build tor with dmallocThis patch against current cvs adds a --with-dmalloc configure
option to build tor against the dmalloc library.
[Automatically added by flyspray2trac: Operating System: All]This patch against current cvs adds a --with-dmalloc configure
option to build tor against the dmalloc library.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/90Bandwidth rate schedules2020-06-13T13:57:14ZTracBandwidth rate schedulesI'd like to be able to set a simple schedule in torrc, so's to allow a higher bandwidth cap in the evenings. Something like this:
--------
BandwidthRate 40 kb # default rate cap
BandwidthBurst 400 kb # default bw cap
...I'd like to be able to set a simple schedule in torrc, so's to allow a higher bandwidth cap in the evenings. Something like this:
--------
BandwidthRate 40 kb # default rate cap
BandwidthBurst 400 kb # default bw cap
DaytimeHours 0700 1900 # daytime window (7am - 7pm)
DaytimeBandwidthRate 10 kb # daytime rate cap
DaytimeBandwidthBurst 10 kb # daytime burst size
--------
Yeah, I could do the same thing with a traffic shaper, but I don't need one otherwise.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: andrewmyershttps://gitlab.torproject.org/legacy/trac/-/issues/91please shutdown immediately when we're hibernating2020-06-13T13:57:14Zweasel (Peter Palfrader)please shutdown immediately when we're hibernatingOn SIGINT tor waits for 30 seconds to shutdown. Even when it's hibernating and there
are no current connections through it.
Perhaps make it shutdown in this state immediately?
[Automatically added by flyspray2trac: Operating System: All]On SIGINT tor waits for 30 seconds to shutdown. Even when it's hibernating and there
are no current connections through it.
Perhaps make it shutdown in this state immediately?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/92Choose specific TOR servers2020-06-13T13:57:14ZTracChoose specific TOR serversIt would be nice to implement the possibility to choose/use only specific TOR servers not only for entry and exit but also for the "middleman".
Right now the only possibility is to exclude certain servers via command line option, but th...It would be nice to implement the possibility to choose/use only specific TOR servers not only for entry and exit but also for the "middleman".
Right now the only possibility is to exclude certain servers via command line option, but that doesn't really fit the needs.
so it would be cool to have a command line option e.g. --middlemanservers <nick1,nick2,> and also the option --strictmiddlemanservers
why i want that feature?
- possibilty to improve speed
- choose a specific route
- possibility to use only really reliable servers, e.g. for time critical tasks
thanks for your work
d3000
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: d3000https://gitlab.torproject.org/legacy/trac/-/issues/93hidden services complain persistently about non-availability of nodes2020-06-13T13:57:14Zweasel (Peter Palfrader)hidden services complain persistently about non-availability of nodesTor continues to complain about not finding nodes to introduction points. It complained once ever second since it was started.
Feb 04 16:05:44.711 [warn] router_choose_random_node(): No available nodes when trying to choose node. Faili...Tor continues to complain about not finding nodes to introduction points. It complained once ever second since it was started.
Feb 04 16:05:44.711 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:44.711 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:44.711 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:45.752 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:45.752 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:46.776 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:46.776 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:47.793 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:47.793 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:48.842 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:48.842 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:49.913 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:49.913 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
...
CVS Snapshot 2005-02-04 00:13 UTC
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/94Typo in man page2020-06-13T13:57:14ZSteven MurdochTypo in man pageI have noticed a confusing typo in the manpage of MixMinion 0.0.8alpha1 (this version isn't listed in the combo box).
In mixminion.1. "noqueue" should be "no-queue"
[Automatically added by flyspray2trac: Operating System: All]I have noticed a confusing typo in the manpage of MixMinion 0.0.8alpha1 (this version isn't listed in the combo box).
In mixminion.1. "noqueue" should be "no-queue"
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/95Makefile doesn't use passive FTP2020-06-13T13:57:14ZSteven MurdochMakefile doesn't use passive FTPIn the Makefile download-openssl target, wget (and possibly curl) use active FTP by default and fail if behind a NAT box, or in my case a paranoid firewall. Is there any reason not to use passive FTP? For wget the "--passive-ftp" switch ...In the Makefile download-openssl target, wget (and possibly curl) use active FTP by default and fail if behind a NAT box, or in my case a paranoid firewall. Is there any reason not to use passive FTP? For wget the "--passive-ftp" switch will do this, I don't know about curl. Another option would be to use HTTP, which would get past even more paranoid HTTP-only firewalls, and those who are required to use a HTTP proxy.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/96assert_cpath_layer_ok2020-06-13T13:57:14ZTracassert_cpath_layer_okanother crash. perhaps it only shows when the network is really
jammed and there are many *very* slow jap connections pending.
[log]
Feb 06 16:11:29.003 [notice] connection_ap_expire_beginning(): Stream is 15 seconds late on address
...another crash. perhaps it only shows when the network is really
jammed and there are many *very* slow jap connections pending.
[log]
Feb 06 16:11:29.003 [notice] connection_ap_expire_beginning(): Stream is 15 seconds late on address
'70.58.141.252'. Retrying.
Feb 06 16:11:29.004 [notice] circuit_log_path(): circ (length 3, exit countach): rodos(open) anorien
(open) countach(open)
Feb 06 16:11:31.002 [notice] connection_ap_expire_beginning(): Stream is 15 seconds late on address
'80.177.13.198'. Retrying.
Feb 06 16:11:31.002 [notice] circuit_log_path(): circ (length 3, exit countach): rodos(open) anorien
(open) countach(open)
Feb 06 16:11:31.004 [notice] connection_ap_expire_beginning(): Stream is 15 seconds late on address
'80.177.13.198'. Retrying.
Feb 06 16:11:31.004 [notice] circuit_log_path(): circ (length 3, exit countach): rodos(open) anorien
(open) countach(open)
Feb 06 16:11:36.581 [err] circuitlist.c:419: assert_cpath_layer_ok: Assertion !cp->handshake_state failed; aborting.
(a few days ago it crashed close to that place with the following log:)
Feb 04 15:56:41.397 [err] assert_cpath_layer_ok(): Unexpected state 191
Feb 04 15:56:41.397 [err] circuitlist.c:426: assert_cpath_layer_ok: Assertion 0 failed; aborting.
[backtrace]
#0 0x40148741 in kill () from /lib/libc.so.6
#1 0x401484c5 in raise () from /lib/libc.so.6
#2 0x40149a08 in abort () from /lib/libc.so.6
#3 0x08051efa in assert_cpath_layer_ok (cp=0x86a4150) at circuitlist.c:419
#4 0x0805ca01 in assert_connection_ok (conn=0x8582ac0, now=1107702696) at connection.c:1484
#5 0x0806cd74 in conn_close_if_marked (i=45) at main.c:332
#6 0x0806dc8c in do_main_loop () at main.c:926
#7 0x0806e535 in tor_main (argc=1, argv=0xbffffe34) at main.c:1426
#8 0x0807e4f4 in main (argc=1, argv=0xbffffe34) at tor_main.c:18
[system description]
i am using the 0.0.9.4 debian package, i am running a pretty old x86
pc and have a jap mix running on the same box which connects to
apache/mod_proxy, which in turn connects to tor.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: fisNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/97connection_dns_remove: Assertion failed2020-06-13T13:57:14Zgoodellconnection_dns_remove: Assertion failedon serifos, 0.0.9.4 (i386_linux24)
[log]
Feb 06 17:32:31.448 [warn] connection_edge_end(): Bug: Calling connection_edge_end on an already ended stream?
Feb 06 17:35:21.528 [warn] connection_edge_end(): Bug: Calling connection_edge_end o...on serifos, 0.0.9.4 (i386_linux24)
[log]
Feb 06 17:32:31.448 [warn] connection_edge_end(): Bug: Calling connection_edge_end on an already ended stream?
Feb 06 17:35:21.528 [warn] connection_edge_end(): Bug: Calling connection_edge_end on an already ended stream?
Feb 06 17:38:50.007 [notice] connection_expire_held_open(): Giving up on marked_for_close conn that's been flushing for 15s (fd 110, type Exit, state 3).
Feb 06 17:38:50.008 [notice] conn_close_if_marked(): Conn (addr 217.175.190.49, fd 110, type Exit, state 3) is being closed, but there are still 5486 bytes we can't write. (Marked at connection_edge.c:112)
Feb 06 17:39:27.677 [err] dns.c:319: connection_dns_remove: Assertion conn->state == EXIT_CONN_STATE_RESOLVING failed; aborting.
[backtrace]
#0 0x4014a741 in kill () from /lib/libc.so.6
#1 0x4014a4c5 in raise () from /lib/libc.so.6
#2 0x4014ba08 in abort () from /lib/libc.so.6
#3 0x08068f13 in connection_dns_remove (conn=0x8213bb0) at dns.c:319
#4 0x08051c97 in _circuit_mark_for_close (circ=0x81dc0b0) at circuitlist.c:386
#5 0x080554cc in command_process_destroy_cell (cell=0xbffff428, conn=0x89ab760) at command.c:309
#6 0x08054eb4 in command_process_cell (cell=0xbffff428, conn=0x89ab760) at command.c:137
#7 0x08061712 in connection_or_process_cells_from_inbuf (conn=0x89ab760) at connection_or.c:502
#8 0x080606f0 in connection_or_process_inbuf (conn=0x89ab760) at connection_or.c:62
#9 0x0805bcac in connection_process_inbuf (conn=0x89ab760, package_partial=1) at connection.c:1313
#10 0x0805aec5 in connection_handle_read (conn=0x89ab760) at connection.c:876
#11 0x0806cb04 in conn_read (i=193) at main.c:265
#12 0x0806dc19 in do_main_loop () at main.c:918
#13 0x0806e505 in tor_main (argc=1, argv=0xbffff984) at main.c:1426
#14 0x0807e4c4 in main (argc=1, argv=0xbffff984) at tor_main.c:18
(gdb) up 3
(gdb) print *conn
$1 = {magic = 2084319310, type = 5 '\005', state = 4 '\004', purpose = 2 '\002',
wants_to_read = 0 '\0', wants_to_write = 0 '\0', s = -1, poll_index = -1, marked_for_close = 0,
marked_for_close_file = 0x0, hold_open_until_flushed = 0, inbuf = 0x824ea08, inbuf_reached_eof = 0,
timestamp_lastread = 1107729523, outbuf = 0x82a7a10, outbuf_flushlen = 0,
timestamp_lastwritten = 1107729523, timestamp_created = 1107729523, addr = 2362680835, port = 0,
address = 0x84544f8 "irc.freenode.net", identity_pkey = 0x0,
identity_digest = '\0' <repeats 19 times>, nickname = 0x0, chosen_exit_name = 0x0, tls = 0x0,
next_circ_id = 13487, bandwidth = 0, receiver_bucket = 0, circ_id_type = CIRC_ID_TYPE_LOWER,
rend_query = '\0' <repeats 16 times>, stream_size = 0, stream_id = 17615, next_stream = 0x0,
cpath_layer = 0x0, package_window = 0, deliver_window = 0, done_sending = 0, done_receiving = 0,
has_sent_end = 0 '\0', socks_request = 0x0, event_mask = 0}
[Automatically added by flyspray2trac: Operating System: All]0.0.9.5Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/98WSAENOBUFS: Running out of buffer space on Windows2020-06-13T17:49:31ZTracWSAENOBUFS: Running out of buffer space on Windows```
Feb 06 02:47:39.469 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 06 12:51:31.380 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 06 14:25:25.031 [err]...```
Feb 06 02:47:39.469 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 06 12:51:31.380 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 06 14:25:25.031 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 07 02:15:17.138 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
```
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: spy1Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/99connect.c "let's try to resolve it anyway, why not" bug2020-06-13T13:57:14ZTracconnect.c "let's try to resolve it anyway, why not" bugShun-ichi Goto's connect.c program 1.90 tries to resolve addresses locally even when specifically told to resolve remotely only (as we discussed in IRC).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Usern...Shun-ichi Goto's connect.c program 1.90 tries to resolve addresses locally even when specifically told to resolve remotely only (as we discussed in IRC).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: skquinnhttps://gitlab.torproject.org/legacy/trac/-/issues/100installation problem2020-06-13T13:57:14ZTracinstallation problemHi,
I can´t get tor to install on an intel box running SuSE 9.1.
I am using tor-0.0.9.4.tar.gz. I do tar xzf tor-0.0.9.4.tar.gz,
then cd into the new directory, then do ./configure, which runs fine.
When I try to make, I get lots of ...Hi,
I can´t get tor to install on an intel box running SuSE 9.1.
I am using tor-0.0.9.4.tar.gz. I do tar xzf tor-0.0.9.4.tar.gz,
then cd into the new directory, then do ./configure, which runs fine.
When I try to make, I get lots of errors complaining about torgzip.c,
The output looks like this:
cc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c log.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c fakepoll.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c util.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c compat.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c container.c
rm -f libor.a
ar cru libor.a log.o fakepoll.o util.o compat.o container.o
ranlib libor.a
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c crypto.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c aes.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c tortls.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c torgzip.c
torgzip.c:20:18: zlib.h: Datei oder Verzeichnis nicht gefunden
torgzip.c: In Funktion »is_gzip_supported«:
torgzip.c:35: error: `ZLIB_VERSION' undeclared (first use in this function)
torgzip.c:35: error: (Each undeclared identifier is reported only once
torgzip.c:35: error: for each function it appears in.)
(much more to follow)
zlib is installed:
# rpm -qa|grep zlib
zlib-1.2.1-70.6
I was able to install an old version of tor (tor-0.0.8.1.tar.gz), but when I
run it, it complains like this;
Feb 12 18:52:13.988 [err] You are running Tor version 0.0.8.1, which will not work with this network.
Is there a way to run and install tor for me?
Thanks for any help
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: thunderhttps://gitlab.torproject.org/legacy/trac/-/issues/101default tor installation does not work over wifi2020-06-13T13:57:14ZTracdefault tor installation does not work over wifii'm running mac os 10.3. and have my powerbook connected over an apple airport extreme basestation.
the default tor installation only gives me privoxy 503 errors - this might be a privoxy issue, i will report the issue there as well.
the...i'm running mac os 10.3. and have my powerbook connected over an apple airport extreme basestation.
the default tor installation only gives me privoxy 503 errors - this might be a privoxy issue, i will report the issue there as well.
the same tor installation however, works perfectly when i connect the powerbook over ehternet - it's when using wifi that i only 503's.
thanks
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: rene