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

Subject: Re: MTU
From: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Date: Thu, 10 Apr 2003 23:08:05 +0200
In-reply-to: <006d01c2ff94$ee80db20$1f0016ac@eng.timetra.com>

I've been here before, but I never addressed the preemption issues by 
encapsulating the critical portion with KeRaiseIrql, preventing the 
preemption in that code block. That's probably the best solution without 
ripping the code apart completely.

DKW

On Thursday 10 April 2003 04:11 pm, you wrote:
> Hi Damion,
>
> I think I've found a problem. The CIPE driver's queues can become
> corrupted, possibly when tap device IRP_MJ_READs (which seem to run at
> IRQL < DISPATCH_LEVEL) are preempted by calls to AdapterTransmit (which
> seem to run at IRQL = DISPATCH_LEVEL). After this has happened, the
> queue count permanently disagrees with the state of the pointers in the
> linked list. I've wrapped the code that handles IRP_MJ_READs with calls
> to KeRaiseIrql (DISPATCH_LEVEL,&oldirlq) and KeLowerIrql (oldirql). I
> haven't seen the problem since. I know this area has been discussed at
> length before, but I'd be interested in any feedback you may have.
>
> Thanks,
>
> Michael.
>
> -----Original Message-----
> From: Damion Wilson [mailto:dwilson,AT,ibl,DOT,bm
> Sent: 08 April 2003 17:11
> To: Michael Clarke
> Subject: Re: MTU
>
> Thanks, that seems like something that could eat up a lot of time
>
> DKW
>
> On Tuesday 08 April 2003 12:37 pm, you wrote:
> > Hi Damion,
> >
> > The MTU fix is a partial solution to a problem that I'm still
> > investigating. I'm using Windows 2000 Server, which may or may not be
> > relevant to my problem.
> >
> > Although not optimal, things should still work with the existing MTU;
> > long UDP frames sent from the CIPE service should be fragmented by
> > Windows before being sent across the internet (provided any NAT
>
> gateways
>
> > along the way track IP fragments properly, which most do). However, in
> > my setup, after a while, something fails and Windows starts
>
> transmitting
>
> > only the first fragment of any long frames that the CIPE service tries
> > to send. This was my main motivation for reducing the MTU. I guess
>
> other
>
> > people are finding it useful because they have broken NAT gateways.
> >
> > Although the change improved things for me, things still seem to
> > eventually fail. I get two remaining failure modes. One is where
>
> frames
>
> > received from the NDIS layer are delayed, possibly in the queues
>
> managed
>
> > by AdapaterTransmit in cipdrvr/cipdrvr.c, although I haven't proved
>
> that
>
> > it isn't in the NDIS driver itself yet. Frames are delayed until
>
> another
>
> > packet arrives, at which point I see the CIPE service reading the
>
> first
>
> > packet from the driver. Once it's in this mode, things stay one packet
> > behind where they should be. The second failure mode is less frequent
> > and I haven't traced it as far, but frame forwarding stops and the
> > service needs to be restarted. I'll let you know if I find out that
> > CIPE's at fault!
> >
> > Michael.
> >
> > -----Original Message-----
> > From: Damion Wilson [mailto:dwilson,AT,ibl,DOT,bm
> > Sent: 08 April 2003 15:39
> > To: Michael Clarke
> > Subject: Re: MTU
> >
> > Ahh, I knew it would be something like that ! I'm not really
> > specifically
> > concerned about adding extra includes to the modules, but, with the
>
> SDK
>
> > &
> > DDK, there are different values assign to macros depending on what
>
> order
>
> > the
> > includes are done ! So after getting it "right" I avoid changing the
> > include
> > setup like the plague.
> >
> > I promise to get your MTU mods in there soon. I'm just setting up to
>
> do
>
> > those
> > changes to cipsrvr that I've discussed on the list and that'll be a
> > fairly
> > major piece of work
> >
> > DKW
> >
> > On Tuesday 08 April 2003 11:23 am, you wrote:
> > > Hi Damion,
> > >
> > > Oops, got it, it's the Platform SDK that causes the problem - it
> > > contains different versions of the windows headers to those shipped
> >
> > with
> >
> > > MSVC6.0, making the build sensitive to the order of the include
> > > directories. I have noticed other people on the mailing list falling
> >
> > for
> >
> > > this, so I guess I'm not the only one.
> > >
> > > I checked the sample drivers in the DDK and they include winioctl.h
>
> in
>
> > > their user mode apps to get their IOCTL defines, although I guess
>
> they
>
> > > don't require the use of the Platform SDK as CIPE does.
> > >
> > > Thanks,
> > >
> > > Michael.
> > >
> > > -----Original Message-----
> > > From: Damion Wilson [mailto:dwilson,AT,ibl,DOT,bm
> > > Sent: 08 April 2003 14:44
> > > To: Michael Clarke
> > > Subject: Re: MTU
> > >
> > > You shouldn't need to add that include to CipeTapIO.cpp. I'm
>
> building
>
> > > with
> > > both Win2K DDK and NT4 DDK. Something else may be missing or
> > > unconfigured in
> > > your SDK setup.
> > >
> > > DKW
> > >
> > > On Tuesday 08 April 2003 08:22 am, Michael Clarke wrote:
> > > > Hi Tom,
> > > >
> > > > You need the Windows DDK as well as MSVS to build the CIPE driver.
> > > > Compiling the CIPE service also seems to require DDK headers. I
> >
> > fixed
> >
> > > > this by adding #include "winioctl.h" to cipsrvr/CipeTapIO.cpp.
> > > >
> > > > I think you are having problems because NFS uses UDP packets. My
>
> fix
>
> > > > should work. I'll send the binary off-list.
> > > >
> > > > Michael.
> > > >
> > > > -----Original Message-----
> > > > From: Tom Parker [mailto:tparker,AT,netspace,DOT,net,DOT,au
> > > > Sent: 08 April 2003 12:09
> > > > To: Michael Clarke
> > > > Cc: cipe-l,AT,inka,DOT,de
> > > > Subject: RE: MTU
> > > >
> > > > Michael,
> > > >
> > > > I'm not sure what I need to build cipe-win32 (I've got both cygwin
> >
> > and
> >
> > > > vs6.0, but it seems like I need something else).
> > > >
> > > > To save me the hassle can you email your binary to me.  I'm having
> > > > trouble
> > > > with MTU too - I'm trying to boot my NFS based mp3 player and the
> > > > packets
> > > > are getting scrambled because of MTU issues (it is sending 1498
>
> byte
>
> > > > packets
> > > > despite the registry being set for 1442).
> > > >
> > > > Thanks heaps,
> > > > Tom
> > > >
> > > > ----------------------------------
> > > > Tom Parker tparker,AT,netspace,DOT,net,DOT,au
> > > > http://www.wiresncode.com/projects
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-cipe-l,AT,inka,DOT,de 
> > > > > [mailto:owner-cipe-l,AT,inka,DOT,de
>
> Behalf
>
> > Of
> >
> > > > > Damion Wilson
> > > > > Sent: Tuesday, 1 April 2003 1:48 AM
> > > > > To: Michael Clarke
> > > > > Cc: cipe-l,AT,inka,DOT,de
> > > > > Subject: Re: MTU
> > > > >
> > > > >
> > > > > Yes, that helps a lot !
> > > > >
> > > > > DKW
> > > > >
> > > > > On Monday 31 March 2003 11:14 am, you wrote:
> > > > > > Hi Damion et al,
> > > > > >
> > > > > > I've been looking at the MTU problem myself over the past few
> > >
> > > days.
> > >
> > > > The
> > > >
> > > > > > way I fixed it was to modify the CIPE tap driver to advertise
>
> a
>
> > > > lower
> > > >
> > > > > > transmit MTU. Currently the driver advertises a transmit MTU
>
> of
>
> > > > 1486, 14
> > > >
> > > > > > bytes less than the 1500 bytes advertised by a normal Ethernet
> > > >
> > > > driver.
> > > >
> > > > > > I've lowered it to 1459 (see derivation below) and now any
> > > >
> > > > fragmentation
> > > >
> > > > > > is performed before the CIPE service sees the packets. This
> >
> > might
> >
> > > be
> > >
> > > > > > superior to changing the TCP MTU using the registry fixes as
>
> it
>
> > > > covers
> > > >
> > > > > > UDP frames too - ping -l 2000 frames are now fragmented before
> > >
> > > being
> > >
> > > > > > encrypted.
> > > > > >
> > > > > > In cipdrvr/cipdrvr.c(590):
> > > > > >         case OID_GEN_MAXIMUM_FRAME_SIZE:
> > > > > >         case OID_GEN_TRANSMIT_BLOCK_SIZE:
> > > > > >         case OID_GEN_TRANSMIT_BUFFER_SPACE:
> > > > > >            l_Query.m_Long = DEFAULT_PACKET_LOOKAHEAD - // 1500
> > > > > >                             20 - // IP header
> > > > > >                             8 -  // UDP header
> > > > > >                             8 -  // IV
> > > > > >                             1 -  // 'P' byte
> > > > > >                             4;   // CIPE CRC
> > > > > >
> > > > > > Hope this helps,
> > > > > >
> > > > > > Michael.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-cipe-l,AT,inka,DOT,de 
> > > > > > [mailto:owner-cipe-l,AT,inka,DOT,de On
> >
> > Behalf
> >
> > > > Of
> > > >
> > > > > > Mark Cooke
> > > > > > Sent: 31 March 2003 15:48
> > > > > > To: Damion Wilson
> > > > > > Cc: cipe-l,AT,inka,DOT,de
> > > > > > Subject: Re: MTU
> > > > > >
> > > > > > Hi Damion,
> > > > > >
> > > > > > In this particular case, it would have saved me a few minutes
> > > >
> > > > digging
> > > >
> > > > > > around trying to work out how to set an MTU, so having it as
>
> an
>
> > > > option
> > > >
> > > > > > in the control panel/next generation setup program would get
>
> my
>
> > > > vote.
> > > >
> > > > > > Thanks for the efforts you make with cipe on windows. It has
> >
> > been
> >
> > > > > > exceedingly helpful here - avoiding the need to try to force
> > >
> > > windows
> > >
> > > > and
> > > >
> > > > > > freeswan to co-exist.
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > > On Mon, 2003-03-31 at 15:26, Damion Wilson wrote:
> > > > > > > Would it help if there was a per adapter MTU option in the
> > > >
> > > > settings ?
> > > >
> > > > > > > DKW
> > > > > > >
> > > > > > > On Monday 31 March 2003 08:19 am, Phil wrote:
> > > > > > > > On Mon, 2003-03-31 at 13:06, Mark Cooke wrote:
> > > > > > > > > Hi Phil,
> > > > > > > > >
> > > > > > > > > I had an issue with MTU, and I manually changed the
> > >
> > > CIPE-Win32
> > >
> > > > MTU
> > > >
> > > > > > to
> > > > > >
> > > > > > > > > 1442 by changing the registry, on the windows end of a
> > > >
> > > > linux-win32
> > > >
> > > > > > cipe
> > > > > >
> > > > > > > > > link.[*]
> > > > > > > > >
> > > > > > > > > This cured a problem I was having where small packets,
> >
> > like
> >
> > > > imap
> > > >
> > > > > > checks
> > > > > >
> > > > > > > > > for new mail, would make it over the encrypted link, but
> > >
> > > bulk
> > >
> > > > > > transfers
> > > > > >
> > > > > > > > > such as actually grabbing the new messages, would fail.
> > > > > > > > >
> > > > > > > > > This was on XP.
> > > > > > > > >
> > > > > > > > > Note, I also set the service to manual, because even
>
> with
>
> > > the
> > >
> > > > > > latest
> > > > > >
> > > > > > > > > dependancy registry mods, on (my install of) XP, the
> >
> > machine
> >
> > > > still
> > > >
> > > > > > > > > pauses for ~ 2 minutes during startup, logging DWK
>
> failed
>
> > to
> >
> > > > > > start, and
> > > > > >
> > > > > > > > > then a terminated unexpectedly, before finally starting
> >
> > up.
> >
> > > I
> > >
> > > > > > just
> > > > > >
> > > > > > > > > added a key to the 'Run' part of the registry, so the
> > >
> > > service
> > >
> > > > is
> > > >
> > > > > > started
> > > > > >
> > > > > > > > > on login.[#]  It means I have to login before the CIPE
> >
> > link
> >
> > > > comes
> > > >
> > > > > > up,
> > > > > >
> > > > > > > > > but that isn't too big a deal in my situation.
> > > > > > > > >
> > > > > > > > > With both the above, CIPE runs very well over my 802.11b
> > >
> > > link,
> > >
> > > > so
> > > >
> > > > > > I was
> > > > > >
> > > > > > > > > able to switch off WEP (which isn't secure anyway).  I
> > >
> > > should
> > >
> > > > just
> > > >
> > > > > > note
> > > > > >
> > > > > > > > > I've had a couple of blue screens since installing CIPE.
> > > > > > > > >
> > > > > > > > > YMMV,
> > > > > > > > >
> > > > > > > > > Mark
> > > > > > > > >
> > > > > > > > > [*]  I added an MTU dword key to the right interface in
> >
> > HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{}
> >
> > > > > > > > > [#] HKLM\Software\Microsoft\Windows\CurrentVersion\Run,
> > >
> > > added
> > >
> > > > a
> > > >
> > > > > > string,
> > > > > >
> > > > > > > > > "C:\windows\system32\cipsrvr.exe" -start
> > > > > > > > >
> > > > > > > > > On Mon, 2003-03-31 at 09:55, Phil wrote:
> > > > > > > > > > hi,
> > > > > > > > > >
> > > > > > > > > > I'd like to konwo if it is ok that my cipcb0's MTU is
> >
> > 1442
> >
> > > ?
> > >
> > > > if
> > > >
> > > > > > I use a
> > > > > >
> > > > > > > > > > windows 2000 client and a cipe linux server, can I
>
> have
>
> > a
> >
> > > > > > problem with
> > > > > >
> > > > > > > > > > MTU?
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > >
> > > > > > > > > > Phil
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> > > > > > > > > > Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe
> >
> > cipe-l"
> >
> > > in
> > >
> > > > > > body
> > > > > >
> > > > > > > > > > Other commands available with "help" in body to the
>
> same
>
> > > > > > address.
> > > > > >
> > > > > > > > > > CIPE info and list archive:
> > > > > > > > > > <URL:http://sites.inka.de/~bigred/devel/cipe.html>
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Mark Cooke <mpc,AT,star,DOT,sr,DOT,bham,DOT,ac,DOT,uk>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> > > > > > > > > Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe
>
> cipe-l"
>
> > in
> >
> > > > body
> > > >
> > > > > > > > > Other commands available with "help" in body to the same
> > > >
> > > > address.
> > > >
> > > > > > > > > CIPE info and list archive:
> > > > > > > > > <URL:http://sites.inka.de/~bigred/devel/cipe.html>
> > > > > > > >
> > > > > > > > thx for your answer Mark. My VPN is ok with 2 Linux
> > >
> > > (yeaaahhhh!
> > >
> > > > > > Linux's
> > > > > >
> > > > > > > > POWER) but It doesn't work with Linux <-> windows 200
> > > >
> > > > Cipe-Win32.
> > > >
> > > > > > I'll
> > > > > >
> > > > > > > > try to modify Windows's MTU.
> > > > > > > > thx for your help.
> > > > > > >
> > > > > > > --
> > > > > > > Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> > > > > > > Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe 
> > > > > > > cipe-l" in
> > >
> > > body
> > >
> > > > > > > Other commands available with "help" in body to the same
> > >
> > > address.
> > >
> > > > > > > CIPE info and list archive:
> > > > > >
> > > > > > <URL:http://sites.inka.de/~bigred/devel/cipe.html>
> > > > >
> > > > > --
> > > > > Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> > > > > Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in
>
> body
>
> > > > > Other commands available with "help" in body to the same
>
> address.
>
> > > > > CIPE info and list archive:
> > > > > <URL:http://sites.inka.de/~bigred/devel/cipe.html>





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