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

Subject: RE: MTU
From: "Michael Clarke" <mclarke,AT,timetra,DOT,com>
Date: Thu, 10 Apr 2003 21:49:35 +0200
In-reply-to: <200304081311.07126.dwilson@ibl.bm>

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 | >> ]