# why does my computer "remember" an old ip address

## albright

This is probably not gentoo specific, but I'm running

gentoo and noticed this weird behaviour.

I have a laptop that works great with kernel 2.6test9

(mm-sources). The internal nic has address 192.168.0.5

My wireless card gets address 192.168.0.7

I don't have pcmcia start at boot, nor are the modules

for the wireless card loaded. I start these manually

when I want to use the wireless card and after it's

inserted I set the essid, key, ip address and netmask

and route gateway.

But let's say the wireless card is on (eth1). Eth0 is down

with no cable plugged in. If I ping 192.168.0.5 from another

computer the laptop responds. If I ssh into the laptop

with user@192.168.0.5 the laptop permits a logon. It

will also respond to pings to 192.168.0.7 and will permit

ssh logons to user@192.168.0.7.

ifconfig reports that only eth1 is up with ip address

192.168.0.7 (plus lo of course).

It's like the computer "remembers" it used to be (sometimes

is) 192.168.0.5. My question is just WHY is this happening.

Obviously my understanding of networking is rudimentary,

but this just doesn't seem right. Any advice would be welcome,

and sorry for the long post.

----------

## phosphan

Could you please post the output of

```
ifconfig -a

route -n

```

Btw, I don't think it's a good idea to have both interfaces in the same network.

----------

## smart

I could imagine this being magic in the other machine, not in the gentoo box.

Give me this hint:

At some time, not long before testing/seeing this situation, you had both network interfaces up and running and tried to connect to eacho of from some other machine ?

----------

## phosphan

 *smart wrote:*   

> I could imagine this being magic in the other machine, not in the gentoo box.
> 
> 

 

Thinking of ARP cache "magic"?

----------

## smart

Ya. When you had both interfaces running before, answer will probably only go out through one and the same interface, but prolly with the original "from" IP. Now i can imagine in the receiving box, ARP would get updated with the same MAC in both cases and from now on use one and the same interface as point of contact for both of these IPs, just as if you had a secondary IP configured on that same interface.

EDIT: Actually, that is sth. that could possibly get imrpoved upon in Linux networking. Having more than one possible routes into a network depending on the from address, so you could make effective use of more than one interface into one and the same network by using the bandwidth of more than one NIC. Another guy here in the forums had a situation where this would have solved his problem, too. You could have your alias IP be set on a secondary NIC instead of one and the same main one... would be a nifty feature i guess. :=)

Some kernel/network wizzies in here that would like to take that opportunity ?  :Smile: )

----------

## phosphan

 *smart wrote:*   

> 
> 
> Having more than one possible routes into a network depending on the from address, so you could make effective use of more than one interface into one and the same network by using the bandwidth of more than one NIC.

 

Something quite similar is described here: http://ds9a.nl/2.4Networking/howto/lartc.loadshare.html - or did you mean something different?

----------

## smart

no, i think this kind of thing is even more wizzy style. it makes two links appear like one with double the bandwidth on a single IP address. You need support on two ends of that kind of thing. Be it two servers/machines or be it machine and superhypercool switch.

I was more referring to the previous stuff. That is two NICs, with one IP each, but in the same subnet.

say as the previous example

NIC A: 192.168.1.2/24

NIC B: 192.168.1.3/24

your machine would prolly receive on both NICs but answer on one only, depending what routing entry is found (first?) you'll see that your routing entries say that for anything that should go to the 192.168.1.0 net it shall use interface A(?) (or the other one), no matter where it came in. So if routing would preserve and use the incoming address used for the deicision where to send out the packets (maybe it does and i'm wrong? currently i don't think so, though).

so if your boxen receives a request that uses 192.168.1.3 as "to" address, it should send out the answer using NIC B, but AFAIK currently it would answer on NIC A (or the other way round, don't know if first or second entry would count) and requests on 192.168.1.2 shall still use NIC A outgoing.

----------

## smart

the magic is gone ?

EDIT: somebody knows how to issue a feature suggestion to the kernel gurus ?

----------

## phosphan

 *smart wrote:*   

> 
> 
> So if routing would preserve and use the incoming address used for the deicision where to send out the packets (maybe it does and i'm wrong? currently i don't think so, though).
> 
> so if your boxen receives a request that uses 192.168.1.3 as "to" address, it should send out the answer using NIC B, but AFAIK currently it would answer on NIC A (or the other way round, don't know if first or second entry would count) and requests on 192.168.1.2 shall still use NIC A outgoing.

 

I think I got the idea. This should work with "ip rule" using an fwmark as selector.

The idea is to mark all packets (using iptables) which belong to connections with a specific destination. "ip rule" can then use this fwmark to use a specific routing table for these packets.

Didn't try, but this should work.

----------

## smart

if that's possible, that would be a nice workaround. but in the meantime, i have moire or less conviced myself that this would be a workaround on top of a bug more or less. while the decision for the box with two NICs would still follow a clean logic (though maybe not nice logic) the possible result of this on the receiving end is no good, that is the ARP cache would probably get a WRONG entry, since it would associate the IP with a MAC that doesn't match. Methinks, that could be classified as a bug.

----------

## phosphan

Did you already find the passage about the arp_filter parameter in /usr/src/linux/Documentation/networking/ip-sysctl.txt ?

----------

## smart

no, but interesting... don't fully get the description for setting 1 (i don't see the definition of when/what/where to check). But there seems to be something like sourcerouting in the pot... looking for that...

EDIT: out for reading for a while...  :Wink: 

----------

## phosphan

Hint: it's about /proc/sys/net/ipv4/conf/*/arp_filter

----------

## smart

hrhr, ok this ip policy routing is nifty stuff, but probably overkill for the originator of this thread. so i'd stick to the single NIC approach

----------

