Re: extra/pptp-conntrack-nat.patch

Re: extra/pptp-conntrack-nat.patch

[Friedrich Lobenstock]

Hi!

Jeff Hall wrote:
> I found the following discussion on the www.sonicwall.com/support site.
> It may explain the mystery of the broken/not-broken check sums.
> 
> Jeff Hall
> 
> SonicWALL: In certain circumstances, a Windows 2000 PC cannot use PPTP to
> access another node on the opposite side of the SonicWall. The issue
> appears to be caused by how certain checksums are calculated differently
> depending on whether this function is performed by the OS itself or if it
> is off-loaded to the ethernet NIC. 
> To work around the issue, you must make sure the OS is allowed to perform
> the checksum calculations, not the ethernet NIC. This can be done by
> following these steps: 
> Right-click the 'My Network Places' desktop icon and select 'Properties'. 
> Right-click on the icon for your ethernet NIC and select 'Properties'. 
> Click on the 'Configure' button. 
> Click on the 'Advanced' tab. 
> Disable the Rx and Tx Checksum Offload options for the card.
> This problem is known to occur with the following: 
> OS: Windows 2000 with service pack 1 
> Ethernet NIC: 3Com 905/920 series ethernet controller. 

May I recall that I really have to remove the // to get it running.

/* track caller id inside control connection, call expect_related */
static int
conntrack_pptp_help(const struct iphdr *iph, size_t len,
                     struct ip_conntrack *ct, enum ip_conntrack_info ctinfo)

{ ...

         /* checksum invalid? */
         if (tcp_v4_check(tcph, tcplen, iph->saddr, iph->daddr,
                         csum_partial((char *) tcph, tcplen, 0))) {
                 printk(KERN_NOTICE __FILE__ ": bad csum\n");
//             return NF_ACCEPT;
         }

If I take a look at the cvs version of the patch there's a comment
above the // line that says that w2k servers send out false csums.

So do I understand this correct that if I remove the //, the pptp
contrack module actually is more RFC conform than before? Or is
it just the other way round?

-- 
MfG / Regards
Friedrich Lobenstock

Re: extra/pptp-conntrack-nat.patch

[Jeff Hall]

On Thu, 10 Apr 2003, Friedrich Lobenstock wrote:

  > Hi!
  > 
  > Jeff Hall wrote:
  > > I found the following discussion on the www.sonicwall.com/support site.
  > > It may explain the mystery of the broken/not-broken check sums.
  > > 
  > > Jeff Hall
  > > 
  > > SonicWALL: In certain circumstances, a Windows 2000 PC cannot use PPTP to
  > > access another node on the opposite side of the SonicWall. The issue
  > > appears to be caused by how certain checksums are calculated differently
  > > depending on whether this function is performed by the OS itself or if it
  > > is off-loaded to the ethernet NIC. 
  > > To work around the issue, you must make sure the OS is allowed to perform
  > > the checksum calculations, not the ethernet NIC. This can be done by
  > > following these steps: 
  > > Right-click the 'My Network Places' desktop icon and select 'Properties'. 
  > > Right-click on the icon for your ethernet NIC and select 'Properties'. 
  > > Click on the 'Configure' button. 
  > > Click on the 'Advanced' tab. 
  > > Disable the Rx and Tx Checksum Offload options for the card.
  > > This problem is known to occur with the following: 
  > > OS: Windows 2000 with service pack 1 
  > > Ethernet NIC: 3Com 905/920 series ethernet controller. 
  > 
  > May I recall that I really have to remove the // to get it running.
  > 
  > /* track caller id inside control connection, call expect_related */
  > static int
  > conntrack_pptp_help(const struct iphdr *iph, size_t len,
  >                      struct ip_conntrack *ct, enum ip_conntrack_info ctinfo)
  > 
  > { ...
  > 
  >          /* checksum invalid? */
  >          if (tcp_v4_check(tcph, tcplen, iph->saddr, iph->daddr,
  >                          csum_partial((char *) tcph, tcplen, 0))) {
  >                  printk(KERN_NOTICE __FILE__ ": bad csum\n");
  > //             return NF_ACCEPT;
  >          }
  > 
  > If I take a look at the cvs version of the patch there's a comment
  > above the // line that says that w2k servers send out false csums.
  > 
  > So do I understand this correct that if I remove the //, the pptp
  > contrack module actually is more RFC conform than before? Or is
  > it just the other way round?
If you remove the comment and include the line "return NF_ACCEPT", then any
packet with an invalid checksum is NOT processed by the PPTP helper function.
With the line commented out the incorrect checksum is ignored and the packet
is processed by the rest of the PPTP helper function. Why this solved your
problem I can't say.
  > 
  > -- 
  > MfG / Regards
  > Friedrich Lobenstock
  > 
  > 
  > 
  > 

Re: extra/pptp-conntrack-nat.patch

[Friedrich Lobenstock]

Jeff Hall wrote:
> On Thu, 10 Apr 2003, Friedrich Lobenstock wrote:
>> May I recall that I really have to remove the // to get it running.
>> 
>> /* track caller id inside control connection, call expect_related */
>> static int
>> conntrack_pptp_help(const struct iphdr *iph, size_t len,
>>                      struct ip_conntrack *ct, enum ip_conntrack_info ctinfo)
>> 
>> { ...
>> 
>>          /* checksum invalid? */
>>          if (tcp_v4_check(tcph, tcplen, iph->saddr, iph->daddr,
>>                          csum_partial((char *) tcph, tcplen, 0))) {
>>                  printk(KERN_NOTICE __FILE__ ": bad csum\n");
>> //             return NF_ACCEPT;
>>          }
>> 
>> If I take a look at the cvs version of the patch there's a comment
>> above the // line that says that w2k servers send out false csums.
>> 
>> So do I understand this correct that if I remove the //, the pptp
>> contrack module actually is more RFC conform than before? Or is
>> it just the other way round? 
>
> If you remove the comment and include the line "return NF_ACCEPT", then any
> packet with an invalid checksum is NOT processed by the PPTP helper function.
> With the line commented out the incorrect checksum is ignored and the packet
> is processed by the rest of the PPTP helper function. Why this solved your
> problem I can't say.

I don't know either. Because of this I ask the author of this module to
make this an option to the module, so I do not have to create two different
versions of devil linux to support both possibilities.

-- 
MfG / Regards
Friedrich Lobenstock

Re: extra/pptp-conntrack-nat.patch

[Ilguiz Latypov]

On Fri, 11 Apr 2003, Friedrich Lobenstock wrote:

> > If you remove the comment and include the line "return NF_ACCEPT",
> > then any packet with an invalid checksum is NOT processed by the PPTP
> > helper function. With the line commented out the incorrect checksum is
> > ignored and the packet is processed by the rest of the PPTP helper
> > function. Why this solved your problem I can't say.
>
> I don't know either. Because of this I ask the author of this module to
> make this an option to the module, so I do not have to create two
> different versions of devil linux to support both possibilities.

Are you connecting to the Windows server from the Linux machine where PPTP
connection tracking modules are loaded?

If this is true, you would be affected by the modules' rewriting of call
IDs in one direction only when you were running the unmodified version.

To be able to connect from such Linux machine to another PPTP server, you
need to apply the pending local NAT patch from the netfilter patch-o-matic
and enable the CONFIG_NF_NAT_LOCAL option in the kernel.

There would be nothing Windows specific in this case.

Correct me if I am wrong.

--
Ilguiz Latypov
Net Integration Technologies, Inc

tel. +1 (514) 281 9191 x 117

Re: extra/pptp-conntrack-nat.patch

[Friedrich Lobenstock]

Ilguiz Latypov wrote:
> 
> Are you connecting to the Windows server from the Linux machine where PPTP
> connection tracking modules are loaded?

No. It looks like this:

Windows-PC ---------> Linux Firewall --------------> Windows Server
  PPTP-Client           connection tracking             PPTP-Server
  private IP        private          official
                      IP                IP

> If this is true, you would be affected by the modules' rewriting of call
> IDs in one direction only when you were running the unmodified version.

I don't see a connection to a bad checksum here?

> 
> To be able to connect from such Linux machine to another PPTP server, you
> need to apply the pending local NAT patch from the netfilter patch-o-matic
> and enable the CONFIG_NF_NAT_LOCAL option in the kernel.
> 
> There would be nothing Windows specific in this case.

I don't think that I need the local nat stuff, do I?

PS: Can I tell the runme script of patch-o-matic to list all applied
patches? As far as I know it only shows the applied patches when you
tell it to apply some patches, but I can not export this list to a file.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl@fl.priv.at
____________________________________________________________________

Re: extra/pptp-conntrack-nat.patch

[Martin Josefsson]

On Fri, 2003-04-11 at 18:40, Friedrich Lobenstock wrote:

> PS: Can I tell the runme script of patch-o-matic to list all applied
> patches? As far as I know it only shows the applied patches when you
> tell it to apply some patches, but I can not export this list to a file.

This feature is missing, I might add it if I get bored enough (I've
already spent quite some time digging through it and fixing/adding
stuff)

-- 
/Martin

Re: extra/pptp-conntrack-nat.patch

[Martin Josefsson]

On Fri, 2003-04-11 at 19:00, Martin Josefsson wrote:
> On Fri, 2003-04-11 at 18:40, Friedrich Lobenstock wrote:
> 
> > PS: Can I tell the runme script of patch-o-matic to list all applied
> > patches? As far as I know it only shows the applied patches when you
> > tell it to apply some patches, but I can not export this list to a file.
> 
> This feature is missing, I might add it if I get bored enough (I've
> already spent quite some time digging through it and fixing/adding
> stuff)

It's not missing anymore :)

./runme --check extra

that checks all patches in submitted pending base and extra and at the
end it writes the results to a file called runme.out-check

-- 
/Martin

Re: extra/pptp-conntrack-nat.patch

[Friedrich Lobenstock]

Martin Josefsson wrote:
> On Fri, 2003-04-11 at 19:00, Martin Josefsson wrote:
> 
>>On Fri, 2003-04-11 at 18:40, Friedrich Lobenstock wrote:
>>
>>
>>>PS: Can I tell the runme script of patch-o-matic to list all applied
>>>patches? As far as I know it only shows the applied patches when you
>>>tell it to apply some patches, but I can not export this list to a file.
>>
>>This feature is missing, I might add it if I get bored enough (I've
>>already spent quite some time digging through it and fixing/adding
>>stuff)
> 
> It's not missing anymore :)
> 
> ./runme --check extra
> 
> that checks all patches in submitted pending base and extra and at the
> end it writes the results to a file called runme.out-check

Great, thanks !!

-- 
MfG / Regards
Friedrich Lobenstock

Re: extra/pptp-conntrack-nat.patch

[Ilguiz Latypov]

Friedrich,

On Fri, 11 Apr 2003, Friedrich Lobenstock wrote:

> > If this is true, you would be affected by the modules' rewriting of call
> > IDs in one direction only when you were running the unmodified version.
>
> I don't see a connection to a bad checksum here?

If you were connecting from the Linux NAT box itself without the local NAT
option, then the unmodified connection tracking modules would keep your
connection tracked yet not rewrite the call ID's in replies.

Changing the module to not track bad checksum connections would "fix" the
above issue by relying on bad TCP checksums.

But I understand that this wasn't your case.

The following chart represents my understanding of the PPTP tracking
modules capabilities in their current state.  I assumed that uncommenting
the "return NF_ACCEPT" statement in question is equivalent to not tracking
a connection with bad TCP checksum.

One can see from that chart that not tracking bad checksum connections
will only benefit the "no local NAT support, connection from the NAT box,
bad checksum"  scenario.  On the other hand, in case of connections from
behind the NAT box, the suggested change will prevent from more than one
bad checksum connection at a time.

The current decision to keep that statement commented means the latter
case casualty outweighed the advantages of the former case in the author's
mind.

I don't understand how the change helped you in the latter case while
theoretically it should only make things worse there.

Thanks,

--
Ilguiz Latypov
Net Integration Technologies, Inc

tel. +1 (514) 281 9191 x 117


                                 connection from       connection from
                               behind the NAT box    the NAT box itself

                               good TCP   bad TCP     good TCP   bad TCP
                               checksum   checksum    checksum   checksum


      no PPTP modules             1          1           +          +


   unmodified PPTP modules        +          +           -          -
 without the local NAT option

   unmodified PPTP modules        +          +           +          +
  with the local NAT option

 uncommented "return NF_ACCEPT"
    for bad TCP checksums         +          1           -          +
 without the local NAT option

 uncommented "return NF_ACCEPT"
    for bad TCP checksums         +          1           +          +
  with the local NAT option


------------------
+: Any number of connections of given class is treated correctly.
-: No connection possible.
1: Only one connection at a time will work in these cases.  If this refers
   to the "behind the NAT box" connections, no connections from the NAT
   box itself should be allowed for this to work.

Re: extra/pptp-conntrack-nat.patch

[Friedrich Lobenstock]

Hello!

Ilguiz Latypov wrote:
> 
> The following chart represents my understanding of the PPTP tracking
> modules capabilities in their current state.  I assumed that uncommenting
> the "return NF_ACCEPT" statement in question is equivalent to not tracking
> a connection with bad TCP checksum. [....]
> 
>                                  connection from       connection from
>                                behind the NAT box    the NAT box itself
> 
>                                good TCP   bad TCP     good TCP   bad TCP
>                                checksum   checksum    checksum   checksum
> 
> 
>       no PPTP modules             1          1           +          +

For connections from behind the NAT box I can not confirm this.

> 
> 
>    unmodified PPTP modules        +          +           -          -
>  without the local NAT option
> 
>    unmodified PPTP modules        +          +           +          +
>   with the local NAT option
> 
>  uncommented "return NF_ACCEPT"
>     for bad TCP checksums         +          1           -          +
>  without the local NAT option
> 
>  uncommented "return NF_ACCEPT"
>     for bad TCP checksums         +          1           +          +
>   with the local NAT option
> 
> 
> ------------------
> +: Any number of connections of given class is treated correctly.
> -: No connection possible.
> 1: Only one connection at a time will work in these cases.  If this refers
>    to the "behind the NAT box" connections, no connections from the NAT
>    box itself should be allowed for this to work.
> 

As the local nat patch is not in patch-o-matic-20030107 did not
get applied to my kernel, but for me that's irrelevant, as I don't
currently use pptp from the linux maschine itself.

-- 
MfG / Regards
Friedrich Lobenstock

Re: extra/pptp-conntrack-nat.patch

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Mon, Mar 31, 2003 at 02:21:08PM +0200, Friedrich Lobenstock wrote:
> Hi!
> 
> Regarding your patch
>   http://cvs.netfilter.org/~checkout~/netfilter/patch-o-matic//extra/pptp-conntrack-nat.patch
> 
> 
> May I suggest that you make this a configurable option, because
> I had this "bad csum" problem and therefor had to remove the '//'
> in front of the 'return NF_ACCEPT;'

actually, _with_ the '//' in front, it accepts packets with broken
checksums.  If you remove the '//' in front, it will not consider
packets with broken checksums.

So W2k should work with the shipped patch ! (IIRC, it works in both
cases)

> -- 
> MfG / Regards
> Friedrich Lobenstock

-- 
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: extra/pptp-conntrack-nat.patch

[Friedrich Lobenstock]

Harald Welte wrote:
> 
> actually, _with_ the '//' in front, it accepts packets with broken
> checksums.  If you remove the '//' in front, it will not consider
> packets with broken checksums.
> 
> So W2k should work with the shipped patch ! (IIRC, it works in both
> cases)
> 

So I conclude that there is not a W2k at the other side (I missinterpreted
the comment ion the patch the other way round) because I needed to remove
the '//' to get it working. But when I ask the people what they've got
as PPTP-Server they tell me it's a W2k server.

I'm using the patch that's in pom-20030107. Could that make a difference?

As a side note, I do the following:
  PPTP-Client --> Devil-Linux-Firewall -->...Internet....--> PPTP-Server

At least it works now but it looks like a mistery now.

-- 
MfG / Regards
Friedrich Lobenstock

Re: extra/pptp-conntrack-nat.patch

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Mon, Mar 31, 2003 at 02:44:57PM +0200, Friedrich Lobenstock wrote:
> Harald Welte wrote:
> >
> >actually, _with_ the '//' in front, it accepts packets with broken
> >checksums.  If you remove the '//' in front, it will not consider
> >packets with broken checksums.
> >
> >So W2k should work with the shipped patch ! (IIRC, it works in both
> >cases)
> >
> 
> So I conclude that there is not a W2k at the other side (I missinterpreted
> the comment ion the patch the other way round) because I needed to remove
> the '//' to get it working. But when I ask the people what they've got
> as PPTP-Server they tell me it's a W2k server.
>
> At least it works now but it looks like a mistery now.

indeed. can anybody else on the mailinglist confirm this observation?

> Friedrich Lobenstock

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: extra/pptp-conntrack-nat.patch

[Friedrich Lobenstock]

Hi!

Harald Welte wrote:
> On Mon, Mar 31, 2003 at 02:44:57PM +0200, Friedrich Lobenstock wrote:
>>So I conclude that there is not a W2k at the other side (I missinterpreted
>>the comment ion the patch the other way round) because I needed to remove
>>the '//' to get it working. But when I ask the people what they've got
>>as PPTP-Server they tell me it's a W2k server.
>>
>>At least it works now but it looks like a mistery now.
> 
> 
> indeed. can anybody else on the mailinglist confirm this observation?
> 

So what do you think of making this a module option?
eg.
   modprobe ip_conntrack_pptp braindead_w2k=[0|1]
or
   modprobe ip_conntrack_pptp accept_bad_csum=[0|1]

-- 
MfG / Regards
Friedrich Lobenstock