Re: [dev] [DEV][Quark] Big problem

From: Laslo Hunhold <dev_AT_frign.de>
Date: Sat, 25 Feb 2023 16:51:05 +0100

On Sat, 25 Feb 2023 09:50:42 -0500
fossy_AT_dnmx.org wrote:

Dear Fossy,

> Before I start, I want to clarify 2 things:
> 1. I'm not 100% sure if it's a Quark problem, but there are like 2/4th
> chance that it is.
> 2. I'm hosting my site over the Tor network
>
> Problem I have: software runs, can access it from localhost via curl,
> but cannot access it from Tor
>
> What happens when I try to access it from Tor? it seems to connect,
> but 0 bytes get transmited
>
> wtf it suddendly started working
>
> usually the fix is NOT restarting Tor, but restarting the jail and
> with it - Quark.. but it works via curl, which is confusing..
>
> Not sure if Quark problem or Tor problem
>
> In Quark log I get a message 'dropped'
>
> I'd like to know if there's something I can do, like what key-words to
> look in Tor's logs
>
> Also to mention: I am getting DDoS-ed for days now xD
>
> I don't see any excessive CPU or memory usage, really - one of reasons
> I use Quark and a static web-site
>
>
> The main reason I think it's Quark's problem: restarting a FreeBSD
> jail with Quark running makes everything work again. This is also why
> I said 2/4 - 1/4 is Tor possible faulty, and the last 1/4 is perhaps
> something to do with FreeBSD jails.
>
> The reason I thikn it's not Quark's problem: I can access it well with
> curl on localhost lol
>
> I also wonder what "- dropped -" means.. and why is there no local
> interface IP address (the 1st '-')?
>
> I helped with the logging to files with Quark bug, now I hope someone
> can help me with this.

one of my development goals for quark was to have no memory allocations
at runtime. This is why it may be the case that you have too many open
connections and exhausted the connection-pool. At this point, quark
kind of goes into an "OOM killer" mode and looks for a candidate to
"drop" (see "connection_get_drop_candidate()" in connection.c) which is
then dropped to serve the new connection.

The heuristic of which connection is dropped is not as straightforward
as choosing the oldest connection, which might be an honest
long-running download or something. Instead, it is checked which
in-address is most frequent, and of those connections, the one with the
smallest progress is dropped. I can imagine that it might be that Tor
opens multiple connections and given Tor looks to have the same
in-address towards quark, it immediately drops the newest connection,
yielding a 0-byte-response.

Maybe you have an idea to improve the heuristic in
connection_get_drop_candidate() to prevent this. :)

With best regards

Laslo
Received on Sat Feb 25 2023 - 16:51:05 CET