> On Mar 13, 2023, at 4:14 PM, local10 wrote:
>
> Mar 13, 2023, 21:42 by recovery...@enotuniq.net:
>
>> Well, it was worth to check it.
>>
>>
>> Next idea is somewhat more complicated.
>>
>> Install tcpdump.
>> Run:
>> tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53
> On Mar 13, 2023, at 12:08 AM, local10 wrote:
>
> I have a local caching DNS server that was working fine for a long time but
> today, all of a sudden, it stopped resolving queries.
>
> More info: https://pastebin.com/iW5YeXgS
>
> Any ideas? Thanks
Based on what I saw in the logs, your
> On Jan 31, 2023, at 8:05 AM, Haines Brown wrote:
>
> I have an application that refuses to start because its port is
> blocked. But I have difficulty knowing what port it is
I would try strace, which shows you all system calls being made. In this case,
it is probably bind() that is
> On Jan 31, 2023, at 8:05 AM, Haines Brown wrote:
>
> I have an application that refuses to start because its port is
> blocked. But I have difficulty knowing what port it is
I would try strace, which shows you all system calls being made. In this case,
it is probably bind() that is
> On Dec 3, 2022, at 12:37 PM, Andre Rodier wrote:
>
> On Sat, 2022-12-03 at 12:09 -0700, Casey Deccio wrote:
>>
>> It could be that your default DNS resolver is not validating. ssh simply
>> looks at the result of the DNSSEC validation
>> provided by your
> On Dec 3, 2022, at 9:22 AM, Andre Rodier wrote:
>
>> ssh -o VerifyHostKeyDNS=yes main.homebox.world
>
> Yes, this is the default option in my ssh/config file.
>
> I tried on the command line as well, but same result:
It could be that your default DNS resolver is not validating. ssh
> On Dec 3, 2022, at 8:30 AM, Andre Rodier wrote:
>
> Where am I making a mistake, please ?
The DNSSEC looks fine. That is, there is a secure chain from the root to the
SSHFP record (see below).
Have you tried adding the VerifyHostKeyDNS=yes option?
ssh -o VerifyHostKeyDNS=yes
> On Aug 30, 2022, at 1:12 PM, Casey Deccio wrote:
>
> I am having trouble tracking down a bug in my monitoring setup. It all
> happened when I upgraded the monitored host (host B in my example below) to
> bullseye. Note that Host A is also running bullseye, but the problem
> On Sep 7, 2022, at 12:41 PM, Jim Popovitch wrote:
>
> On Wed, 2022-09-07 at 12:37 -0600, Casey Deccio wrote:
>>
>>> On Sep 7, 2022, at 11:46 AM, Jim Popovitch >> <mailto:j...@k4vqc.com>> wrote:
>>>
>>> I saw some much of the v
> On Sep 7, 2022, at 11:46 AM, Jim Popovitch wrote:
>
> I saw some much of the verbose '15 > 14' logs that I just decided to
> net.ipv4.tcp_window_scaling=0 and be done with it. Cleared up the
> noise, haven't noticed any problems since. ymmv.
Sounds like you've seen a non-trivial amount of
> On Sep 3, 2022, at 7:30 PM, Kevin Price wrote:
>
> Am 03.09.22 um 06:32 schrieb Casey Deccio:
>>> On Sep 2, 2022, at 8:14 PM, Kevin Price wrote
>
>>> We got him. :) Casey, you file the bug report, Okay?
>
>> Done! https://bugs.debian.org/cgi-
Hi Michael,
> On Sep 7, 2022, at 5:49 AM, Michael Grant wrote:
>
> I'm seeing this error over and over in /var/log/messages:
>
> Sep 6 05:02:42 hostname kernel: [408794.655182] TCP: tcp_parse_options:
> Illegal window scaling value 15 > 14 received
> Sep 6 05:02:43 hostname kernel:
> On Sep 2, 2022, at 8:14 PM, Kevin Price wrote:
>
> Am 03.09.22 um 02:15 schrieb Kevin Price:
>> Let's double check whether our connman is in fact the culprit, and then
>> make arrest. (file bug report)
>
> We got him. :) Casey, you file the bug report, Okay?
Done!
> On Sep 2, 2022, at 1:05 PM, Kevin Price wrote:
>
> I suspect your "very little customization" (since you're doing
> networking stuff) or the "VBox Guest Additions" (since they mess with
> network interfaces). In order to test this, I used
> debian-11.3.0-amd64-netinst.iso from the archive to
> On Sep 2, 2022, at 2:51 AM, Kevin Price wrote:
>
> Am 02.09.22 um 06:33 schrieb Casey Deccio:
>> 1) a sanity check (can others confirm the behavior discrepancy?);
>
> No. My 5.10.0-17 behaves like your 5.10.0-13.
Thanks so much for checking!
> 2) an expectati
> On Sep 1, 2022, at 10:33 PM, Casey Deccio wrote:
>
> I've come across some unexpected changes in interface behavior between
> linux-image-5.10.0-13-amd64 and linux-image-5.10.0-17-amd64.
>
Relatedly, there is this behavior change:
linux-image-5.10.0-13-amd64:
$ sudo ip
I've come across some unexpected changes in interface behavior between
linux-image-5.10.0-13-amd64 and linux-image-5.10.0-17-amd64.
Consider the following script:
$ cat test.sh
#!/bin/sh
sudo ip link add test1 type veth peer test2
sudo ip link set test1 down
sudo ip link set test2 down
sudo
> On Aug 30, 2022, at 1:40 PM, Nicholas Geovanis wrote:
>
> When you run check_dns by hand on Host B, you don't say who you are logged-in
> as. That can make a difference. Nagios runs its scripts in a known
> environment which may be different than you expect.
>
Thanks for the question. I
Hi all,
I am having trouble tracking down a bug in my monitoring setup. It all
happened when I upgraded the monitored host (host B in my example below) to
bullseye. Note that Host A is also running bullseye, but the problem didn't
show itself until Host B was upgraded.
Here is the setup:
I would like to pipe raw straight data through a terminal without any
special characters, null character conversion, carriage
return/newline conversion, or echo. 'stty raw' and 'stty sane' seem
to approach this, but not exactly. Before I start guessing more with
all the individual options in
20 matches
Mail list logo
