<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: question...
From: Scott Herscher <scott,AT,swampwolf,DOT,com>
Date: Mon, 8 Apr 2002 19:12:20 +0200
In-reply-to: <20020406222423.AAA7129@stormy.ibl.bm@there>

This is what I've learned:

1) The binary distribution does *not* seem to work on XP.  There might be
more than one problem with it, but the initial troubles I had were assigning
an IP address to the CIPE adapter.  It hung when I hit the OK button.  After
starting it again, it had the address I typed in, but apparently it didn't
totally "have" it, as my new adapter did not show up in the route command.
Why this is happening, I don't know.

2) The adapter has the same behavior under XP as under 2k regarding
uninstall.  Both bring the machine down hard.  I have an interesting tidbit
here, however.  I have two 2k machines.  Uninstalling the CIPE adapter works
on one of them.  The only difference between the two machines is that they
have different service packs installed on them.  The "good" machine (the
machine where CIPE uninstalls) does not have any service packs installed!
The other machine has the latest service pack (SP5? SP6?  I can't remember
off the top of my head).  While it doesn't really help pinpoint the problem,
I think the trouble is something that was introduced as part of those
service packs.

3) I don't think the uninstall problem has anything to do with tap devices
or cipsrvr talking to a device that's not there.  The problem occurs if you
freshly install CIPE and then subsequently uninstall it, without even
running the CIPE control panel applet to create a new tunnel.  At that
point, the CIPE server isn't even running.

I'm starting to get to work debugging it right now...I'll let you know what
I find.


On 4/6/02 2:23 PM, "Damion Wilson" <dwilson,AT,ibl,DOT,bm> wrote:

> That's great !
> I don't have XP. My information came from others on the mailing list.
> I want you to try the distributed binaries. I don't want to start having
> different binary distributions for different Windows versions unless I 
> have to. If there are things that have to be fixed, then I'll fix them in 
> source code.
> What's your thinking on the driver unload issue ? I found a bug two weeks 
> where I wasn't removing the symbolic link for the TAP device. There may be
> more issues around having the service communicating with a non-existent TAP
> device that has no driver.
> On Friday 05 April 2002 07:52 pm, you wrote:
>> Hey there Damion...as I'm typing this, I've got my Win2k box talking to a
>> remote CIPE gateway running WinXP.  Everything seems to be working great.
>> I was anticipating great horror, but it works.  Matter of fact, we were
>> just running a little VNC session back and forth.  Am I missing something
>> (again)?  I thought there were problems running on XP. The only thing that
>> might have made a difference is that I recompiled all the source code on
>> the XP host.  I used Visual Studio 6.0 and the new Windows DDK.  Lemme know
>> if you want me to send you the products of the build so you can post'em on
>> your site.  Had to change a few things to get it to build, but they were
>> relatively minor (header file inclusions and the like).
>> Oh yea...still working on the uninstall problem...hopefully will have that
>> fixed early next week, but we'll see what we shall see.
>> Scotto
>> On 4/4/02 9:28 AM, "Damion Wilson" <dwilson,AT,ibl,DOT,bm> wrote:
>>> BTW, Have you tried tracing a CIPE driver load on WinXP yet ?
>>> DKW
>>> On Thursday 04 April 2002 12:04 pm, you wrote:
>>>> I like the way you think!  To be honest, I can probably help you more
>>>> programmatically than any other way, but you never know what might
>>>> happen!
>>>> Take care,
>>>> Scotto
>>>> On 4/4/02 5:45 AM, "Damion Wilson" <dwilson,AT,ibl,DOT,bm> wrote:
>>>>> Weeelll. Now that you mention it, CIPE-Win32 could use a nice HTML user
>>>>> manual...
>>>>> DKW
>>>>> On Thursday 04 April 2002 03:24 am, you wrote:
>>>>>> Whew!!!  Thank you very much.  I'm now able to ping to the private
>>>>>> network. I've noticed that you made mention of the uninstall of the
>>>>>> driver problem, which I'm also experiencing.  I'm going to attempt to
>>>>>> fix that in the next couple of days, as well as port to XP.  Thanks
>>>>>> again for the help...I hope I can return the favor, you know?
>>>>>> Scotto
>>>>>> On 4/3/02 5:35 PM, "Damion Wilson" <dwilson,AT,ibl,DOT,bm> wrote:
>>>>>>> I'm not sure where you went with this one but I believe you may be
>>>>>>> chasing a red herring here.
>>>>>>> Occasionally TCPIP.SYS will send ARP requests to the CIPE devices
>>>>>>> about CIPE peers because we've tricked it into believing that the
>>>>>>> CIPE adapter is Ethernet. We answer the requests with made up ARP
>>>>>>> replies faking a MAC address for the peer in question. No UDP data
>>>>>>> transfer happens for this.
>>>>>>> Successful IP traffic requires that all hosts "know the way" so to
>>>>>>> speak to the other networks. This information can be done with RIP,
>>>>>>> OSPF, etc routing protocols or static routes and default gateways.
>>>>>>> In the network
>>>>>>> A <==> G1 <==> G2 <==> B
>>>>>>> A host on network B must have G2 as its default router or, at least,
>>>>>>> an entry in its routing table saying that the network A is reachable
>>>>>>> via G2. Likewise, a host on network A must have G2 as its router for
>>>>>>> network B. G1 must have an entry describing G2 as the gateway for B
>>>>>>> and G2 must have an entry for G1 as the gateway for A. Without this
>>>>>>> information, a packet can make it halfway, a quarter of the way or
>>>>>>> three quarters of the way and then stop.
>>>>>>> You must also turn on IP forwarding for Windows NT/2000 for all of
>>>>>>> this to work if G1 and/or G2 are Windows machines.
>>>>>>> Treat the CIPE adapters as Ethernet adapters and things should work
>>>>>>> out. Send me a drawing of your network layout with the addresses and
>>>>>>> netmasks and I'll see if anything pops out, but I think that
>>>>>>> debugging the driver/service is not the place to start.
>>>>>>> DKW
>>>>>>> On Wednesday 03 April 2002 08:05 pm, you wrote:
>>>>>>>> Hi Damion!!!  I'm sorry to keep bugging you, but I'm a little
>>>>>>>> confused about something, and I'm hoping you can clear it up.
>>>>>>>> While I have successfully gotten CIPE running to where two CIPE
>>>>>>>> gateway machines can ping each other, I haven't been as successful
>>>>>>>> in pinging machines "behind" the CIPE gateway.  I thought this just
>>>>>>>> entailed some modifications to the routing tables, but in looking at
>>>>>>>> the code, I'm now thoroughly confused.
>>>>>>>> The CipeTapIO class seems to be responsible for reading from the tap
>>>>>>>> device. Thus all traffic that you want to be shipped over the
>>>>>>>> internet to the other side of the tunnel should be written to the
>>>>>>>> tap device. The CipeTapIO class reads it off the adapter and then
>>>>>>>> calls Send on an instance of a
>>>>>>>> CipeSocketIO class.  Now when I'm tracing a ping to a machine on the
>>>>>>>> other guy's network, this is what I'm seeing.
>>>>>>>> 1) It gets sent to the tap device, because I configured the routing
>>>>>>>> tables to do this (route add mask
>>>>>>>>, where the foreign network is at and my
>>>>>>>> CIPE PTP address is  I can see this is true, because I
>>>>>>>> added debug statements to the the cipdrvr device driver and could
>>>>>>>> see them print out using DebugView.
>>>>>>>> 2) The CipeTapIO successfully reads off the tap device, but in
>>>>>>>> CipeTapIO::CompleteAsyncReceive, it gets lost because
>>>>>>>> if (IsArpRequest(m_Buffer) is true, but l_socketIO.Address() ==
>>>>>>>> m_Buffer.arp.DestinationIP() is NOT true.
>>>>>>>> So my question is: if I'm pinging some machine behind the CIPE
>>>>>>>> gateway, the preceding will never work, because the arp
>>>>>>>> DestinationIP will be some other address.  Thus it will never hit
>>>>>>>> the code that actually sends packets across to the other side.
>>>>>>>> What am I missing here?  I'm thinking it has to be something to do
>>>>>>>> with how I set up the routing tables, but I'm at a loss to explain
>>>>>>>> it. It seems like for the code to work, the DestinationIP has to be
>>>>>>>> my peer's PTP address, but how could it be that if I'm not pinging
>>>>>>>> that guy, but I'm pinging a machine on his LAN???
>>>>>>>> Any help would be greatly appreciated!!!
>>>>>>>> Thanks Damion,
>>>>>>>> Scott
>>>>>>>> -----------------------------------------------------------
>>>>>>>> Scott Herscher                  Swampwolf Technologies, Inc.
>>>>>>>> scott,AT,swampwolf,DOT,com       315 South Coast Hwy, #U96
>>>>>>>> Tel/Fax: 877.822.3969    Encinitas, CA  92024
>>>>>>>> -----------------------------------------------------------
>>>>>>>> On 4/2/02 7:14 AM, "Damion Wilson" <dwilson,AT,ibl,DOT,bm> wrote:
>>>>>>>>> Yeah, it's probably a bug. The actual pattern of use only causes
>>>>>>>>> invocation of GetMgrHandle() to happen once but there is a
>>>>>>>>> programming "hole" here. There should be a test of both class
>>>>>>>>> handle variables to ensure that they are non-null before attempting
>>>>>>>>> to assign them.
>>>>>>>>> I'm glad you're having fun playing with it. Right now, we're at the
>>>>>>>>> stage of ironing out the last bugs keeping it from being
>>>>>>>>> "production quality".
>>>>>>>>> DKW
>>>>>>>>> On Monday 01 April 2002 09:27 pm, you wrote:
>>>>>>>>>> Yea, multithreading can be a pain in the butt, I'll give ya that.
>>>>>>>>>> I've written a bunch of networking software on windows, and I'd
>>>>>>>>>> never used overlapped I/0...I've always used multithreading,
>>>>>>>>>> that's why I was curious.
>>>>>>>>>> Another question...I've been stepping through the code, and I
>>>>>>>>>> noticed that in CipeServiceBase::OpenSvcHandle, the first line
>>>>>>>>>> calls OpenMgrHandle(). That's cool, except OpenSvcHandle seems to
>>>>>>>>>> be called multiple times, and the handle that is created from
>>>>>>>>>> OpenMgrHandle isn't closed each time.  Is it cool to do this?
>>>>>>>>>> It's always hard to look at foreign code, so I'm probably missing
>>>>>>>>>> something.  Just though I'd check.
>>>>>>>>>> Thanks again Damion for your help.  I'm really excited to get CIPE
>>>>>>>>>> working on my machine.  I'm having some problems, but I'm learning
>>>>>>>>>> alot too, so it's all good!!!
>>>>>>>>>> Take care,
>>>>>>>>>> Scotto
>>>>>>>>>> On 3/29/02 6:57 AM, "Damion Wilson" <dwilson,AT,ibl,DOT,bm> wrote:
>>>>>>>>>>> Multiple threads are a pain in the ass mostly for what you get
>>>>>>>>>>> (with structure locks and all). The Unix way (single threaded
>>>>>>>>>>> with a select()) is the best I have worked with but Windows isn't
>>>>>>>>>>> efficient that way and there isn't a way to mix WSAAsyncSelect
>>>>>>>>>>> with non socket file handles (for TAP devices). The reason that
>>>>>>>>>>> Microsoft advises writing things multithreaded is because
>>>>>>>>>>> creating and destroying processes is VERY expensive on NT. So,
>>>>>>>>>>> for them, using threads gets the performance vis a vis multiple
>>>>>>>>>>> connections.
>>>>>>>>>>> I suppose that I could have made a thread for each adapter/TAP
>>>>>>>>>>> pairing but I don't /didn't see a case for any better performance
>>>>>>>>>>> while there was a clear case for a service which would be
>>>>>>>>>>> difficult to debug. Believe me, I have a production program that
>>>>>>>>>>> uses both Overlapped I/O and multiple sockets and threading to
>>>>>>>>>>> deal with a vendor library that doesn't export its socket
>>>>>>>>>>> connection, forcing me instead to use a blocking API function.
>>>>>>>>>>> Debugging the program may have cost an extra 2 man-days to date
>>>>>>>>>>> over a program that only took 1 man-week to write simply.
>>>>>>>>>>> In any case, the Overlapped I/O itself uses system threads to
>>>>>>>>>>> accomplish its "business" so, since the program spends most of
>>>>>>>>>>> its time waiting for I/O operations to be completed
>>>>>>>>>>> asynchronously, events get serviced in a very timely manner.
>>>>>>>>>>> DKW
>>>>>>>>>>> On Friday 29 March 2002 03:34 am, you wrote:
>>>>>>>>>>>> thanks!  appreciate the help.  quick question though.  the one
>>>>>>>>>>>> process you're talking about is the cipesvr?  I haven't looked
>>>>>>>>>>>> at it closely, but I'm assuming it's single threaded if you
>>>>>>>>>>>> chose to use Overlapped I/O.  If this is true, why didn't you
>>>>>>>>>>>> make it multi-threaded?  What I mean is one interface per
>>>>>>>>>>>> thread.  Would there have been resource contention issues that
>>>>>>>>>>>> would have been difficult to manage?  Just kinda curious is all.
>>>>>>>>>>>> Thanks again,
>>>>>>>>>>>> Scotto
>>>>>>>>>>>> On 3/28/02 3:07 PM, "Damion Wilson" <dwilson,AT,ibl,DOT,bm> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> The driver is specifically NOT tied to CIPE. It merely
>>>>>>>>>>>>> implements pseudo-Ethernet devices tied to serial TAP devices.
>>>>>>>>>>>>> The registry entries and symbol names will have "DKW" and "VPN"
>>>>>>>>>>>>> and "CIPE" in them but there's really no reason you couldn't
>>>>>>>>>>>>> change them and they don't affect the processing in any way.
>>>>>>>>>>>>> You will probably have to explore my usermode class hierarchy
>>>>>>>>>>>>> to see what kind of operations you'll have to implement in the
>>>>>>>>>>>>> usermode
>>>>>>>>>>>>> service/consoleapp.
>>>>>>>>>>>>> I'm sorry, but the only real documentation is the code itself
>>>>>>>>>>>>> :-) You should get a copy of the NT/Win2K DDK which has all the
>>>>>>>>>>>>> help that you need ;-) but there still appear to be no books on
>>>>>>>>>>>>> writing NDIS drivers. The usermode stuff is reasonably well
>>>>>>>>>>>>> laid out. The only tricky bit is the Overlapped I/O stuff which
>>>>>>>>>>>>> I do because I manage all the active CIPE interfaces with a
>>>>>>>>>>>>> single process. If you chose to manage one interface per
>>>>>>>>>>>>> process then you wouldn't necessarily have to do it that way.
>>>>>>>>>>>>> Technically, all you need once the driver is installed and
>>>>>>>>>>>>> working and you have instantiated an interface is to open the
>>>>>>>>>>>>> associated TAP device for reading and writing. packets that try
>>>>>>>>>>>>> to leave the machine via that interface will get sent to the
>>>>>>>>>>>>> TAP (and to your program). Writes to the TAP will appear as
>>>>>>>>>>>>> arriving packets on the associated interface. You are
>>>>>>>>>>>>> responsible for ensuring that the packets are proper Ethernet
>>>>>>>>>>>>> packets, though.
>>>>>>>>>>>>> Also, check out the IOCtl's used to access/control MAC
>>>>>>>>>>>>> information.
>>>>>>>>>>>>> Hope that helps,
>>>>>>>>>>>>> DKW
>>>>>>>>>>>>> On Thursday 28 March 2002 06:57 pm, you wrote:
>>>>>>>>>>>>>> Hi there!  I'm interested in implementing a homebrew tunneling
>>>>>>>>>>>>>> scheme, and I'm interested in saving myself work as much as
>>>>>>>>>>>>>> possible.  My question for you is this:  can I reuse the work
>>>>>>>>>>>>>> you've done on the NDIS driver for CIPE in my own work?
>>>>>>>>>>>>>> Technically, how much of your work is tightly bound to CIPE?
>>>>>>>>>>>>>> If it is indeed reusable, would you be able to give me a few
>>>>>>>>>>>>>> pointers as to how I should go about reusing it? Or point me
>>>>>>>>>>>>>> to a document that might describe this?
>>>>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>>>>> Scott

<< | Thread Index | >> ]    [ << | Date Index | >> ]