openvpn-devel Mailing List for OpenVPN

Hi list! I set my openvpn server to dish out default routes with a high metric. This allows me to prefer hard wired LAN over the vpn, whilst allowing the same openvpn server to provide default routes for my wireless. Config is like so push "route 0.0.0.0 0.0.0.0 10.73.1.1 500" This works great! However, when the openvpn client stops it tears down all default routes - which is not desirable. Attached is a patch that only tears down routes on the metric given, so if a route was created with a metric, tear down the route with that metric. Only patched for Linux systems as I'm unsure of the command for others - although its probably very similar. Thanks -- Roy Marples <ube...@ge...> Gentoo Linux Developer 

Dave, I've got the latest code. TAPTester compiles without any error. I'm using Win 2003 as my OpenVPN server. Could you send me the server configuration file that you used for testing. Did you use emulator for ping test? Salamz, -IQ Dave <de...@zi...> wrote:Iftikhar; If interested, I just updated the source to correct a bug (previously you had to specify the dev-node option) and to emulate supporting the nobind option. You still have to use the ip-win32 ipapi option. Also, I have some initial good news. I have successfully ping'ed the server-side end of the tunnel. This means data is flowing through the driver and protocol stack correctly, from server to openvpn.exe. I used a very minimal server configuration. Now I need to figure out how to set up more options so I probably won't be coding anything for a couple days. -Dave 

>-----Original Message----- >From: ope...@li... [mailto:ope...@li...] On Behalf Of Iftikhar Qureshi >Sent: Monday, March 27, 2006 10:57 AM >To: Dave >Cc: ope...@li... >Subject: RE: [Openvpn-devel] OpenVPN for PocketPC > > Iftikhar; If interested, I just updated the source to correct a bug (previously = you had to specify the dev-node option) and to emulate supporting the nobind option. You still have to use the ip-win32 ipapi option. Also, I have some initial good news. I have successfully ping'ed the server-side end of the tunnel. This means data is flowing through the driver and protocol stack correctly, from server to openvpn.exe. I used a very minimal server configuration. Now I need to figure out = how to set up more options so I probably won't be coding anything for a couple days. -Dave 

Hi all, I'm doing some test with openvpn, and I saw some problem using NTLM auth proxy. I tested the software on a ISA server and all work fine, the problem is using a squid proxy with NTLM. I recognized 2 different problem: - The proxy authorization phase (one, two and three) are done all on the same connection, but the "Connection: keep-alive" or "Proxy-connection: keep-alive" are not set on the request. Some kind of proxy (like squid) after the first request drop the connection, and openvpn doesn't do another connect. - NTLM domain, actualy on openvpn config file the user can't set the domain of the credentials sent to the proxy. An Microsoft ISA server will have a "default domain" to try the authentication, but that doesn't mean that "default domain" will be the right one... Also on squid the domain is required and a null domain will be refused. I hope these info will help you to fix the authentication and made openvpn more reliable. Cheers inode 

> -----Original Message----- > From: James Yonan [mailto:ji...@yo...] > Sent: Monday, March 27, 2006 4:57 PM > To: Dave > Subject: Re: [Openvpn-devel] OpenVPN for PocketPC (...) > > =20 > Are you using OpenVPN 2.0 or 2.1 (better to use 2.1 in this regard). >=20 > Basically if you see repeating cycle of TAP getting > BOOTREQUEST/DHCPDISCOVER messages from the DHCP client=20 > service and then=20 > replying with BOOTREPLY/DHCPOFFER, it means that the DHCP=20 > client service=20 > is not happy with the DHCPOFFER message which was returned by the TAP=20 > driver (or perhaps it didn't receive the message). >=20 > As far as the OpenVPN configuration is concerned, see the static key > howto http://openvpn.net/static.html which includes a very barebones=20 > configuration which should be suitable for testing purposes. >=20 > If you want to test the automatic DHCP negotiation, try using OpenVPN > 2.1 and use "topology subnet". >=20 > Setting the IP/subnet (and other optional attributes) on the > TAP adapter=20 > is problematic on Windows due to the lack of a direct API=20 > call. So the=20 > --ip-win32 option allows multiple methods to be tried. =20 > --ip-win32 ipapi=20 > might work, but it's not clear to me why it used .51 in your=20 > case. It=20 > would help to see your config files. >=20 > Also, keep in mind that the IP helper API doesn't have the > function we=20 > really need which is "Assign IP address, netmask, and other DHCP=20 > properties to network adapter". Instead it has a function=20 > which "adds"=20 > an IP/netmask to an already-configured network adapter. That=20 > means that=20 > you often end up with the primary IP address being the=20 > "autoconfiguration" address, with the one you really wanted=20 > assigned as=20 > a secondary IP/netmask. Less than optimal, and breaks some apps. =20 > That's why --ip-win32 dynamic is the default (which basically=20 > tells the=20 > TAP adapter to implement its own internal DHCP server). >=20 > James >=20 Thanks for taking a look at the debug output. Ultimately I certain my = test environment is configured incorrectly. Unfortunately as I am a newbie = to OpenVPN I don't really know what I am doing. I did originally try = static keys, however I got a complaint that you can't do that with bridging = which is why I made all the certificate stuff. I'll revisit that. At present I can ping the 10.8.0.51 address (the client endpoint) but = not the 10.8.0.4 (the server endpoint). Hmm. Am I maybe missing a gateway = in my routing list? I'm getting this behaviour both on the client NT installation (that I am using as a sanity check) and the PocketPC build. My server is a linux box and I just noticed that there was no br or tap devices listed when I did an ipconfig, so I ran bridge-start and they appeared. Still, I notice that that the tap device does not have an IP address, even when openvpn is running. Shouldn't I expect to see a = 10.8.0.4 assigned to it? I probably just don't understand. Re: 2.1 vs 2.0, I thought 2.1 wasn't done yet? That 2.0.5 was the last released build? Then again maybe I'm just using that because it was the = rpm I had available for the server side.... Configuration files. First, here's briefly the network topology: * internal network 192.168.1.0 / 14 * server: spunky 192.168.1.10 * router: 192.168.1.1 Tap endpoint to be 10.8.0.4 for server and clients get .50-100 During this initial testing I'm actually coming in through the internal network (which I know will ultimately cause problems but I think I = should at least be able to ping both the 10. endpoints initially before worrying = about that). PocketPC client will have address of 192.168.1.129, and NT = client will have 192.168.1.22. OK, server, a Suse linux box is thus: #server config = begin=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D port 1194 proto udp dev tap0 ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt cert /etc/openvpn/easy-rsa/2.0/keys/server.crt key /etc/openvpn/easy-rsa/2.0/keys/server.key # This file should be = kept secret dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem ifconfig-pool-persist ipp.txt server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100 keepalive 10 = 120 comp-lzo persist-key persist-tun status openvpn-status.log log /var/log/openvpn verb 3 #server config = end=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My Pocket PC config is thus: #client config = begin=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D client dev tap dev-node TAP1: proto udp remote 192.168.1.10 1194 local 192.168.1.129 ;ifconfig 10.8.0.40 255.255.255.0 ip-win32 ipapi=20 ;nobind ca "\\ca.crt" cert "\\ipaq4150.crt" key "\\ipaq4150.key" comp-lzo verb 3 #client config = end=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Any input is hugely appreciated. -Dave 

Dave wrote: >> -----Original Message----- >> From: James Yonan [mailto:ji...@yo...] >> > > ... > > >>> etc. I believe the object spaces have been unified, and I know you >>> can take a socket and pass it to, say WaitForSingleObject >>> >> and have it >> >>> work. >>> >> They sort of did that with WSAEventSelect -- if there was a way that >> WSAEventSelect could be used on the TAP device handle (as well as the >> network socket), then that would be another route towards moving away >> from overlapped I/O. >> > > Upon thinking about your suggestion, I think there are some problems: > > * SOCKETs that go to select() can be signalled in three different ways: > read data available, ready to accept writes, and error (more for > WSAEventSelect). Windows handles are either signalled or non-signalled, so > there isn't that breakdown. I think this is internal architecture to > Winsock and I don't know if it could be replicated into other systems. An > interesting research project, though. > Exactly, that's why WSAEventSelect exists -- to provide event mapping from socket to handle space. > I also noticed that sockets are not handles in CE, so the likelihood of > select ever accepting HANDLEs directly is slim to none. There might be some > funky wrapper that could be made, though again there would be research to do > on that. > > >>> the existing event architecture as-is, and I just had to make some >>> specialized versions of tun_finalize, queue_read, open, close, etc. >>> >> How did you deal with getting socket.c off of overlapped I/O >> (or did you >> figure out a way that PocketPC can do overlapped I/O?). >> > > The latter, mostly. It was a happy confluence of events that: > * Winsock implementations are required to support overlapped IO, at least > through the WSA- functions, > * you happily were already using the WSA- functions for the waits and get > results, > * the WSAEvent in CE is really a native event, and the WSAOVERLAPPED is > defined the same as OVERLAPPED > > So it all fell into place. I had to modify tun to call my emulated > overlapped io api, but this wound up being fairly a fairly surgical (i.e. > not gross) change. > > >>> I didn't bother >>> doing the same with writes since they always completed immediately >>> anyway once handing off to NDIS. >>> >> I would worry about assuming this unless the API guarantees it. I've >> seen a few cases in the overall development of OpenVPN where assuming >> that writes always complete immediately (even when totally >> supported by >> observed behavior) introduced subtle bugs. >> > > I'm curious if you can expound. Subtlety is not a virtue in bugs! I was > going by my interpretation of the existing driver code. It seemed to me it > went like: > > 1) IRP_MJ_CREATE comes in > 2) packet is handed off to NDIS via NdisMEthIndicateReceive and finished > via NdisMEthIndicateReceiveComplete > 3) the IoCompleteRequest() finished the IRP under all code paths > immediately > > So it seemed that really it was always completing immediately. And even if > it wasn't, since the next time usermode queues a write it waits for the > first to complete (via finalize) so it didn't seem to be a big loss to leave > that call synchronous. NDIS sends the packet up the stack asynchronously > already. > Some time back I put in some debugging code to print a status line if WriteFile queued an overlapped action rather than an immediate return, and I recall that WriteFile did queue sometimes -- but only when I intentionally stress tested the machine, by having lots of apps running, and making it come in and out of hibernation. If it's rare enough, then it's probably okay to just do a blocked write -- then worst-case-scenario is the event loop halts for some milliseconds, and it's not like people are going to run OpenVPN servers on their PocketPC (where the latency would matter). > >> It's probably not essential to support control-c/keyboard >> signaling -- >> this feature is used mostly by developers who run OpenVPN in console >> mode. Real-world usage of OpenVPN usually involves running >> > > Ah! So I'm the only one to bear the burden! Well, good to know that -- I > hadn't delved that far into the openvpn architecture. Actually, the > management interface sounds like it will make the future task of packaging > up a PPC-relevant UI much more easy than I expected, so that's good news > indeed. > > >> The driver has quite a bit of instrumentation code to help debug/test >> the DHCP handshake. >> > > Yes, now I must figure out how to interpret it. Care to take a look at the > output from the driver and/or openvpn? You might can tell me immediately > what it means where it might take me days to figure it out. I'll stick an > excerpt at the bottom of this message. > > >> Nobind is quite an important option, so I'm surprised that CE >> wouldn't >> support it. If it's really not supported on UDP sockets, it might be >> possible to simulate nobind by binding to a dynamic port number (from >> 49152 through 65535) and if the bind fails, retry the next >> higher value. >> > > What clued me in was the docs for WSARecv which explicitly stated that the > socket must be bound, so I suppose that technically it shouldn't work on NT > either, but just does as a 'gift'. Again, I should be able to emulate the > behavior somewhat by binding a port of 0, though for some reason this > chooses between 1024 and 5000, as opposed to the high ones. The > try-and-repeat you suggest should also work. > > > If it tries a value between 1024 and 5000 then it's probably acting the same as Win 2000/XP which I've also seen allocate from this range. >>> Iftikhar: I updated the source and also I fixed the problem I >>> mentioned previously about the driver not handling the >>> >> power-off state >> >>> correctly; you can power on and off to heart's content. >>> >>> >> Is this fix relevant to the 2000/XP version of the driver as >> well? If >> so, would you mind posting a patch that only addresses this fix? >> > > It's not relevant. The stream driver part for CE has some additional power > management stuff. My doing debug file io at that time is apparently uncool. > I removed that and all worked again. The NDIS power management behaves fine > as-is. > > > >> Okay, a couple questions for you: >> >> The 2000/XP version of the driver uses the OemWin2k.inf file and >> tapinstall.exe (basically a clone of devcon.exe from the DDK) >> to install >> and configure the TAP device nodes. What is the PocketPC way >> of doing this? >> > > Pretty easy: registry keys are set up. If one wishes you can then load the > driver immediately with an ioctl you send to NDIS, or you can soft-reset > (sortof like 'restart windows') and it will be loaded automatically. > > For testing, I made a little app that adds/removes the keys and > loads/unloads the driver. In a release situation this can be handled in the > CAB file, and/or little app like the tapinstall.exe you mention. > > >> 2000/XP provides the netsh utility for programmatically configuring >> network devices. Does PocketPC have any equivalent utility/API? >> > > Yes and no. I'm not familiar with netsh, but understand it to have been > created because it is fancier than the sundry other tools and more amenable > to scripting. There is not an equivalent to this for CE. Now, the stuff > like ping, route, ipconfig, etc., do exist. They don't ship with PPC > because it doesn't have a console out-of-box anyway. They are findable on > the internet and I have a set which I am using now. Actually I think > Microsoft releases the source available -- they're pretty much all a UI to > the IpHelper functions. Which, since you already have those calls in > openvpn, it might obviate the necessity for an end user to worry about them. > > -Dave > > > PS Oh, regarding output from my DHCP, this is what my windows box says > during the last phase of negotiation: > > Sun Mar 26 17:36:30 2006 us=885461 TAP-WIN32 device [OpenVPN] opened: > \\.\Global\{0B8E84A0-84E7-46DB-BEE7-C4B0166791E9}.tap > Sun Mar 26 17:36:30 2006 us=885495 TAP-Win32 Driver Version 8.1 > Sun Mar 26 17:36:30 2006 us=885512 TAP-Win32 MTU=1500 > Sun Mar 26 17:36:30 2006 us=885537 Notified TAP-Win32 driver to set a DHCP > IP/netmask of 10.8.0.50/255.255.255.0 on interface > {0B8E84A0-84E7-46DB-BEE7-C4B0166791E9} [DHCP-serv: 10.8.0.0, lease-time: > 31536000] > Sun Mar 26 17:36:30 2006 us=892848 Successful ARP Flush on interface [5] > {0B8E84A0-84E7-46DB-BEE7-C4B0166791E9} > Sun Mar 26 17:36:30 2006 us=901492 TEST ROUTES: 0/0 succeeded len=-1 ret=0 > a=0 u/d=down > Sun Mar 26 17:36:30 2006 us=901537 Route: Waiting for TUN/TAP interface to > come up... > Sun Mar 26 17:36:32 2006 us=65631 TEST ROUTES: 0/0 succeeded len=-1 ret=0 > a=0 u/d=down > Sun Mar 26 17:36:32 2006 us=65678 Route: Waiting for TUN/TAP interface to > come up... > Sun Mar 26 17:36:33 2006 us=434239 TEST ROUTES: 0/0 succeeded len=-1 ret=1 > a=0 u/d=up > Sun Mar 26 17:36:33 2006 us=434277 Initialization Sequence Completed > > > And this is what the similar section on the pocket pc says: > > Mon Mar 27 08:56:29 2006 us=47349 TAP-WIN32 device [TAP1:] opened: TAP1: > Mon Mar 27 08:56:29 2006 us=48315 TAP-Win32 Driver Version 8.1 (DEBUG) > Mon Mar 27 08:56:29 2006 us=48978 TAP-Win32 MTU=1500 > Mon Mar 27 08:56:29 2006 us=49755 Notified TAP-Win32 driver to set a DHCP > IP/netmask of 10.8.0.51/255.255.255.0 on interface TAP1: [DHCP-serv: > 10.8.0.0, lease-time: 31536000] > Mon Mar 27 08:56:29 2006 us=51431 Successful ARP Flush on interface [131074] > TAP DEVICE 1 > Mon Mar 27 08:56:29 2006 us=84761 TEST ROUTES: 0/0 succeeded len=-1 ret=0 > a=0 u/d=down > Mon Mar 27 08:56:29 2006 us=85677 Route: Waiting for TUN/TAP interface to > come up... > (...12 times...) > Mon Mar 27 08:56:58 2006 us=389816 Initialization Sequence Completed With > Errors ( see http://openvpn.net/faq.html#dhcpclientserv ) > > > During that activity the driver is spewing out the following debug: > > > [TAP DEVICE 1] Unhandled OID ffffff > [TAP DEVICE 1] Unhandled OID 20214 > [TAP DEVICE 1] Unhandled OID 20215 > [TAP DEVICE 1] Unhandled OID 20215 > TAP_Open; dwData = 0x00036110, dwAccess = 0xc0000000, dwShareMode = > 0x00000000; inst = 0x00036110 > [TAP DEVICE 1] [TAP] release [8.1] open request (m_TapOpens=0) > AdapterTransmit ??? src=0:ff:2d:4b:be:28 dest=33:33:ff:4b:be:28 proto=0x86dd > len=86 > AdapterTransmit ??? src=0:ff:2d:4b:be:28 dest=33:33:0:0:0:2 proto=0x86dd > len=62 > AdapterTransmit ??? src=0:ff:2d:4b:be:28 dest=33:33:ff:4b:be:28 proto=0x86dd > len=78 > AdapterTransmit ??? src=0:ff:2d:4b:be:28 dest=33:33:0:0:0:2 proto=0x86dd > len=70 > AdapterTransmit ??? src=0:ff:2d:4b:be:28 dest=33:33:ff:4b:be:28 proto=0x86dd > len=86 > AdapterTransmit ??? src=0:ff:2d:4b:be:28 dest=33:33:0:0:0:2 proto=0x86dd > len=70 > AdapterTransmit IPv4 UDP[342] BOOTREQUEST DHCPDISCOVER > 0.0.0.0:BOOTPC[0:ff:2d:4b:be:28] -> > 255.255.255.255:BOOTPS[ff:ff:ff:ff:ff:ff] ch=0:ff:2d:4b:be:28 xid=0x00000ae9 > ma=0x00000383 id=0x4451 ttl=128 ic=0xf554 [0x0000] uc=0x75e6 [0x0000/60] > OPT.53.1.1.61.7.1.0.255.45.75.190.40.55.7.1.3.6.15.44.46.47.255.0.0.0.0.0.0. > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 > DHCPMsg IPv4 UDP[304] BOOTREPLY DHCPOFFER 10.8.0.0:BOOTPS[0:ff:2f:4b:be:28] > -> 255.255.255.255:BOOTPC[ff:ff:ff:ff:ff:ff] yi=10.8.0.51 si=10.8.0.0 > ch=0:ff:2d:4b:be:28 xid=0x00000ae9 ma=0x00000300 ttl=16 ic=0x9fc4 [0x0000] > uc=0x311e [0x0000/22] > OPT.53.1.2.54.4.10.8.0.0.51.4.49.0.0.0.1.4.255.255.255.0.255 > > With the last pair repeated 12 times. > > In the short term I modified the client config to use: > > ifconfig 10.8.0.40 255.255.255.0 > ip-win32 ipapi > > Which gets me further but I don't really know what I'm doing, I'm just > hacking around. When those configs are used, I then get the address of > 10.8.0.51. Hmmm. Shouldn't I have gotten .40? The .51 what what I > originally was going to be assigned from DHCP! > > Are you using OpenVPN 2.0 or 2.1 (better to use 2.1 in this regard). Basically if you see repeating cycle of TAP getting BOOTREQUEST/DHCPDISCOVER messages from the DHCP client service and then replying with BOOTREPLY/DHCPOFFER, it means that the DHCP client service is not happy with the DHCPOFFER message which was returned by the TAP driver (or perhaps it didn't receive the message). As far as the OpenVPN configuration is concerned, see the static key howto http://openvpn.net/static.html which includes a very barebones configuration which should be suitable for testing purposes. If you want to test the automatic DHCP negotiation, try using OpenVPN 2.1 and use "topology subnet". Setting the IP/subnet (and other optional attributes) on the TAP adapter is problematic on Windows due to the lack of a direct API call. So the --ip-win32 option allows multiple methods to be tried. --ip-win32 ipapi might work, but it's not clear to me why it used .51 in your case. It would help to see your config files. Also, keep in mind that the IP helper API doesn't have the function we really need which is "Assign IP address, netmask, and other DHCP properties to network adapter". Instead it has a function which "adds" an IP/netmask to an already-configured network adapter. That means that you often end up with the primary IP address being the "autoconfiguration" address, with the one you really wanted assigned as a secondary IP/netmask. Less than optimal, and breaks some apps. That's why --ip-win32 dynamic is the default (which basically tells the TAP adapter to implement its own internal DHCP server). James 

> -----Original Message----- > From: James Yonan [mailto:ji...@yo...]=20 ... > > etc. I believe the object spaces have been unified, and I know you=20 > > can take a socket and pass it to, say WaitForSingleObject=20 > and have it=20 > > work. > They sort of did that with WSAEventSelect -- if there was a way that=20 > WSAEventSelect could be used on the TAP device handle (as well as the=20 > network socket), then that would be another route towards moving away=20 > from overlapped I/O. Upon thinking about your suggestion, I think there are some problems: * SOCKETs that go to select() can be signalled in three different ways: read data available, ready to accept writes, and error (more for WSAEventSelect). Windows handles are either signalled or non-signalled, = so there isn't that breakdown. I think this is internal architecture to Winsock and I don't know if it could be replicated into other systems. = An interesting research project, though. I also noticed that sockets are not handles in CE, so the likelihood of select ever accepting HANDLEs directly is slim to none. There might be = some funky wrapper that could be made, though again there would be research = to do on that. > > the existing event architecture as-is, and I just had to make some=20 > > specialized versions of tun_finalize, queue_read, open, close, etc. > How did you deal with getting socket.c off of overlapped I/O=20 > (or did you=20 > figure out a way that PocketPC can do overlapped I/O?). The latter, mostly. It was a happy confluence of events that: * Winsock implementations are required to support overlapped IO, at = least through the WSA- functions, * you happily were already using the WSA- functions for the waits and = get results, * the WSAEvent in CE is really a native event, and the WSAOVERLAPPED is defined the same as OVERLAPPED So it all fell into place. I had to modify tun to call my emulated overlapped io api, but this wound up being fairly a fairly surgical = (i.e. not gross) change. > > I didn't bother > > doing the same with writes since they always completed immediately=20 > > anyway once handing off to NDIS. > I would worry about assuming this unless the API guarantees it. I've=20 > seen a few cases in the overall development of OpenVPN where assuming=20 > that writes always complete immediately (even when totally=20 > supported by=20 > observed behavior) introduced subtle bugs. I'm curious if you can expound. Subtlety is not a virtue in bugs! I = was going by my interpretation of the existing driver code. It seemed to me = it went like: 1) IRP_MJ_CREATE comes in 2) packet is handed off to NDIS via NdisMEthIndicateReceive and = finished via NdisMEthIndicateReceiveComplete 3) the IoCompleteRequest() finished the IRP under all code paths immediately So it seemed that really it was always completing immediately. And even = if it wasn't, since the next time usermode queues a write it waits for the first to complete (via finalize) so it didn't seem to be a big loss to = leave that call synchronous. NDIS sends the packet up the stack = asynchronously already. > It's probably not essential to support control-c/keyboard=20 > signaling --=20 > this feature is used mostly by developers who run OpenVPN in console=20 > mode. Real-world usage of OpenVPN usually involves running=20 Ah! So I'm the only one to bear the burden! Well, good to know that -- = I hadn't delved that far into the openvpn architecture. Actually, the management interface sounds like it will make the future task of = packaging up a PPC-relevant UI much more easy than I expected, so that's good news indeed. > The driver has quite a bit of instrumentation code to help debug/test=20 > the DHCP handshake. Yes, now I must figure out how to interpret it. Care to take a look at = the output from the driver and/or openvpn? You might can tell me = immediately what it means where it might take me days to figure it out. I'll stick = an excerpt at the bottom of this message. > Nobind is quite an important option, so I'm surprised that CE=20 > wouldn't=20 > support it. If it's really not supported on UDP sockets, it might be=20 > possible to simulate nobind by binding to a dynamic port number (from=20 > 49152 through 65535) and if the bind fails, retry the next=20 > higher value. What clued me in was the docs for WSARecv which explicitly stated that = the socket must be bound, so I suppose that technically it shouldn't work on = NT either, but just does as a 'gift'. Again, I should be able to emulate = the behavior somewhat by binding a port of 0, though for some reason this chooses between 1024 and 5000, as opposed to the high ones. The try-and-repeat you suggest should also work. > > Iftikhar: I updated the source and also I fixed the problem I=20 > > mentioned previously about the driver not handling the=20 > power-off state=20 > > correctly; you can power on and off to heart's content. > > =20 > Is this fix relevant to the 2000/XP version of the driver as=20 > well? If=20 > so, would you mind posting a patch that only addresses this fix? It's not relevant. The stream driver part for CE has some additional = power management stuff. My doing debug file io at that time is apparently = uncool. I removed that and all worked again. The NDIS power management behaves = fine as-is. > Okay, a couple questions for you: >=20 > The 2000/XP version of the driver uses the OemWin2k.inf file and=20 > tapinstall.exe (basically a clone of devcon.exe from the DDK)=20 > to install=20 > and configure the TAP device nodes. What is the PocketPC way=20 > of doing this? Pretty easy: registry keys are set up. If one wishes you can then load = the driver immediately with an ioctl you send to NDIS, or you can soft-reset (sortof like 'restart windows') and it will be loaded automatically. For testing, I made a little app that adds/removes the keys and loads/unloads the driver. In a release situation this can be handled in = the CAB file, and/or little app like the tapinstall.exe you mention. > 2000/XP provides the netsh utility for programmatically configuring=20 > network devices. Does PocketPC have any equivalent utility/API? Yes and no. I'm not familiar with netsh, but understand it to have been created because it is fancier than the sundry other tools and more = amenable to scripting. There is not an equivalent to this for CE. Now, the = stuff like ping, route, ipconfig, etc., do exist. They don't ship with PPC because it doesn't have a console out-of-box anyway. They are findable = on the internet and I have a set which I am using now. Actually I think Microsoft releases the source available -- they're pretty much all a UI = to the IpHelper functions. Which, since you already have those calls in openvpn, it might obviate the necessity for an end user to worry about = them. -Dave PS Oh, regarding output from my DHCP, this is what my windows box says during the last phase of negotiation: Sun Mar 26 17:36:30 2006 us=3D885461 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{0B8E84A0-84E7-46DB-BEE7-C4B0166791E9}.tap Sun Mar 26 17:36:30 2006 us=3D885495 TAP-Win32 Driver Version 8.1=20 Sun Mar 26 17:36:30 2006 us=3D885512 TAP-Win32 MTU=3D1500 Sun Mar 26 17:36:30 2006 us=3D885537 Notified TAP-Win32 driver to set a = DHCP IP/netmask of 10.8.0.50/255.255.255.0 on interface {0B8E84A0-84E7-46DB-BEE7-C4B0166791E9} [DHCP-serv: 10.8.0.0, lease-time: 31536000] Sun Mar 26 17:36:30 2006 us=3D892848 Successful ARP Flush on interface = [5] {0B8E84A0-84E7-46DB-BEE7-C4B0166791E9} Sun Mar 26 17:36:30 2006 us=3D901492 TEST ROUTES: 0/0 succeeded len=3D-1 = ret=3D0 a=3D0 u/d=3Ddown Sun Mar 26 17:36:30 2006 us=3D901537 Route: Waiting for TUN/TAP = interface to come up... Sun Mar 26 17:36:32 2006 us=3D65631 TEST ROUTES: 0/0 succeeded len=3D-1 = ret=3D0 a=3D0 u/d=3Ddown Sun Mar 26 17:36:32 2006 us=3D65678 Route: Waiting for TUN/TAP interface = to come up... Sun Mar 26 17:36:33 2006 us=3D434239 TEST ROUTES: 0/0 succeeded len=3D-1 = ret=3D1 a=3D0 u/d=3Dup Sun Mar 26 17:36:33 2006 us=3D434277 Initialization Sequence Completed And this is what the similar section on the pocket pc says: Mon Mar 27 08:56:29 2006 us=3D47349 TAP-WIN32 device [TAP1:] opened: = TAP1: Mon Mar 27 08:56:29 2006 us=3D48315 TAP-Win32 Driver Version 8.1 (DEBUG) Mon Mar 27 08:56:29 2006 us=3D48978 TAP-Win32 MTU=3D1500 Mon Mar 27 08:56:29 2006 us=3D49755 Notified TAP-Win32 driver to set a = DHCP IP/netmask of 10.8.0.51/255.255.255.0 on interface TAP1: [DHCP-serv: 10.8.0.0, lease-time: 31536000] Mon Mar 27 08:56:29 2006 us=3D51431 Successful ARP Flush on interface = [131074] TAP DEVICE 1 Mon Mar 27 08:56:29 2006 us=3D84761 TEST ROUTES: 0/0 succeeded len=3D-1 = ret=3D0 a=3D0 u/d=3Ddown Mon Mar 27 08:56:29 2006 us=3D85677 Route: Waiting for TUN/TAP interface = to come up... (...12 times...) Mon Mar 27 08:56:58 2006 us=3D389816 Initialization Sequence Completed = With Errors ( see http://openvpn.net/faq.html#dhcpclientserv ) During that activity the driver is spewing out the following debug: [TAP DEVICE 1] Unhandled OID ffffff [TAP DEVICE 1] Unhandled OID 20214 [TAP DEVICE 1] Unhandled OID 20215 [TAP DEVICE 1] Unhandled OID 20215 TAP_Open; dwData =3D 0x00036110, dwAccess =3D 0xc0000000, dwShareMode = =3D 0x00000000; inst =3D 0x00036110 [TAP DEVICE 1] [TAP] release [8.1] open request (m_TapOpens=3D0) AdapterTransmit ??? src=3D0:ff:2d:4b:be:28 dest=3D33:33:ff:4b:be:28 = proto=3D0x86dd len=3D86 AdapterTransmit ??? src=3D0:ff:2d:4b:be:28 dest=3D33:33:0:0:0:2 = proto=3D0x86dd len=3D62 AdapterTransmit ??? src=3D0:ff:2d:4b:be:28 dest=3D33:33:ff:4b:be:28 = proto=3D0x86dd len=3D78 AdapterTransmit ??? src=3D0:ff:2d:4b:be:28 dest=3D33:33:0:0:0:2 = proto=3D0x86dd len=3D70 AdapterTransmit ??? src=3D0:ff:2d:4b:be:28 dest=3D33:33:ff:4b:be:28 = proto=3D0x86dd len=3D86 AdapterTransmit ??? src=3D0:ff:2d:4b:be:28 dest=3D33:33:0:0:0:2 = proto=3D0x86dd len=3D70 AdapterTransmit IPv4 UDP[342] BOOTREQUEST DHCPDISCOVER 0.0.0.0:BOOTPC[0:ff:2d:4b:be:28] -> 255.255.255.255:BOOTPS[ff:ff:ff:ff:ff:ff] ch=3D0:ff:2d:4b:be:28 = xid=3D0x00000ae9 ma=3D0x00000383 id=3D0x4451 ttl=3D128 ic=3D0xf554 [0x0000] uc=3D0x75e6 = [0x0000/60] OPT.53.1.1.61.7.1.0.255.45.75.190.40.55.7.1.3.6.15.44.46.47.255.0.0.0.0.0= .0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 DHCPMsg IPv4 UDP[304] BOOTREPLY DHCPOFFER = 10.8.0.0:BOOTPS[0:ff:2f:4b:be:28] -> 255.255.255.255:BOOTPC[ff:ff:ff:ff:ff:ff] yi=3D10.8.0.51 = si=3D10.8.0.0 ch=3D0:ff:2d:4b:be:28 xid=3D0x00000ae9 ma=3D0x00000300 ttl=3D16 = ic=3D0x9fc4 [0x0000] uc=3D0x311e [0x0000/22] OPT.53.1.2.54.4.10.8.0.0.51.4.49.0.0.0.1.4.255.255.255.0.255 With the last pair repeated 12 times. In the short term I modified the client config to use: ifconfig 10.8.0.40 255.255.255.0 ip-win32 ipapi=20 Which gets me further but I don't really know what I'm doing, I'm just hacking around. When those configs are used, I then get the address of 10.8.0.51. Hmmm. Shouldn't I have gotten .40? The .51 what what I originally was going to be assigned from DHCP! 

Forgot completely about the rtti lib. Sorry about that. Strictly it's = not needed I don't think, but I have a tendency to use exceptions so I = usually put it in without thinking about it. =20 The installation of the driver works like this: =20 * Stick it in \Windows This is the conventional location for such files. CE doesn't have a configurable 'PATH' per se, but that directory is implictly used for = module lookup. * Create the required NDIS keys. You can do that with the TapTester = via the button labelled 'SetupNDISKeys', and you just have to do it once. Eventually, when everything is working, I intend to make a .cab = installer which will do the registry setup. =20 That the basic installation and will make available a device called = TAP1: which is the tap driver. The driver will automatically be loaded upon bootup via soft reset. Also, you can cause it to be loaded immediately (without soft reset) with the TAP tester button labelled = 'RegisterAdapter' =20 =20 How to remove: =20 * mostly for dev, you can unload the driver immediately via the = TapTester button labelled 'DeregisterAdapter'. This is useful for dev/testing because you can't install a newly built driver if one is already loaded. * more important: since the system will load the driver automatically = when you soft reset, it is important to use the 'DeleteNDISKeys' button if = you don't want that to happen. When the keys are deleted, then the system = will not know about the driver and not load it. =20 =20 Quick check that it is loaded: =20 1) There is a button labelled 'SqooshIt' (sorry for the silly name), = that will list all loaded NDIS adapters, you will see the TAP driver if it is loaded. 2) You can drill down through the standard network settings and you = will see an adapter named: 'TAP1: Virtual Ethernet Device' listed along with all the other adapters = on your device. I can't tell you how to get there because they move this around, but on my PPC2003 device, it can be accessed from the network = icon at the top of the screen: settings, advanced, network card, network adapters; and then there is a listbox with the names in it. =20 =20 This should be a drop kick, but I am interested if there is any = lock-down for unsigned drivers on PPC-Phone Edition which is what your PPC-6700 is running I think. I'm interested in SmartPhone, too, but I don't know = anyone with one of those devices to try it out on. Maybe you have a friend? =20 =20 Notes on current status: =20 1 currently, I have hacked forward.c to have the following commented = out around line 1215: if (flags & IOW_WAIT_SIGNAL) wait_signal (c->c2.event_set, (void*)&err_shift); the consequence is that you don't have a means (like ctrl-c) to stop the openvpn app. I have to do this for the moment until I can figure out either: a way to get a real event handle for the console, or a different mechanism altogether to provide the signals thus emulated. So you can terminate it from the control panel, or if you use something like 'magic button' the X button will really close the app (instead of 'smart = minimize', which really just hides it behind the desktop). =20 2 You must not use the 'nobind' option in the client config. =20 3 I haven't figured out why my dhcp is not configuring correctly, = however I have had luck with the 'ip-win32 ipapi' 'ifconfig l rp' options. =20 4 I am a configuration newby to openvpn, and I know my test setup is = not correctly configured. I am using a windows client as my control during experiments. It's not working correctly either, so I know I have = something wrong -- don't know what yet. =20 FWIW, my client config contains: =20 #begin client =20 dev tap dev-node TAP1: =20 proto udp =20 remote 192.168.1.10 1194 #don't like this but work-around until I fix/emulate nobind local 192.168.1.129 =20 #dhcp not working for some reason, this gets past that ip-win32 ipapi #interestingly, I still get a 10.8.0.51 address on the TAP, which is = from the DHCP pool! curious.... ifconfig 10.8.0.40 255.255.255.0 #openssl stuff ca "\\ca.crt" cert "\\ipaq4150.crt" key "\\ipaq4150.key" =20 comp-lzo =20 verb 5 #end =20 though don't take this as a reccomendation, just as a reference point as = to where I am now. =20 =20 FWIW: you may wish to download nettools_arm_setup.exe from somewhere = which will give you the usual network tools like route, ipconfig, netstat, et = al. =20 -Dave =20 =20 -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Iftikhar Qureshi Sent: Monday, March 27, 2006 10:57 AM To: Dave Cc: ope...@li... Subject: RE: [Openvpn-devel] OpenVPN for PocketPC Dave, I got updated code and built TAPTester successfully. I had to get RITTI package for Ccrtrtti.lib. What is the recommended way of installing tap-ce.dll? ...I just copied = it in the same folder as the TAPTester application which worked. Salamz, -IQ Dave <de...@zi...> wrote:=20 ... Iftikhar: I updated the source and also I fixed the problem I mentioned previously about the driver not handling the power-off state correctly; = you can power on and off to heart's content. -Dave 

Dave wrote: >> -----Original Message----- >> From: James Yonan [mailto:ji...@yo...] >> Sent: Sunday, March 26, 2006 3:02 PM >> To: Dave >> Cc: 'Iftikhar Qureshi'; ope...@li... >> Subject: Re: [Openvpn-devel] OpenVPN for PocketPC >> >> >> >>> * I discovered yesterday that in the particular case of >>> >> winsock, that >> >>> overlapped io support is required, and (supposedly) has been >>> implemented in CE and is available via the WSA versions of those >>> methods (e.g. WSAGetOverlappedResult). This is really good news >>> because it possibly means that all the socket.c work will >>> >> not have to >> >>> be reworked at all. Hopefully! >>> >>> So I think that only the five various tun_* and *_tun >>> >> methods need to >> >>> be implemented to declare this 'feature complete' and then the >>> exciting phase of testing/fixing begins. >>> >>> >>> >> The Windows version of OpenVPN currently wants overlapped I/O to be >> supported by the OS. The reason why overlapped I/O was >> originally used >> (rather than unix-style select or poll) is so that the event >> loop could >> treat TAP device events the same as network socket events, and handle >> network and TAP events within a single event loop. >> >> The root of the problem is that Windows supports two incompatible (as >> far as I know) I/O wait event spaces: there is the SOCKET >> type which >> can be used as an argument to select() and then there's the HANDLE >> (returned by CreateEvent) which is used as an argument to >> WaitForSingleObject/WaitForMultipleObjects. Currently the Windows >> version of OpenVPN uses the HANDLE space which unfortunately >> makes the >> I/O code more complex than would be the case under unix. >> >> However if we could figure out a way to allow select() to poll on the >> TAP device handle as well as network sockets, then we could >> do away with >> Windows overlapped I/O -- that would move us into the SOCKET >> event space >> which is much more reasonable to deal with, and compatible with unix >> event I/O semantics (such as select()). >> >> James >> > > It's an interesting idea and worth some thought. The object spaces were > separate for historical reasons (winsock came out when 16-bit was still > quite alive) and hence the duplicated WSAOVERLAPPED, WSAEVENT, etc. I > believe the object spaces have been unified, and I know you can take a > socket and pass it to, say WaitForSingleObject and have it work. They sort of did that with WSAEventSelect -- if there was a way that WSAEventSelect could be used on the TAP device handle (as well as the network socket), then that would be another route towards moving away from overlapped I/O. > Perhaps > the converse is true (take a file handle and pass it to select(), or at > least WSASelect()). This assuming that winsock doesn't strap-on some > private magic to it's socket handles that would be a problem for non-magical > 'other' handles. Also, the driver would have to be coded to signal the > handle appropriately. I think this is doable in NT, however I'm pretty sure > it would be a challenge for CE because you don't have access to your handle > (so what would one signal). > > Agreed it would be tidier to have all the platforms use the simpler select() > mechanism. > > Ultimately, yesterday I gave up the ghost on trying to rework the tap > usermode stuff to work in a polling manner, and wound up implementing the > equivalent of overlapped IO using a custom DeviceIoControl() for the > overlapped Read() and for the CancelIo(). This let me reuse all the > existing event architecture as-is, and I just had to make some specialized > versions of tun_finalize, queue_read, open, close, etc. How did you deal with getting socket.c off of overlapped I/O (or did you figure out a way that PocketPC can do overlapped I/O?). > I didn't bother > doing the same with writes since they always completed immediately anyway > once handing off to NDIS. I would worry about assuming this unless the API guarantees it. I've seen a few cases in the overall development of OpenVPN where assuming that writes always complete immediately (even when totally supported by observed behavior) introduced subtle bugs. > Anyway, this re-unified the event model between > the socket stuff and the tap stuff. > > Your point is timely, however, because my new challenge is similar (though > different): the handle returned from GetStdHandle() is _not_ suitable for > synchronization on CE. The WSAWaitForEvent call barfs with 'invalid > parameter' if it is in the event set. Eventually I figured out it was the > console handle so at the moment I have that commented-out until I can think > of a suitable solution. I'll probably have to dig in the PortLib code, but > the console driver itself is not open-source, so it might be a chore > resolving that issue. > It's probably not essential to support control-c/keyboard signaling -- this feature is used mostly by developers who run OpenVPN in console mode. Real-world usage of OpenVPN usually involves running OpenVPN as a service and using the management interface (manage.c) to control the OpenVPN process from a GUI via a TCP socket. > With that commented-out, I can't ctrl-c to stop the application, but I can > start to initiate a session with the server. Now things run happily until I > get to the point where DHCP is happening and then it fails to get an IP > address from the server. Hopefully something configuration related, but, > well, probably not -- probably a bug I introduced and will have to > find-and-fix (sigh). > The driver has quite a bit of instrumentation code to help debug/test the DHCP handshake. > Question for you: I discovered today that 'nobind' can't be used on CE. > The socket has to go through bind() before it can be used in, say WSARecv. > Is there an especial reason why someone would be upset about not having that > option supported? I haven't tried, but I might be able to emulate it by > binding to ADDR_ANY:0. Maybe. > Nobind is quite an important option, so I'm surprised that CE wouldn't support it. If it's really not supported on UDP sockets, it might be possible to simulate nobind by binding to a dynamic port number (from 49152 through 65535) and if the bind fails, retry the next higher value. > Iftikhar: I updated the source and also I fixed the problem I mentioned > previously about the driver not handling the power-off state correctly; you > can power on and off to heart's content. > Is this fix relevant to the 2000/XP version of the driver as well? If so, would you mind posting a patch that only addresses this fix? Okay, a couple questions for you: The 2000/XP version of the driver uses the OemWin2k.inf file and tapinstall.exe (basically a clone of devcon.exe from the DDK) to install and configure the TAP device nodes. What is the PocketPC way of doing this? 2000/XP provides the netsh utility for programmatically configuring network devices. Does PocketPC have any equivalent utility/API? Thanks, James 

Dave, I got updated code and built TAPTester successfully. I had to get RITTI package for Ccrtrtti.lib. What is the recommended way of installing tap-ce.dll? ...I just copied it in the same folder as the TAPTester application which worked. Salamz, -IQ Dave <de...@zi...> wrote:... Iftikhar: I updated the source and also I fixed the problem I mentioned previously about the driver not handling the power-off state correctly; you can power on and off to heart's content. -Dave 

> -----Original Message----- > From: James Yonan [mailto:ji...@yo...]=20 > Sent: Sunday, March 26, 2006 3:02 PM > To: Dave > Cc: 'Iftikhar Qureshi'; ope...@li... > Subject: Re: [Openvpn-devel] OpenVPN for PocketPC >=20 >=20 > > > > * I discovered yesterday that in the particular case of=20 > winsock, that=20 > > overlapped io support is required, and (supposedly) has been=20 > > implemented in CE and is available via the WSA versions of those=20 > > methods (e.g. WSAGetOverlappedResult). This is really good news=20 > > because it possibly means that all the socket.c work will=20 > not have to=20 > > be reworked at all. Hopefully! > > > > So I think that only the five various tun_* and *_tun=20 > methods need to=20 > > be implemented to declare this 'feature complete' and then the=20 > > exciting phase of testing/fixing begins. > > > > =20 > The Windows version of OpenVPN currently wants overlapped I/O to be=20 > supported by the OS. The reason why overlapped I/O was=20 > originally used=20 > (rather than unix-style select or poll) is so that the event=20 > loop could=20 > treat TAP device events the same as network socket events, and handle=20 > network and TAP events within a single event loop. >=20 > The root of the problem is that Windows supports two incompatible (as=20 > far as I know) I/O wait event spaces: there is the SOCKET=20 > type which=20 > can be used as an argument to select() and then there's the HANDLE=20 > (returned by CreateEvent) which is used as an argument to=20 > WaitForSingleObject/WaitForMultipleObjects. Currently the Windows=20 > version of OpenVPN uses the HANDLE space which unfortunately=20 > makes the=20 > I/O code more complex than would be the case under unix. >=20 > However if we could figure out a way to allow select() to poll on the=20 > TAP device handle as well as network sockets, then we could=20 > do away with=20 > Windows overlapped I/O -- that would move us into the SOCKET=20 > event space=20 > which is much more reasonable to deal with, and compatible with unix=20 > event I/O semantics (such as select()). >=20 > James =20 It's an interesting idea and worth some thought. The object spaces were separate for historical reasons (winsock came out when 16-bit was still quite alive) and hence the duplicated WSAOVERLAPPED, WSAEVENT, etc. I believe the object spaces have been unified, and I know you can take a socket and pass it to, say WaitForSingleObject and have it work. = Perhaps the converse is true (take a file handle and pass it to select(), or at least WSASelect()). This assuming that winsock doesn't strap-on some private magic to it's socket handles that would be a problem for = non-magical 'other' handles. Also, the driver would have to be coded to signal the handle appropriately. I think this is doable in NT, however I'm pretty = sure it would be a challenge for CE because you don't have access to your = handle (so what would one signal). Agreed it would be tidier to have all the platforms use the simpler = select() mechanism. Ultimately, yesterday I gave up the ghost on trying to rework the tap usermode stuff to work in a polling manner, and wound up implementing = the equivalent of overlapped IO using a custom DeviceIoControl() for the overlapped Read() and for the CancelIo(). This let me reuse all the existing event architecture as-is, and I just had to make some = specialized versions of tun_finalize, queue_read, open, close, etc. I didn't bother doing the same with writes since they always completed immediately = anyway once handing off to NDIS. Anyway, this re-unified the event model = between the socket stuff and the tap stuff. Your point is timely, however, because my new challenge is similar = (though different): the handle returned from GetStdHandle() is _not_ suitable = for synchronization on CE. The WSAWaitForEvent call barfs with 'invalid parameter' if it is in the event set. Eventually I figured out it was = the console handle so at the moment I have that commented-out until I can = think of a suitable solution. I'll probably have to dig in the PortLib code, = but the console driver itself is not open-source, so it might be a chore resolving that issue. With that commented-out, I can't ctrl-c to stop the application, but I = can start to initiate a session with the server. Now things run happily = until I get to the point where DHCP is happening and then it fails to get an IP address from the server. Hopefully something configuration related, = but, well, probably not -- probably a bug I introduced and will have to find-and-fix (sigh). Question for you: I discovered today that 'nobind' can't be used on CE. The socket has to go through bind() before it can be used in, say = WSARecv. Is there an especial reason why someone would be upset about not having = that option supported? I haven't tried, but I might be able to emulate it by binding to ADDR_ANY:0. Maybe. Iftikhar: I updated the source and also I fixed the problem I mentioned previously about the driver not handling the power-off state correctly; = you can power on and off to heart's content. -Dave 

> > * I discovered yesterday that in the particular case of winsock, that > overlapped io support is required, and (supposedly) has been implemented in > CE and is available via the WSA versions of those methods (e.g. > WSAGetOverlappedResult). This is really good news because it possibly means > that all the socket.c work will not have to be reworked at all. Hopefully! > > So I think that only the five various tun_* and *_tun methods need to be > implemented to declare this 'feature complete' and then the exciting phase > of testing/fixing begins. > > The Windows version of OpenVPN currently wants overlapped I/O to be supported by the OS. The reason why overlapped I/O was originally used (rather than unix-style select or poll) is so that the event loop could treat TAP device events the same as network socket events, and handle network and TAP events within a single event loop. The root of the problem is that Windows supports two incompatible (as far as I know) I/O wait event spaces: there is the SOCKET type which can be used as an argument to select() and then there's the HANDLE (returned by CreateEvent) which is used as an argument to WaitForSingleObject/WaitForMultipleObjects. Currently the Windows version of OpenVPN uses the HANDLE space which unfortunately makes the I/O code more complex than would be the case under unix. However if we could figure out a way to allow select() to poll on the TAP device handle as well as network sockets, then we could do away with Windows overlapped I/O -- that would move us into the SOCKET event space which is much more reasonable to deal with, and compatible with unix event I/O semantics (such as select()). James 

-----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Iftikhar Qureshi Sent: Friday, March 24, 2006 2:42 PM To: ope...@li... Subject: [Openvpn-devel] PocketPC - Compile Error Dave: I tried to Rebuild and getting an error. ... =20 OK, I found the dependency and eliminated it. It was just a couple = ioctl() code definitions for loading and unloading the NDIS driver that were = needed. That project should build fine now without the Platform Builder = installed. Also, I checked that the same was true of the main openvpn project, and = it is. The driver currently still required some headers from the Platform Builder. I included pre-built binaries of the driver in all = configurations. =20 -Dave 

-----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Iftikhar Qureshi Sent: Friday, March 24, 2006 2:42 PM To: ope...@li... Subject: [Openvpn-devel] PocketPC - Compile Error ...=20 c:\program files\windows ce tools\wce420\pocket pc 2003\include\armv4\ntcompat.h(1236) : fatal error C1083: Cannot open = include file: 'lss.h': No such file or directory ...=20 =20 Iftikhar, =20 I took a peek and that file lss.h is part of the 'Platform Builder'. Actually, I don't know what hoisted it into that project. Parts of the platform builder are needed for the TAP driver, but it shouldn't be = needed at all for any of the user-mode parts. I'll try and see if I can find = where the dependency came in, and how to remove it. =20 -Dave 

I'm using OpenVPN 2.0.5 with OpenSSL built against PRNGD on Solaris 8 (sparc). On startup, I always got "ERROR: Random number generator cannot obtain entro <<openvpn-2.0.5-initprng.patch>> py for PRNG". I fixed it with the attached patch. =20 

Dave: I tried to Rebuild and getting an error. Active Configuration: TAPTester - Debug Active Platform: Pocket PC 2003 c:\program files\windows ce tools\wce420\pocket pc 2003\include\armv4\ntcompat.h(1236) : fatal error C1083: Cannot open include file: 'lss.h': No such file or directory I'm still looking into this - just wanted to check with you if you might have seen this before. Salamz, -IQ PS: I couldn't send to the OpenVPN list earlier. Hope it go thorugh this time. 

I am using: keepalive 10 60 resolv-retry infinite Yet, frequently the connection dies, and is not reestablished until I manually restart the client (udp client/server). The server is on dhcp and does change ip - I don't know if this is part of the problem - but shouldn't the client keep trying to re-resolve the name and restart the connection? It doesn't seem to. This is : openvpn-2.1-0.7.beta11.fc5 

Dave- I've downloaded the files from the link you sent me and configured the project according to recommended directory structure. Now I'm going through the source code. I've picked up the changed source code as well (unless you changed the file name). Unable to compile yet as I've not yet resolved all the dependencies. And BTW I ended up using PPC 2003 SDK :) Salamz, -IQ PS: Device I'm using is PPC-6700 Dave <de...@zi...> wrote: > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] On Behalf Of Dave > Sent: Wednesday, March 22, 2006 8:30 AM > To: 'Iftikhar Qureshi'; ope...@li... > Subject: RE: [Openvpn-devel] OpenVPN for PocketPC Iftikhar; I updated the source at the web location I previously sent you in case you want to pick it up. Here's a brief summary of what I've fixed/extended since last time: * I figured out my dynamic driver load/unload problem; it was a bug I introduced in one of the ANSI/UNICODE functions that had the effect of truncating the adapter name stored internally in NDIS. Curious that it worked in the emulator anyway... * I implemented several of the functions in tun.c (currently residing wince_tun.c) and sifted away some that were win32-specific ones. * I discovered yesterday that in the particular case of winsock, that overlapped io support is required, and (supposedly) has been implemented in CE and is available via the WSA versions of those methods (e.g. WSAGetOverlappedResult). This is really good news because it possibly means that all the socket.c work will not have to be reworked at all. Hopefully! So I think that only the five various tun_* and *_tun methods need to be implemented to declare this 'feature complete' and then the exciting phase of testing/fixing begins. -Dave 

> -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...] On Behalf Of Dave > Sent: Wednesday, March 22, 2006 8:30 AM > To: 'Iftikhar Qureshi'; ope...@li... > Subject: RE: [Openvpn-devel] OpenVPN for PocketPC Iftikhar; I updated the source at the web location I previously sent you in case = you want to pick it up. Here's a brief summary of what I've fixed/extended since last time: * I figured out my dynamic driver load/unload problem; it was a bug I introduced in one of the ANSI/UNICODE functions that had the effect of truncating the adapter name stored internally in NDIS. Curious that it worked in the emulator anyway... * I implemented several of the functions in tun.c (currently residing wince_tun.c) and sifted away some that were win32-specific ones. * I discovered yesterday that in the particular case of winsock, that overlapped io support is required, and (supposedly) has been implemented = in CE and is available via the WSA versions of those methods (e.g. WSAGetOverlappedResult). This is really good news because it possibly = means that all the socket.c work will not have to be reworked at all. = Hopefully! So I think that only the five various tun_* and *_tun methods need to be implemented to declare this 'feature complete' and then the exciting = phase of testing/fixing begins. -Dave 

Iftikhar; I should be able to send to you an archive with the modified source for = the PocketPC port of the openvpn (once I find a suitable ftp; the email is unhappy with the size). Brief summary of modifications to source thus far: TAP driver in tap-win32 directory: dhcp.c	trivial change to avoid compiler warning error.c	modification to spew debug to text file in debug build lrror.h	prototype change to avoid compiler warning lock.h	CE doesn't have IRQLs; compensate design macinfo.c	alternative random MAC generation prototypes.h	altered parameters for CreateTapDevice types.h	modified 'extension' structure for CE-relevant things tapdvr.c	support CE ;) resource.h tap-ce.rc tap-ce.ico tap-ce.vcp tap-ce.def tap-ce.cpp tap-ce.h	added OpenVPN user-mode application in main directory: config-win32.h	config mods and inclusion of portstuff cryptoapi.h	include config-win32.h for some portability defs win32.c	mods incomplete* tun.c	include breakout wince_tun.c, incomplete** wince_tun.c	breakout of CE-specific tun stuff** wince_portstuff.h, .c	implementation of some APIs not otherwise present * in win32.c, a method get_console_input_win32() needs to be = implemented. ** the user-mode side of the tun stuff has not been done; the = implementation in wince_tun.c is just cut/paste from the same-named methods in tun.c so that compilation will happen. TBD: I discovered a couple days ago that all the socket IO uses the = overlapped io method. So all the stuff in socket.c/h will have to be reworked as = well, in addition to the stuff in tun.c. I am hoping that doing an = implementation of socket.c that is closer to the unix configuration (where there isn't overlapped io) will work. Also, there is a minor method in win32.c that needs implementation. It involves console io, and since the SymbolicTools PortLib is being used = at the moment to provide console support, I suspect that documentation in = such can provide guidance. To install the tap driver you need to set up some registry keys. In the interest of concision, here are those keys in regedit format: REGEDIT4 [HKEY_LOCAL_MACHINE\Comm\TAP Device] "ImagePath"=3D"tap-ce.dll" "Group"=3D"NDIS" "DisplayName"=3D"TAP user-mode ethernet device" [HKEY_LOCAL_MACHINE\Comm\TAP Device\Linkage] "Route"=3Dhex(7):\ 54,41,50,20,44,65,76,69,63,65,31,00,00,00,00 [HKEY_LOCAL_MACHINE\Comm\TAP Device1] "ImagePath"=3D"tap-ce.dll" "Group"=3D"NDIS" "DisplayName"=3D"TAP user-mode ethernet device" [HKEY_LOCAL_MACHINE\Comm\TAP Device1\Parms] "StreamIndex"=3Ddword:00000001 "StreamName"=3D"TAP" "BusType"=3Ddword:00000000 "BusNumber"=3Ddword:00000000 If you install these keys, and have the driver named tap-ce.dll and = placed in the \Windows directory, then the driver will be loaded upon start = (you can do soft-reset after copying the files and installing the keys to stimulate the load). Also, to uninstall the driver you can remove the = keys or the dll and soft-reset again. There is an API to load and unload the driver on-the-fly. It works = great in the emulator but doesn't work on any of my real devices. It's via IOCTL_NDIS_REGISTER_ADAPTER. If you can get that to work on a real = device please let me know. It fails in interesting ways. First, when loading = the driver it fails and returns 'parameter error'. However, it did really = load the driver and the driver is running happily. Second, when unloading = the driver, it returns 'success', however it really did _not_ unload the = driver and you will still have to soft-reset (after removing the registry keys) = to truly unload it. Odd! I notice the reference counts did not drop appropriately in that second scenario. -Dave 

Hey, anybody interested in porting OpenVPN to OSF1/Tru64? I've prepared a tap driver for it[1], so at least layer 2 tunneling should work. The driver's behaviour is mostly the same as the *BSD ones (although it's not a port of either of them). It was tested on Digital UNIX V4.0B running on a DEC 3000, and seems to work quite nicely. [1] http://innoidea.com/~vili/osf1_tap.tar.gz -vili 

I'll send a package to you later tonight or possibly tomorrow depending = on how other things I'm doing work out. =20 Good that you have a WM5 device since I don't have one of those to test with. Wish I had a smartphone too. I'd using PPC2003 and SE. =20 Regarding targeting WM5, I seem to recall that they changed the whole ActiveSync protocol in WM5 and I wonder if that might be the source of = your troubles. You definitely should be able to build a PPC2003-targeted app = and have it run on WM5, but I don't know if you'll still run into troubles connecting to the WM5 device for debugging purposes. DevStudio 2005 is supposed to be able to target WM5 specifically, but it is not even = slightly free, alas. =20 Brief status update: =20 * I unit tested all the 'portability' functions I had to implement to = get user-mode to build, so that's out of the way. I discovered yesterday, though, that there will be some significant work to do in two places: = the tun.c which is the interface to the driver, which I expected, but also = all of the stuff in socket.c will have to be visited as well. I didn't = expect that, but all the socket IO is using overlapped IO also, which we don't = have in CE. I'm hoping that we can deal with this by making an = implementation that is more patterned after the unix socket io, which of course = definitely is not 'overlapped' and then just accomodate the few BSD-WSA = discrepancies. =20 Since I have been hacking on the code a bit to get it to compile, I am = going to send you: =20 * the libs and headers for the openssl and lzo like we talked about * a zip of my source tree with modifications I have made thus far * a brief description of non-obvious configuration; e.g. I have my 3rd party libs in a location relative to my projects that gets picked up via settings in the eVC project =20 I have marked all the spots I have hacked-on with the comment //HHH for = ease of searching. You're free of course also to use diff. =20 Talk to you later; you're help will be greatly appreciated! =20 -Dave -----Original Message----- From: Iftikhar Qureshi [mailto:ift...@ya...]=20 Sent: Monday, March 20, 2006 11:30 AM To: Dave; ope...@li... Subject: RE: [Openvpn-devel] OpenVPN for PocketPC Please do send the binaries/headers. I'll start testing and will give = you an update. You may send it to my email id. =20 I'm having a bit of difficulity making eVC4 target my WM5.0 device - so still working on that. =20 Salamz, -IQ Dave <de...@zi...> wrote: Well, a lot of the discovery work at least. Currently I'm testing the routines I added for porting the user-mode stuff. I've tested most of those. Also, if it's useful, I can send you prebuilt binaries and headers for = the openssl and lzo. That way at least you don't have to mess with that. Or you might wish to build them anyway as a sanity check on your setup. -Dave 

Please do send the binaries/headers. I'll start testing and will give you an update. You may send it to my email id. I'm having a bit of difficulity making eVC4 target my WM5.0 device - so still working on that. Salamz, -IQ Dave <de...@zi...> wrote: Well, a lot of the discovery work at least. Currently I'm testing the routines I added for porting the user-mode stuff. I've tested most of those. Also, if it's useful, I can send you prebuilt binaries and headers for the openssl and lzo. That way at least you don't have to mess with that. Or you might wish to build them anyway as a sanity check on your setup. -Dave 

>-----Original Message----- >From: ope...@li... [mailto:ope...@li...] On Behalf Of Iftikhar Qureshi >Sent: Friday, March 17, 2006 3:41 PM >To: Dave; ope...@li... >Subject: RE: [Openvpn-devel] OpenVPN for PocketPC > > >Dave, > >Thanks for all the information. Looks like you've taken care of all the hard work :) > >Okay, I'll try to build the development environment on my machine so = that I can do some testing/development. Meanwhile if you want me to do some = testing do let me know. You may write me directly as well. > >I'll bug you again as soon as I have all required tools/APIs :) > >Salamz, >-IQ Well, a lot of the discovery work at least. Currently I'm testing the routines I added for porting the user-mode stuff. I've tested most of those. Also, if it's useful, I can send you prebuilt binaries and headers for = the openssl and lzo. That way at least you don't have to mess with that. = Or you might wish to build them anyway as a sanity check on your setup. -Dave 

Dave, Thanks for all the information. Looks like you've taken care of all the hard work :) Okay, I'll try to build the development environment on my machine so that I can do some testing/development. Meanwhile if you want me to do some testing do let me know. You may write me directly as well. I'll bug you again as soon as I have all required tools/APIs :) Salamz, -IQ Dave <de...@zi...> wrote: