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

2023-02-26 Thread fossy
(replying to Laslo)
> which is basically a CGI-interface and thus not within quark's scope.

thttpd has a patch that adds basic CGI support, and I've quickly scanned the
patch, and it seems super simple.. perhaps you could use that in one way or
another.
I don't mean to say "support intellectual property" (I despise it), but
just to
warn you - I'm not sure what the license they use is.

Git? What a bloated mess.. I ahve been working on an Suckless thing alike it,
but my health :(


No, yeah, I absolutely understand.. but I think Quark can be good, if we just
fix this shitty problem lol.. like.. I got lots of hope in it, by which I
mean
you guys ._. sorry.
I just want Suckless software to succeed.. and last time I checked OpenBSD's
httpd code - it was NOT nearly as suckless lul.

Best regards
- anon




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

2023-02-26 Thread fossy
Hey, Laslo.

Yeah, that's fine.. it's like "stable release" for normies.

Ah. I kind-of like Quark.. I don't want to go try thttpd..

It does NOT work XD
In fact - it seems to work much less.. like the opposite from before.
I get like the IP (localhost) dropped - -
usually it's IP (localhost) 200(or 403) somethingsomething.onion /

And this dropping began at literally the 3rd connection within like 5
minutes.. so it cannot be any sort of limit per-say.. except this time,
just on
this 3rd connection(from overall logs that I've seen), the log output was
this:
IP (localhost) 200 - /

I'm not sure if the logging is broken, but I rely on the manually loading the
site and checking if 0 bytes get received - which hasn't happened yet, of
course.


And you are right - you haven't given me any reason for such a threat, it
wasn't for you lol.. or perhaps it was a preventive advice rather than a
threat.. I forgot.. doesn't matter.. what matters is that you're trying to
help
and I'm thankful.. I hope misunderstandings don't happen anymore.




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

2023-02-26 Thread Laslo Hunhold
On Sun, 26 Feb 2023 14:02:48 +0100
Thomas Oltmann  wrote:

Dear Thomas,

> Looks to me like your version of quark is actually a lot newer than
> 2020; Old versions of quark did not print that "dropped" message.
> 
> Probably only tangentially related,
> but I reported a bug in the connection dropping code some time ago,
> which meant that quark would likely drop legitimate connections under
> load (IP address comparison check was the wrong way 'round).
> I don't think the fix ever got merged ...

mea culpa, I postponed the merge planning to refactor some things, but
never got around to merging them. I have now merged them all, maybe
this already fixes the problem.

Sorry for making you wait so long for the merge, as I usually try to
respond fast.

With best regards

Laslo



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

2023-02-26 Thread fossy
If you guys want - perhaps we can play the printf game, or rather - the
logging game?




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

2023-02-26 Thread fossy
Ah, I see.
I forgot how to use git after such a long absence from programming.. +6
months.

I ran the command and it's up to date, last commit is
68b4f733b2755762e43df90f73db5a6ec8d14104 on both of my sites.

I see.
I can test the patch, but I don't think I'm using AF_INET6 as I disabled IPv6
in FreeBSD jail. Meaning the patch probably doesn't do anything for me.

Like I said - I increased -s and -t, but that doesn't seem to change
anything..
which is quite strange, is it not?

What are your thoughts on thttpd (https://www.acme.com/software/thttpd/)?
I see that Suckless isn't hosted by Quark,
either, would love to hear why is that, too.




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

2023-02-26 Thread Thomas Oltmann
On Sun, Feb 26, 2023 at 3:53 PM  wrote:
>
> I did a git clone like it says on the main Quark web-site, and doing `mandoc
> -a quark.1` it shows '2020-09-27', and that's what I am using.
> Unless that's wrong and/or there's another way to get the version number -
> I'd
> like to know.

Ah i see. Running 'git clone' as described on the website does
actually download the latest version.
That date is simply when the last major changes where made to the
manpage, not quark itself.
If you run 'git log' you'll see the date of the most recent (topmost)
change to the source code.

> > which meant that quark would likely drop legitimate connections under load
> (IP address comparison check was the wrong way 'round). I don't think the fix
> ever got merged ...
>
> That's interesting. Like I said - 2020 version, is it fixed in newer commits,
> should I test that out as well?
>
> Because increasing -s and -t seems to do jack shit as I already stated :d

The bug still hasn't been fixed in the latest version.
I've attached a bug fix patch to this mail that you can use, but I'm not 100%
sure that this bug is responsible for your problem.
To apply the patch, simply drop the .diff file in your quark source
folder, then run
git am quark-addr_cmp_fix-20230226.diff
and then rebuild & reinstall with
make
make install
From 0fc2f684e79795dcc4cbd9888a0dd30d78aff36f Mon Sep 17 00:00:00 2001
From: Thomas Oltmann 
Date: Sun, 26 Feb 2023 17:38:43 +0100
Subject: [PATCH] Fix inverted conditional in sock_same_addr()

---
 sock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sock.c b/sock.c
index ecb73ef..e6e7754 100644
--- a/sock.c
+++ b/sock.c
@@ -198,7 +198,7 @@ sock_same_addr(const struct sockaddr_storage *sa1, const struct sockaddr_storage
 	case AF_INET6:
 		return memcmp(((struct sockaddr_in6 *)sa1)->sin6_addr.s6_addr,
 		  ((struct sockaddr_in6 *)sa2)->sin6_addr.s6_addr,
-		  sizeof(((struct sockaddr_in6 *)sa1)->sin6_addr.s6_addr));
+		  sizeof(((struct sockaddr_in6 *)sa1)->sin6_addr.s6_addr)) == 0;
 	case AF_INET:
 		return ntohl(((struct sockaddr_in *)sa1)->sin_addr.s_addr) ==
 		   ntohl(((struct sockaddr_in *)sa2)->sin_addr.s_addr);
-- 
2.39.1



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

2023-02-26 Thread fossy
I did a git clone like it says on the main Quark web-site, and doing `mandoc
-a quark.1` it shows '2020-09-27', and that's what I am using.
Unless that's wrong and/or there's another way to get the version number -
I'd
like to know.

> which meant that quark would likely drop legitimate connections under load
(IP address comparison check was the wrong way 'round). I don't think the fix
ever got merged ...

That's interesting. Like I said - 2020 version, is it fixed in newer commits,
should I test that out as well?

Because increasing -s and -t seems to do jack shit as I already stated :d

Thanks for your time, and please don't be such an asshole like the 2 guys
already did.. nothing is perfect, and I can also make you cry with facts
about
your life you did not even realize, so let's keep it friendly, shall we?




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

2023-02-26 Thread fossy
> Reread Laslo's message and look at the source code as he suggested in
the mentioned message.

I cannot afford that, I have health problems :(.
Regardless - I am getting only ~5 requests per minute, and my biggest file
is <3M, so even given the attack has a super-slow Tor circuit connection
of say 50kbit/s - the connection pool which is by default 64 - shouldn't
be exhausted at the connection rate (~5/min).




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

2023-02-26 Thread Thomas Oltmann
Hi fossy,
Looks to me like your version of quark is actually a lot newer than 2020;
Old versions of quark did not print that "dropped" message.

Probably only tangentially related,
but I reported a bug in the connection dropping code some time ago,
which meant that quark would likely drop legitimate connections under load
(IP address comparison check was the wrong way 'round).
I don't think the fix ever got merged ...

On Sat, Feb 25, 2023 at 8:12 PM Страхиња Радић  wrote:
>
> On 23/02/25 12:59PM, fo...@dnmx.org wrote:
> > Tried -s 128 -t 8, doesn't seem to do jack shit..
> > Got less than 10 connection logs from Quark and then another dropped one..
> > Is there any other reason Quark would print-out 'dropped', other than
> > connection pool at max?
> >
> > I restarted the jail, so Quark's memory and stuff should have been reset.
>
> Reread Laslo's message and look at the source code as he suggested in the
> mentioned message.



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

2023-02-25 Thread Страхиња Радић
On 23/02/25 12:59PM, fo...@dnmx.org wrote:
> Tried -s 128 -t 8, doesn't seem to do jack shit..
> Got less than 10 connection logs from Quark and then another dropped one..
> Is there any other reason Quark would print-out 'dropped', other than
> connection pool at max?
> 
> I restarted the jail, so Quark's memory and stuff should have been reset.

Reread Laslo's message and look at the source code as he suggested in the 
mentioned message.


signature.asc
Description: PGP signature


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

2023-02-25 Thread fossy
Tried -s 128 -t 8, doesn't seem to do jack shit..
Got less than 10 connection logs from Quark and then another dropped one..
Is there any other reason Quark would print-out 'dropped', other than
connection pool at max?

I restarted the jail, so Quark's memory and stuff should have been reset.




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

2023-02-25 Thread fossy
Hey, I just read the quark.1 .
I see the -s and -t options lol. I shall experiment.




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

2023-02-25 Thread fossy
Hi, Laslo.
Sorry, I might not have been best at explaining problem, but then again - I
didn't quite understand problem.. but said all I did understand.

> one of my development goals for quark was to have no memory allocations at
runtime.

Right, I knew that.. but what about memory allocation BEFORE runtime?

Also, worth nothing - I did the stable git clone which gives a 2020 version..
but there seems to be a lot of patches from 2021 and some are anti-DDoS.

It is also worth nothing that I did some resource limitation, but nothing too
extreme. Again - I am not running Facebook or over clear-net, so connections
should be much slower.

And yes - when using curl it shows localhost thing and when Tor - Tor
address.

I use rctl and limit openfiles.. and I guess that also goes for sockets..
should I increase this? Not a small number.
I guess open connections can be much frequent if I have big files and the
transfer speed is slow (like on Tor can be lol).. but shouldn't exceed
the
openfiles limit ..

According to Quark logs - I got like 8k connections in total, over a
period of
like 5 days.. unless there are some hidden connections - I don't see the HOW
the 'OOM KILLER' could be triggered.. and my biggest files are like less than
3M

Do I have an idea? I could have many ideas, but I cannot do jack shit because
of my health with eyes.. even doing this is a hard challange.. and is ruining
my health.


So - yeah.. how many open connections are by default - does it scale up by
some
sort of resource discovery?
How does Quark figure out how big the connection pool is? Does it figure
out at
all? XD.

Quark seems to be some sort of fail2ban, too, huh, since it immediately drops
stuff.. but only when at critical usage? If so - very cool.


Sorry I couldn't help more.. And being an asshole.. I usually have more
patience, but I am losing my sanity and the will to live as my health
declines.. I just want to write C again.. oh God I am crying right now..
*goes
to listen 'Dennis Ritchie - Write in C' while crying*.


It seems some buddy chad of mine found it only allows for 64 connections by
default.. but even then - it shouldn't be exceeded, right?
Perhaps I can like somehow monitor shit in more detail? Can I add some
sort of
printf on connection output?

Thanks for your time.. I fucking love you *cries again*.

- Friendly anon




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

2023-02-25 Thread fossy
You are a brainless joke.




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

2023-02-25 Thread Hiltjo Posthuma
On Sat, Feb 25, 2023 at 09:50:42AM -0500, fo...@dnmx.org wrote:
> Hello.
> 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.
> 
> 

Hi,

Have you tried watching the TOP 10 Quark Life Hacks video to solve the BIG
PROBLEM?

https://www.youtube.com/embed/SqaOZLuQfPg

Hope this helps and you'll get out of jail soon,

-- 
Kind regards,
Hiltjo