TCP IP keil stack support

Note that in a local area network, you address data to a network card using the MAC addresses - not IP numbers. The IP numbers are just used for making ARP lookups. The sender broadcasts an ARP request asking which MAC address that wants to respond to the destination IP. The sender machine then caches any answer it receives and then continues to send data to this MAC address for a while.

Introducing a machine that responds "me" to all ARP requests can be used by data thieves to hijack communication in a network - the machine that is quickest to respond to that ARP request will win.

When hardening a machine, it is normal to have firewall rules that looks at the destination IP number of received packets to verify that the destination IP really belongs to the receiving machine. But this is normally a task for a firewall - the TCP/IP stack don't really care.

So if I have a computer with known MAC address but unknown IP number somewhere in an office network, I can assign my own IP number to that MAC address in my local computer. And then send messages to this other computer. This is often used when configuring web cameras, etc, that don't have any manual interface for setting up an IP number and the network don't have any DHCP server that can assign an IP number. So a configuration tool can invent an IP number for that web camera. The user can then connect to the camera using this invented IP number and access a web page where the real settings can be specified.

In your case - don't expect the Keil stack to look at the destination IP numbers except for when answering ARP requests. If you need firewalling - add own code to check the destination IP whenever you get a connect.

Note that computers, switches, ... caches the ARP answers, so a while after you have chaneged an IP number, caching information will remember the older IP number->MAC mapping.

Note that in a local area network, you address data to a network card using the MAC addresses - not IP numbers. The IP numbers are just used for making ARP lookups. The sender broadcasts an ARP request asking which MAC address that wants to respond to the destination IP. The sender machine then caches any answer it receives and then continues to send data to this MAC address for a while.

Introducing a machine that responds "me" to all ARP requests can be used by data thieves to hijack communication in a network - the machine that is quickest to respond to that ARP request will win.

When hardening a machine, it is normal to have firewall rules that looks at the destination IP number of received packets to verify that the destination IP really belongs to the receiving machine. But this is normally a task for a firewall - the TCP/IP stack don't really care.

So if I have a computer with known MAC address but unknown IP number somewhere in an office network, I can assign my own IP number to that MAC address in my local computer. And then send messages to this other computer. This is often used when configuring web cameras, etc, that don't have any manual interface for setting up an IP number and the network don't have any DHCP server that can assign an IP number. So a configuration tool can invent an IP number for that web camera. The user can then connect to the camera using this invented IP number and access a web page where the real settings can be specified.

In your case - don't expect the Keil stack to look at the destination IP numbers except for when answering ARP requests. If you need firewalling - add own code to check the destination IP whenever you get a connect.

Note that computers, switches, ... caches the ARP answers, so a while after you have chaneged an IP number, caching information will remember the older IP number->MAC mapping.