I'm able to reproduce.
I can confirm that when this happens, it's the OVH server that fails to
send the response to my network.
35 9.862648672 MY_PUBLIC_IP_AT_HOME → 54.38.38.159 ICMP 78 Echo (ping)
request id=0x4b30, seq=33150/32385, ttl=1
36 9.862704895 54.38.38.159 → MY_PUBLIC_IP_AT_HOME IC
On 9/7/23 13:28, Dan Ritter wrote:
module(load="imuxsock" SysSock.Name="/run/systemd/journal/syslog" ) # provides
support for local system logging
There was a simpler line there, I commented it out.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot,
On 9/7/23 13:28, Dan Ritter wrote:
gene heskett wrote:
On 9/7/23 10:34, Dan Ritter wrote:
gene heskett wrote:
I thought, when I installed bullseye on this box, that a raid is what I
needed for a /home partition, and indeed under bullseye it worked
flawlessly. Since my surprise install of book
On 9/7/23 10:34, Dan Ritter wrote:
gene heskett wrote:
I thought, when I installed bullseye on this box, that a raid is what I
needed for a /home partition, and indeed under bullseye it worked
flawlessly. Since my surprise install of bookworm, cause by an update to
bullseye wiping out my user p
Greetings all;
I thought, when I installed bullseye on this box, that a raid is what I
needed for a /home partition, and indeed under bullseye it worked
flawlessly. Since my surprise install of bookworm, cause by an update
to bullseye wiping out my user pw, so I went to another machine and
d
On Sep 07, 2023, duh_gently...@simplelogin.com wrote:
> Thank you for your advice!
No problem.
>
> lspci says:
> 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models
> 00h-0fh) PCIe GPP Bridge
Okay so it's the root PCI bridge on the motherboard. Are there any
BIOS/UEFI upd
On 07.09.23 13:56, Anssi Saari wrote:
basti writes:
My changes where attached in my last mail. Did you seen it?
Have a look at the mailing archive:
https://lists.debian.org/debian-user/2023/09/msg00157.html
No, you posted only your new versions so I can't know what you
actually changed. You
Thank you for your advice!
lspci says:
00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h
(Models 00h-0fh) PCIe GPP Bridge
The only 2 PCIe devices I have are my video card and my m.2 drive. I
have had different kernel versions as I have had this problem for at
least 6 months (
I'll write my answer here as well, as the OP posted the same posts on
debian-french (also top-posting ...).
Some ISPs or service providers may use private IPs (RFC1918) or even
APIPA for their internal routers, to spare public IPs.
CG-NAT (which uses APIPAs) especially may create some weird pr
basti writes:
> My changes where attached in my last mail. Did you seen it?
> Have a look at the mailing archive:
>
> https://lists.debian.org/debian-user/2023/09/msg00157.html
No, you posted only your new versions so I can't know what you
actually changed. You posted originally that you have:
On 07/09/2023 17:32, Andy Smith wrote:
On Thu, Sep 07, 2023 at 12:20:18PM +0200, Romain wrote:
With -n (sometimes it stops at hop 7, sometimes 9):
└─# mtr -nr 54.38.38.159 -4
Start: 2023-09-07T08:17:12+
HOST: rpi4Loss% Snt Last Avg Best Wrst StDev
^^
On Sep 07, 2023, duh_gently...@simplelogin.com wrote:
> Hello,
>
> I'd like to submit a bug, but I'm not quite sure which package it
> should be.
> I could not find anything similar in the bugtracker.
>
> The problem occurs every 10-20 times. After the system has been suspended
> and then resumed
Hello,
On Thu, Sep 07, 2023 at 12:20:18PM +0200, Romain wrote:
> With -n (sometimes it stops at hop 7, sometimes 9):
> └─# mtr -nr 54.38.38.159 -4
> Start: 2023-09-07T08:17:12+
> HOST: rpi4Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 192.168.0.10
No, I'm using the DNS server included in my ISP modem, in which I can only
select the last digits. It's impossible that an internal device has
received a public IP address in the DNS zone (or it's not something I've
done).
With -n (sometimes it stops at hop 7, sometimes 9):
└─# mtr -nr 54.38.38.15
On 07/09/2023 14:31, Romain wrote:
12.|-- rpi4.home 90.0% 10 7955. 7955. 7955. 7955.
0.0
May it happen that you associated a local device with the IP of your
remote server? Check configuration of the .home DNS zone. Try to add -n
option to suppress DNS lookup and comp
Hello,
I'd like to submit a bug, but I'm not quite sure which package it should
be. I could not find anything similar in the bugtracker.
The problem occurs every 10-20 times. After the system has been
suspended and then resumed, the following message is written to kern.log
and syslog:
2023
On 07.09.23 10:27, Anssi Saari wrote:
basti writes:
Am 06.09.23 um 09:37 schrieb Marco:
Am 06.09.2023 09:24 schrieb Anssi Saari:
That should be enough but I don't really know how pppoe works, I've
only used IPv6 with tunneling, 6rd and 6in4 with the late route48.org.
With PPP IPv6CP (RFC 2
I can reproduce with OVH IPs, but not with Scaleway IPs. I smell filtering
on the OVH side.
Le jeu. 7 sept. 2023 à 09:48, Paul van der Vlis a
écrit :
> Op 06-09-2023 om 15:40 schreef Romain:
> > Next time it happens I'll run more tests from the server to my home.
> > I'm wondering if my modem at
basti writes:
> Am 06.09.23 um 09:37 schrieb Marco:
>> Am 06.09.2023 09:24 schrieb Anssi Saari:
>>
>>> That should be enough but I don't really know how pppoe works, I've
>>> only used IPv6 with tunneling, 6rd and 6in4 with the late route48.org.
>> With PPP IPv6CP (RFC 2472 is being used.
>> It
Op 06-09-2023 om 15:40 schreef Romain:
Next time it happens I'll run more tests from the server to my home.
I'm wondering if my modem at home could not be the culprit. I'm prepared
for more tests here too.
If you have switches at home, those could be the problem too.
You could let log iptable
It happened again last night, but I wasn't able to investigate before I
woke up, and for the moment it's not blocking anymore.
Out of curiosity, I'm doing a regular MTR, and I've had a strange thing
happen.
A normal one (rpi4 at home to OVH):
└─# mtr -r 54.38.38.159 -4
Start: 2023-09-07T07:14:15+0
21 matches
Mail list logo
