Hi everyone,
I have noticed a different behaviour related to the way the arp table
is managed depending on the tool I use to configure the interfaces
(iwconfig or iw).
In particular, I considered the following two cases (ath5k used for both).
First case: I create the interface with iw (in ad-hoc mode), then I set
the essid and the channel with iwconfig. After a while (several minutes)
I change the channel with iwconfig in order to join a different ibss
(with the same essid) on the new channel. The kernel used was 3.0.
Second case: I create the interface with iw (in ad-hoc mode), then I
join an ibss (on a certain essid) setting at the same time the freq (in
fixed-freq mode), with iw. After a while I leave the ibss and join
another ibss on a different channel with iw (by first issuing iw ibss
leave and then iw ibss join on the new channel). The kernel used was 3.2.
It seemed to me that in both cases the "current" ibss was left and the
new one was joined (by looking at dmesg output). However, in the second
case, I noticed some arp requests just after the ibss join, while in the
first case no arp request at all. Is it due to the fact that in the
second scenario the arp table was erased? Is that a known behavior?
It would be useful for me to know that as unfortunately I cannot easily
repeat the two tests; I would therefore be glad if some of you could
give me some hints on what has been happening in the second case that
triggered the arp requests (I can say almost for sure that it was not
due to the arp timeout because the timeout was larger and I got the same
results for different repetitions, i.e. arp request just after the ibss
join).
Thanks in advance,
Giovanni
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
