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 db_ext...@gmx.de
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
On Tue, Jul 21, 2015 at 4:38 PM, Sebastian Fett db_ext...@gmx.de 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
On Wed, Jul 22, 2015 at 9:49 AM, Sebastian Fett db_ext...@gmx.de 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
On Tue, Jul 21, 2015 at 4:38 PM, Sebastian Fett db_ext...@gmx.de 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
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
