Package: isc-dhcp-client
Version: 4.4.3-P1-1.1
Followup-For: Bug #932769
Hi,
We experience this issue too, in Bullseye and Bookworm (updated from
Bullseye).
Our environment is similar to that described by Mark (the initial
reporter), i.e., a VMware ESXi cluster with VMs stored on a network
> On Wed, 31 Jul 2019 08:37:37 +0200, Sven Hartge said:
> This bug has been fixed in ISC DHCP 4.3.6.
I had the problem with Debian stretch. Since I'm moving to buster soon,
this is not that important for me. But it may be nice to have this fixed
for stretch.
> In my opinion this chan
On 31.07.19 08:37, Sven Hartge wrote:
> This was ISC-Bug 45457:
> https://bugs.isc.org/Public/Bug/Display.html?id=45457
>
> This bug has been fixed in ISC DHCP 4.3.6.
>
> The commit implementing this is
> https://gitlab.isc.org/isc-projects/dhcp/commit/3e88222f1c2f7a365b9fde018bb4bf86520b51d6
I
On 31.07.19 00:20, Thomas Lange wrote:
> First I can confirm this bug. Some time ago I had two servers which
> caused a huge amount of dhcp requests to log the DHCP server (managed
> by a different departement). They told me one server did 30 requests
> per seconds.
> I've looked at the CentOS 8
First I can confirm this bug. Some time ago I had two servers which
caused a huge amount of dhcp requests to log the DHCP server (managed
by a different departement). They told me one server did 30 requests
per seconds.
I've looked at the CentOS 8 sources and found this patch:
> # If we receiv
Hi Tomas,
Thanks for recategorizing the bug and applying the version. I was getting
caught up and see you already did this.
Just wanted to add a few points from additional testing I've been doing.
> I can't replicate this by damaging /var in any other way. I've tried
filling the volume up unti
On 24.07.19 11:13, Tomas Pospisek wrote:
> So my interpretation of your initial bug report, that the VM would DoS
> the host on which it was running via fast changing of IP addresses on
> its interface was completely off the track?
>
> So what you wanted in fact wanted to say by "DoS'ing the serv
i-bin/bugreport.cgi?bug=888209
Thanks, just let me know if you have any questions.
On Tue, Jul 23, 2019 at 4:23 PM Tomáš Pospíšek wrote:
Am 23.07.19 um 17:57 schrieb Ben Hutchings:
> On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
>> Package: general
>
On Tue, 23 Jul 2019 19:32:04 -0600 Mark Hutchison
wrote:
> When I look at systemctl for the dhclient service, I can see that there's
> an error, "can't create /var/lib/dhcp/dhclient.intname.leases Read Only
> file system", and then the DHCPREQUEST > DHCPACK > DHCPDECLINE sequence
> starts every f
Hi fellas,
Apologies for the brevity in the initial bug report. I was using the
reportbug tool directly from the console of the VM I was working on, small
resolution. Allow me to elaborate...
We initially discovered this bug testing our storage product, we had a
Debian 10 VM running in a typica
9 at 4:23 PM Tomáš Pospíšek wrote:
> Am 23.07.19 um 17:57 schrieb Ben Hutchings:
> > On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
> >> Package: general
> >> Followup-For: Bug #932769
> >>
> >> Could you privide a recipe on how to reproduce this?
Am 23.07.19 um 17:57 schrieb Ben Hutchings:
> On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
>> Package: general
>> Followup-For: Bug #932769
>>
>> Could you privide a recipe on how to reproduce this? There's a lot of
>> very special setup below, tha
On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
> Package: general
> Followup-For: Bug #932769
>
> Could you privide a recipe on how to reproduce this? There's a lot of
> very special setup below, that someone wwould need large amounts of time
> to reporoduce I fe
-dhcp-client? [...]?): shouldn't there be some rate
limiting sanity check in the DHCP client?
*t
On Tue, 23 Jul 2019, Tomas Pospisek wrote:
Package: general
Followup-For: Bug #932769
Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, th
Package: general
Followup-For: Bug #932769
Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.
Is it possible to reduce the problem to something easily demonstratable?
This see
Package: general
Severity: important
Tags: l10n
Dear Maintainer,
While doing unrelated storage testing for our VMware integrated product, we
purposefully recreated
a storage outage by removing the iSCSI initiators from the backing array
hosting the vmdk disk
images for the virtual machine.
Up
16 matches
Mail list logo
