| Poštni seznam arhiviranih sporo?il |
Nazaj na seznam |
|
|---|
Hi *,
I released a test version to
http://www.clanganke.de/test/deb103_1004.zip
This includes the standalone executable only. If you use it, make sure that you stop any XCenter running the widget.
New features:
new startup properties page for enable/disable radio
new submenu for to (reconfigure) or disable the IP interface bound to the wifi nic. This should help for scenario 3, when you want to switch from wifi nic to wired nic, at least you can free up the DHCP lease properly. I have no clue yet how a user can best issue a DHCP request for the wired nic after having released the one from the wifi nic - I am not sure if such a feature should be part of XWLAN and where it could be integrated... OTOH we otherwise may have to come back to the 2nd best solution: scripts...
How are you doing this? Is there an API for DHCPMON?
conflict detection: whenever XWLAN configures the IP interface for the wifi nic (either with a static address or by DHCP), XWLAN checks if any other interface is configured for the same IP segment. If so, a popup asks to either disable the conflicting (cabled) interface or to take back the configuration for the wifi nic. Check the config of both lan interfaces with ifconfig before and after you pressed either buttons - it should have deleted either interface to resolve the conflict.
the code executing the DHCP config/unconfig now issues dhcpmon calls only (no more kill of DHCPCD.EXE)
whenever the configuration of the wifi nic IP has been completed, XWLAN flushes the ARP cache (!!). I think this has not been noticed in the previous discussions, but is very important, once the same router needs to be reached over a different interface. If the arp cache is not flushed, the arp entry will make the stack stick to the hardware used last time, even when the IP interface has been deleted.Interestingly, it is not even necessary to kick out obsolete "duplicate" entries of net routes out of the routing table (see ntetstat -r) after having switched the default route from lan0 to lan1(or vice versa) - even if there are still net routes pointing to the now unavailable interface (ssee rightost column of netstat -r), the IP stack manages to find the correct route once the arp cache is flushed.Yes, this is a very good point, which we have discussed a few times on this list with regard to Neil's scripts. I thought, though, that it would still be necessary to flush the routing table. This is a good tip.
|
Naro?iti: Poro?ilo (Feed),
Izvle?ek (Digest),
Indeks. Odjava E-pošta za mojstra za sezname |