Manager, QA &
Canada H4T 1V3
Tel. : 514.335.9867 #3279
Cell. : 514.994.7360
Fax : 514.333.9873
Look at the netsh command line in winXP. I use this to set interfaces
through batch file. Here is an example of the command:
Sebastian Pein <pein <at> infinity-networks.de> writes:
Then to be really show my 'ignorance' of IP knowledge, what if the host
portion was identical at the hotspot? Such as:
XP IP at hotspot - OpenVPN - Host IP at Office
192.168.128.1/24 - 172.16.0.0/24 - 192.168.128.2/26
Notice the borrowed bits on the Office Subnet Mask? Now if I ping
192.168.128.2 from XP will it route correctly?
i guess these two computers will not be able to see each other. at least the
at hotspot will speak to the .2 via arp/ethernet. as xp will look at the mask
of 24 bits it will think the .2 lives in the same ip-segment and will be
reachable directly, without usage of any routing tables. but let me think
the office-host. this one too will try arp/ethernet speech, because the .1 is
also in the same subnet when considerung the 26bit mask. it would use the
routed way if the hotspot xp would have been assigned > .64 (hope i
right in my head?!).
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....<a
Just discovered something interesting with XP TCP/IP stack!
I am able to collect the current dhcp assigned IP and subnet mask for the XP
nic interface. Then drop DHCP, re-assign the same IP but with a NEW subnet
mask of 255.255.255.252, the stack does seem to restart, but is un-noticed by
the local switch servicing the XP box. The route tables reflect the change
Then start OpenVPN on the XP box. (If I make the switch after OpenVPN start,
it restarts itself and connects the vpn tunnel again successfully).
All works normally, except of course I would not be able to ping anything on
the local subnet of the XP box, but as these are clients at hotspots, I think
that would be a huge benefit anyway and help protect the machine from war
I can even collect the OpenVPN assigned client IP address and change the local
interface to use that as it's default gateway on the client. When this change
occurs, the XP TCP/IP stack does not seem to restart! Therefore the OpenVPN
tunnel does not go down. This seems to cut off the XP box to any traffic
except through the OpenVPN tunnel. Check the route tables on the XP box and
they seem correct showing the new OpenVPN tunnel as the gateway.
Once the OpenVPN session ends, the XP interface can be set back to dhcp and
everything is cleaned up in the routing tables! Without reboot, amazing, for
So now I just need to develop .net or vbscript to automate it all, we'll see.