On Tue, Jun 3, 2014 at 11:37 AM, Tom Gundersen wrote:
> On Mon, Jun 2, 2014 at 2:09 PM, Patrik Flykt
> wrote:
>> On Fri, 2014-05-30 at 17:21 +0100, Tom Gundersen wrote:
>>> I'm wondering if the criterion should be to request broadcast if and
>>> only if we have not configured an IP address (I.e.
On Mon, Jun 2, 2014 at 2:09 PM, Patrik Flykt
wrote:
> On Fri, 2014-05-30 at 17:21 +0100, Tom Gundersen wrote:
>> I'm wondering if the criterion should be to request broadcast if and
>> only if we have not configured an IP address (I.e. only in
>> discovering, requesting and init-reboot), as that s
>Then again, if the network is known to operate correctly, it is better
>to request and get unicast delivery all the time instead. Should we have
>a configuration parameter that requests broadcast delivery by default
>and therefore works in all places? The system owner can then turn on
>unicast del
On Fri, 2014-05-30 at 17:21 +0100, Tom Gundersen wrote:
> I'm wondering if the criterion should be to request broadcast if and
> only if we have not configured an IP address (I.e. only in
> discovering, requesting and init-reboot), as that seems to be the
> problem, or did I get that wrong?
Yes, I
On Fri, 2014-05-30 at 17:42 +0100, Tom Gundersen wrote:
> > Actually, I have had recent reports from users that there seems to
> exist
> > a category of networking devices
>
> Do you have any more info on this by any chance? Any way we may
> classify these devices in a robust way?
Unfortunately i
On 30 May 2014 10:12, "Patrik Flykt" wrote:
>
> On Thu, 2014-05-29 at 00:03 +0100, Tom Gundersen wrote:
> > On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar
> > wrote:
> > > In systems running on hypervisors this flag needs to be set ON, so
offers can reach
> > > the virtual machines.
> > >
> > >
On 30 May 2014 10:25, "Patrik Flykt" wrote:
>
> On Thu, 2014-05-29 at 18:18 +0100, Tom Gundersen wrote:
> > + if (link->udev_device) {
> > + const char *l2;
> > +
> > + l2 = udev_device_get_sysattr_value(link->udev_device, "layer2");
> > + if (l2) {
> > + unsigned layer2;
>
> I'd really hope we could avoid setting broadcast everywhere, as that
>seems very wasteful...
I agree with you, broadcasting everywhere it's clearly not convenient.
It seems to me the ideal path to move forward looks like this:
1. Use platform specific raw sockets for the first attempt of ge
On Thu, 2014-05-29 at 18:18 +0100, Tom Gundersen wrote:
> + if (link->udev_device) {
> + const char *l2;
> +
> + l2 = udev_device_get_sysattr_value(link->udev_device, "layer2");
> + if (l2) {
> + unsigned layer2;
> +
> + r = safe_atou(l2, &layer2);
> +
On Thu, 2014-05-29 at 00:03 +0100, Tom Gundersen wrote:
> On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar
> wrote:
> > In systems running on hypervisors this flag needs to be set ON, so offers
> > can reach
> > the virtual machines.
> >
> > For more information please refer to this thread in Core
On Fri, May 30, 2014 at 3:24 AM, Camilo Aguilar
wrote:
> Hi Tom, the patch did not work because there is no layer2 file. Would it be
> safe to assume that no file is the same as the file having 0? This is out of
> my reach unfortunately, but I will be happy to read whatever link you throw
> at me.
Hi Tom, the patch did not work because there is no layer2 file. Would it be
safe to assume that no file is the same as the file having 0? This is out
of my reach unfortunately, but I will be happy to read whatever link you
throw at me.
Also, to better clarify how ISC dhcp-4.3.0 works. It seems it
Hi Tom, thanks for the updated patch. I'm going to test it and let you know
the results.
As for the drivers involved here: e1000 and vmxnet3 (VMware)
Best,
Camilo
On Thu, May 29, 2014 at 1:18 PM, Tom Gundersen wrote:
> On Thu, May 29, 2014 at 6:05 PM, Camilo Aguilar
> wrote:
> > No, I don't
On Thu, May 29, 2014 at 6:05 PM, Camilo Aguilar
wrote:
> No, I don't see it in any of the machines that are failing.
What driver is used on the interface that fails? The qeth driver
should always expose the layer2 value in sysfs as far as I can tell.
The attached (entirely untested) update of you
No, I don't see it in any of the machines that are failing.
On Thu, May 29, 2014 at 5:04 AM, Kay Sievers wrote:
> On Thu, May 29, 2014 at 4:42 PM, Camilo Aguilar
> wrote:
> > gah, the link for 2 is
> >
> https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8
> > ins
On Thu, May 29, 2014 at 4:42 PM, Camilo Aguilar
wrote:
> gah, the link for 2 is
> https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8
> instead
>> 2. The network interface says that it needs broadcast
Do you see that "layer2" file in /sys on the machine that does n
gah, the link for 2 is
https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8
instead
On Thu, May 29, 2014 at 4:41 AM, Camilo Aguilar
wrote:
> I spent some time studying the standard ISC's implementation. And, unless
> I'm misreading the code, for Linux the client se
I spent some time studying the standard ISC's implementation. And, unless
I'm misreading the code, for Linux the client seems to always set the
broadcast bit ON except when SOCKET_CAN_RECEIVE_UNICAST_UNCONFIGURED is
defined in compilation time, which I don't see anybody doing. For the rest
of the
You are right. Apologies. I was stuck on my own work due to this issue and was
eager to get it solved too soon.
I'll spend some more time tonight digging about how other DHCP clients deal
with detecting if the interface supports link level unicast or not.
—
Sent from Mailbox
On Wed, May 28,
On Wed, May 28, 2014 at 4:13 PM, Camilo Aguilar
wrote:
> Oh, never mind, there is no rush since we are already custom patching in
> CoreOS for now.
Hey, don't get ahead of yourself. I haven't merged your patch into
CoreOS just yet ;-)
I'm fine with the patch being a temporary fix as long as we ca
Oh, never mind, there is no rush since we are already custom patching in
CoreOS for now.
On Wed, May 28, 2014 at 7:10 PM, Camilo Aguilar wrote:
> It makes total sense. I can provide that patch in addition if you like,
> But, can we merge this change for now so we can fix
> https://github.com/cor
It makes total sense. I can provide that patch in addition if you like,
But, can we merge this change for now so we can fix
https://github.com/coreos/bugs/issues/12 and create a new issue to make it
more robust?
On Wed, May 28, 2014 at 7:03 PM, Tom Gundersen wrote:
> On Wed, May 28, 2014 at 7:4
On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar
wrote:
> In systems running on hypervisors this flag needs to be set ON, so offers can
> reach
> the virtual machines.
>
> For more information please refer to this thread in CoreOS:
> https://github.com/coreos/bugs/issues/12
>
> Signed-off-by: Cam
In systems running on hypervisors this flag needs to be set ON, so offers can
reach
the virtual machines.
For more information please refer to this thread in CoreOS:
https://github.com/coreos/bugs/issues/12
Signed-off-by: Camilo Aguilar
---
src/libsystemd-network/sd-dhcp-client.c | 9
24 matches
Mail list logo
