On Mon, 19 Nov 2007, Alexey Kuznetsov wrote:
> Hello!
>
> > Is there a reason that the target hardware address isn't the target
> > hardware address?
>
> It is bound only to the fact that linux uses protocol address
> of the machine, which responds. It would be highly confusing
> (more than
Hello!
> Is there a reason that the target hardware address isn't the target
> hardware address?
It is bound only to the fact that linux uses protocol address
of the machine, which responds. It would be highly confusing
(more than confusing :-)), if we used our protocol address and hardware
Hello!
Is there a reason that the target hardware address isn't the target
hardware address?
It is bound only to the fact that linux uses protocol address
of the machine, which responds. It would be highly confusing
(more than confusing :-)), if we used our protocol address and hardware
On Mon, 19 Nov 2007, Alexey Kuznetsov wrote:
Hello!
Is there a reason that the target hardware address isn't the target
hardware address?
It is bound only to the fact that linux uses protocol address
of the machine, which responds. It would be highly confusing
(more than confusing
Hi,
I started to look at this code when I was working on a project of
rewriting a dhcp-client.
I wanted to make the client use arp to determine if the offered
address was free or in use.
Thats when I noticed that linux machines responded in this, for me, odd way.
The problem is not really the
Hello!
> Send a correct arp reply instead of one with sender ip and sender
> hardware adress in target fields.
I do not see anything more legal in setting target address to 0.
Actually, semantics of target address in ARP reply is ambiguous.
If it is a reply to some real request, it is set to
Fix arp reply when received arp probe with sender ip 0.
Can't find any ground in RFC2131 to send a non-valid arp-reply in
the special case of sender ip being set to 0.
- Bug fix for arp handling when sender ip is set to 0.
Send a correct arp reply instead of one with sender ip and sender
Fix arp reply when received arp probe with sender ip 0.
Can't find any ground in RFC2131 to send a non-valid arp-reply in
the special case of sender ip being set to 0.
- Bug fix for arp handling when sender ip is set to 0.
Send a correct arp reply instead of one with sender ip and sender
Hello!
Send a correct arp reply instead of one with sender ip and sender
hardware adress in target fields.
I do not see anything more legal in setting target address to 0.
Actually, semantics of target address in ARP reply is ambiguous.
If it is a reply to some real request, it is set to
Hi,
I started to look at this code when I was working on a project of
rewriting a dhcp-client.
I wanted to make the client use arp to determine if the offered
address was free or in use.
Thats when I noticed that linux machines responded in this, for me, odd way.
The problem is not really the
Hi,
I was working on a project that involved having our dhcp-client
performing a check on the offered IP-address to make sure it wasn't in
use.
The standard way of doing this is sending out an arp request with the
sender ip set to 0. (RFC2131).
When I was testing out my implemented solution I
Hi,
I was working on a project that involved having our dhcp-client
performing a check on the offered IP-address to make sure it wasn't in
use.
The standard way of doing this is sending out an arp request with the
sender ip set to 0. (RFC2131).
When I was testing out my implemented solution I
12 matches
Mail list logo
