Just a quick update on the subject.
Thanks for the input. It's good to see that I am not the only one that
has this problem.
Right now we go with our initial approach and bcast our arp responses.
We have a very local network build only for one purpose. Other devices
in that network use the same
From: Sebastian Fett
Date: Wed, 22 Jul 2015 09:49:49 +0200
> I think that behaviour is acceptable because it only happens in local
> networks. Waking up sleeping devices will not be a concern there.
No, it is not acceptable.
If your laptop or cell phone's wireless interface is sleeping, they
ar
On Wed, Jul 22, 2015 at 9:49 AM, Sebastian Fett wrote:
>> what is your use case?
>>
>
> My problem ist a local network of audio devices. It is a valid possibility
> that two halfs of the setup are set up individually (Stage left and stage
> right). Both local networks will auto configure themselv
On Tue, Jul 21, 2015 at 4:38 PM, Sebastian Fett wrote:
Hello!
According to RFC3927 every ARP packet (reply and request) should be sent as
link layer broadcast as long as the sender IP is a link local address. (see
chapter 2.5).
Because broadcast replies are noisy and should be avoided.
if pos
On Tue, Jul 21, 2015 at 4:38 PM, Sebastian Fett wrote:
> Hello!
>
> According to RFC3927 every ARP packet (reply and request) should be sent as
> link layer broadcast as long as the sender IP is a link local address. (see
> chapter 2.5).
Because broadcast replies are noisy and should be avoided.
Hello!
According to RFC3927 every ARP packet (reply and request) should be sent
as link layer broadcast as long as the sender IP is a link local
address. (see chapter 2.5).
That functionality would help me a lot with a use case I have with our
application.
But it is not implemented in the ke
