ARP requests on my net?

[Mike McCarty]

Les Mikesell wrote:
> On Tue, 2006-04-04 at 22:22, Mike McCarty wrote:
> 

>>So my Linux machine is asking for router's MAC address so it
>>can dump packets destined for the router? That might make sense
>>on a 10 Base 2, yes, because everyone would see all messages
>>(that didn't collide, that is :-) 
> 
> 
> Ethernet still acts the same as it did on coax.  You aren't
> doing point-to-point at the hardware layer just because
> the 10/100Base-T jacks work that way.

Of course. But this has nothing to do with dumping packets in
the IP layer. (I realize that you're not the one who suggested
that this was the reason.)

>>But the message is coming
>>from IP, because it knows its own IP address. Why would IP be
>>putting layer 2 addresses into messages?
> 
> 
> It has to, if it wants to deliver over media that needs them.
> Just like IPX or Appletalk (etc.) would have to in order to
> use ethernet.
> 
> 
>>HTTP, SMTP, FTP, etc.
>>TCP
>>IP (ICMP)
>>LAN/PPP/Frame Relay/ATM or etc.
>>physical
>>
>>In this case, the LAN protocol is "ethernet", which needs to
>>know its own MAC, and that of its gateway. Anything not matching the
>>MAC should be dumped. With a semi-intelligent board the board itself
>>should dump packets not destined for its MAC. 
> 
> 
> Yes, that's the point, packets that aren't broadcast/multicast or
> destined for that MAC address are ignored efficiently.  And
> unwanted multicast is usually ignored fairly efficiently.

Ok, so why is the IP layer asking the router for its MAC? So it
can send to its gateway? That makes sense, but has nothing
to do with dumping packets. Or does it?

>>Is it the case that
>>layer 1 is asking for its gateway MAC? Somehow, this looks like
>>mixed layers to me. It looks like IP is asking for a MAC which
>>it doesn't need. Or does IP need the MAC of the destination
>>to instruct layer 1 where to send to the gateway?
> 
> 
> Not just it's gateway - it needs the MAC address to deliver
> any packet to any specific address on the local lan.  TCP
> knows about ethernet, not the other way around.  When

Presumably you mean that IP knows about ethernet.

> TCP needs to send on the local subnet, it constructs an
> ethernet packet, and it needs the destination MAC to
> do that - and it uses ARP to get it when needed.  If it
> is sending to something off the local net, then it still
> needs to send to the router via ethernet so it ARP's the
> gateway MAC address but constructs the packet with the
> real destination IP. 

What you say makes sense (except that TCP sits on top of
IP, so presumably it is IP making the requests; I do
realize that some use integrated TCP/IP stacks).

But what has this to do with dumping packets not destined for
me? IOW, what you say makes sense for routing out, but not
for dumping packets.

>>Is it presuming
>>that the gateway (router) may have gone down, and another device
>>with a different MAC may have taken over, and been assigned the
>>same IP via DHCP?
> 
> 
> Most devices other than routers have a very short arp cache
> time to allow you to change devices and addresses.  Routers
> can cache up to 20 minutes.  If you aren't aware of this it
> can cause trouble when you try to quickly swap in a replacment
> machine or ethernet card.

Fine. My machine is querying its gateway to know how to route.

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
172.17.0.0      *               255.255.0.0     U     0      0        0 eth0
default         router          0.0.0.0         UG    0      0        0 eth0

And it does it every two minutes, apparently.
But that has nothing to do with dumping packets, does it?

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!