Mike Mestnik wrote: >> mac address changes at every hop. The mac is *always* going to be your
> Assuming you could, do the imposible and, find out what the original mac > was. (We seam to agree)You can't send a pkt to a mac address not on your > local network. I can only deal with the possible. >> next-hop router's address. No use sending it back to it, it doesn't > Not next-hop, where talking about source MAC, the last(previous)-hop. OK. Talking again about a stub net. The last router to touch the packet would be the router that all packets for your net come in on and go out on. It's the same router. outgoing Next hop and incoming prev hop are the same router. Semantics. >> care. >> > What do you mean by care? If I take you literaly, that router cared enuff > to send us the original pkt. The idea is the host(router) that gave us > the pkt had a reverse route for the IP. This MUST be true > since(other-wise) that router should/would have been the one to red flag > the pkt. > What information are you going to send that router? Are you going to tell it that it sent you a packet it shouldn't have? What type of packet? Are you going to send an icmp dest unreachable? The router is forwarding packets. It's not the originator of the packet and if you send it a icmp dest unr. back to it, it's going to discard the packet. It simply won't know what you are talking about and drop the packet. > In cases where that router made a mistake it would/might send the reject > pkt back to us. In these cases we can do one of two things, keep state > and see that we can just drop this pkt or subtract one from the > TTL(eventualy it will be out of time) and bounce it back. OK, here's my last on this. Let's have a scenario that is pretty common. udp packet with a spoofed source address. That's spoofed IP address. The packet is sent from the originating host and travels along the net thru routers that care about *1* thing - destination. They look at the destination address and forward the packet out the right interface. Period. It moves along the net and finally gets to your network and hits your debian firewall, which is forwarding for an internal LAN. You are a firewall and you look at the source address and note that it says it's coming from your internal net, however it is coming in on the external interface. Decision? Reject the packet? As I've said before, you don't know where to send it. Your stack is going to create a packet with a desstination address of a host on your *internal* net and then your routing table is going to make the decision to route that packet out your internal interface. It's that simple. There are no 'what if we could find the original mac address' or 'maybe the prev-hop router will do something if I send a packet'. At this point, we've gone miles past a response to path mtu discovery, and Steven's has a great book on TCP/IP. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
