On 19.12.2018 18:46, Michael Tremer wrote:
Hi,
On 19 Dec 2018, at 17:45, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi Michael,
On 19.12.2018 17:10, Michael Tremer wrote:
Sorry from me as well for overlooking that.
No problem... ;-)
Merged and the nightly build ran through…
Ok, thanks for the feedback - in between I thought there were still mistakes in it. That d*** "binary blob" came from my installation archive - I forgot to delete it *twice* before pushing! Duh! Now I'm using a dedicated 'upload'-directory for these archives, so this won't happen again…
No worries. Shit happens.
On my production machine this build is running without any errors since then.
Good. I will install this as soon as possible. I still don’t quite believe that nothing in the configuration has to be changed.
'squid - k parse' never showed any errors and the GUI didn't make any problems until now. We'll see.
We still have Daniel’s patch that hasn’t been integrated. Do you have time to look into that again, too? I forget where that got stuck…
I can do that - its running here - work in progress. ;-)
Best, Matthias
-Michael
Best, Matthias
-Michael
On 17 Dec 2018, at 18:52, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 17.12.2018 18:19, Michael Tremer wrote:
Hey,
Hi,
this patch has a binary blob in it. That is why it is so large.
Yep. Sorry for the noise, but it seems I "stood a bit beside me" while sending this.
I guess you want to resend that?!
Exactly. I did that already - please take a look at:
=> https://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=c9164e6a...
And:
=> https://patchwork.ipfire.org/patch/1998/
Best, Matthias
Hi,
On 19.12.2018 18:54, Matthias Fischer wrote:
On 19.12.2018 18:46, Michael Tremer wrote:
Hi,
On 19 Dec 2018, at 17:45, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi Michael,
On 19.12.2018 17:10, Michael Tremer wrote:
Sorry from me as well for overlooking that.
No problem... ;-)
Merged and the nightly build ran through…
Ok, thanks for the feedback - in between I thought there were still mistakes in it. That d*** "binary blob" came from my installation archive - I forgot to delete it *twice* before pushing! Duh! Now I'm using a dedicated 'upload'-directory for these archives, so this won't happen again…
No worries. Shit happens.
On my production machine this build is running without any errors since then.
Good. I will install this as soon as possible. I still don’t quite believe that nothing in the configuration has to be changed.
'squid - k parse' never showed any errors and the GUI didn't make any problems until now. We'll see.
We still have Daniel’s patch that hasn’t been integrated. Do you have time to look into that again, too? I forget where that got stuck…
I can do that - its running here - work in progress. ;-)
I fear I've found ONE problem with Daniel's patch and the 'queue-size'-option, so I'd prefer to alter the 'queue-size'-value from '64' to '128'.
With 'queue-size=64' I got these errors again today:
... 2018/12/20 11:17:49 kid1| comm_udp_sendto FD 8, (family=2) 127.0.0.1:53: (1) Operation not permitted 2018/12/20 11:17:49 kid1| idnsSendQuery FD 8: sendto: (1) Operation not permitted 2018/12/20 11:17:54 kid1| comm_udp_sendto FD 8, (family=2) 127.0.0.1:53: (1) Operation not permitted 2018/12/20 11:17:54 kid1| idnsSendQuery FD 8: sendto: (1) Operation not permitted 2018/12/20 11:18:04 kid1| comm_udp_sendto FD 8, (family=2) 127.0.0.1:53: (1) Operation not permitted 2018/12/20 11:18:04 kid1| idnsSendQuery FD 8: sendto: (1) Operation not permitted ...
They happen even without any DNS rules - perhaps the '64' is too small!?
With '128' I don't see them. Any thoughts?
Best, Matthias
Hey,
On 20 Dec 2018, at 21:05, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
On 19.12.2018 18:54, Matthias Fischer wrote:
On 19.12.2018 18:46, Michael Tremer wrote:
Hi,
On 19 Dec 2018, at 17:45, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi Michael,
On 19.12.2018 17:10, Michael Tremer wrote:
Sorry from me as well for overlooking that.
No problem... ;-)
Merged and the nightly build ran through…
Ok, thanks for the feedback - in between I thought there were still mistakes in it. That d*** "binary blob" came from my installation archive - I forgot to delete it *twice* before pushing! Duh! Now I'm using a dedicated 'upload'-directory for these archives, so this won't happen again…
No worries. Shit happens.
On my production machine this build is running without any errors since then.
Good. I will install this as soon as possible. I still don’t quite believe that nothing in the configuration has to be changed.
'squid - k parse' never showed any errors and the GUI didn't make any problems until now. We'll see.
We still have Daniel’s patch that hasn’t been integrated. Do you have time to look into that again, too? I forget where that got stuck…
I can do that - its running here - work in progress. ;-)
I fear I've found ONE problem with Daniel's patch and the 'queue-size'-option, so I'd prefer to alter the 'queue-size'-value from '64' to '128’.
Hmm, 64 was just a guess. That’s definitely debatable.
With 'queue-size=64' I got these errors again today:
... 2018/12/20 11:17:49 kid1| comm_udp_sendto FD 8, (family=2) 127.0.0.1:53: (1) Operation not permitted 2018/12/20 11:17:49 kid1| idnsSendQuery FD 8: sendto: (1) Operation not permitted 2018/12/20 11:17:54 kid1| comm_udp_sendto FD 8, (family=2) 127.0.0.1:53: (1) Operation not permitted 2018/12/20 11:17:54 kid1| idnsSendQuery FD 8: sendto: (1) Operation not permitted 2018/12/20 11:18:04 kid1| comm_udp_sendto FD 8, (family=2) 127.0.0.1:53: (1) Operation not permitted 2018/12/20 11:18:04 kid1| idnsSendQuery FD 8: sendto: (1) Operation not permitted ...
They happen even without any DNS rules - perhaps the '64' is too small!?
This is just a problem resolving the hostname. Either that is because there is a firewall rule that blocks port 53 (unlikely) or unbound hits a limit of maximum number of requests per host. In that case we probably need to adjust that.
You should be able to trace that with tcpdump:
tcpdump -i lo port 53 -nn
There is probably TCP reset packets (with an R in the square brackets).
With '128' I don't see them. Any thoughts?
If my theory above this true, this does not make much sense. So either I am wrong or this changes some other behaviour too. No matter how long the queue, the number of requests processed at a time should be the same.
Best, -Michael
Best, Matthias
-
Matthias Fischer -
Michael Tremer