Problem with SCPS & connection tracking

When I have connection tracking enabled in the kernel and use the
Space Communications Protocol Standard (SCPS), which is a protocol to
speed up TCP over satellite, I can no longer start a video call using
Polycom ViewStationFX. Using Wireshark, I see the "Connect" message
is being dropped. At the same time, I see "nf_ct_q931: packet
dropped" being printed to /var/log/messages. This happens because
nf_ct_expect_related returns -EBUSY since expect_clash does not return
zero. Without SCPS, the call works fine with connection tracking
enabled.

Why does expect_clash return nonzero? What is the "clash" it is
looking for and is there any reason that SCPS would cause such a
clash? Is there any known incompatibility between SCPS and connection
tracking?

I am running Linux 2.6.26 on PowerPC.

On Mon, 2011-02-07, Washington Ratso wrote:
> When I have connection tracking enabled in the kernel and use the
> Space Communications Protocol Standard (SCPS)
^^^^^^^^
The name sounded silly, so I googled it. It's "Space Communications
Protocol Specifications", which sounds much more serious.

http://en.wikipedia.org/wiki/Space_C...Specifications

> which is a protocol to
> speed up TCP over satellite

It's many different things. Do you mean the sender-side modifications
to TCP, or the alternative to IP, or the FTP extensions, or ... ?

I have never heard of it before so I can't help -- but due to the
vague information, neither can anyone else at this point.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Feb 8, 1:47*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Mon, 2011-02-07, Washington Ratso wrote:
> > When I have connection tracking enabled in the kernel and use the
> > Space Communications Protocol Standard (SCPS)
>
> * * * * * * * * * * * * * * * * ^^^^^^^^
> The name sounded silly, so I googled it. It's "Space Communications
> Protocol Specifications", which sounds much more serious.
>
> http://en.wikipedia.org/wiki/Space_C...col_Specificat...
>
> > which is a protocol to
> > speed up TCP over satellite
>
> It's many different things. *Do you mean the sender-side modifications
> to TCP, or the alternative to IP, or the FTP extensions, or ... ?
>
> I have never heard of it before so I can't help -- but due to the
> vague information, neither can anyone else at this point.
>
> /Jorgen
>
> --
> * // Jorgen Grahn <grahn@ *Oo *o. * . *.
> \X/ * * snipabacken.se> * O *o * .


It is on the receive side. The call originates on a Polycom
ViewStationFX (10.175.1.3). It then goes through a Linux box
(10.185.1.1), over a satellite link, then through another Linux box
(10.175.2.1), then to a PC (10.175.2.2). While setting up the call, I
can see the "Connect" message is sent from the PC (10.175.2.2) but the
Linux box (10.175.2.1) intentionally drops it, as mentioned above, in
the kernel's connection tracking software.

Note, it is the kernel that is dropping the packet, not the SCPS
software, but enabling the SCPS does cause the "Connect" packet to be
dropped because this does not happen if SCPS is not enabled.

What other details would you like to know?

On Thu, 2011-02-10, Washington Ratso wrote:
> On Feb 8, 1:47*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Mon, 2011-02-07, Washington Ratso wrote:
>> > When I have connection tracking enabled in the kernel and use the
>> > Space Communications Protocol Standard (SCPS)
>>
>> * * * * * * * * * * * * * * * * ^^^^^^^^
>> The name sounded silly, so I googled it. It's "Space Communications
>> Protocol Specifications", which sounds much more serious.
>>
>> http://en.wikipedia.org/wiki/Space_C...col_Specificat...
>>
>> > which is a protocol to
>> > speed up TCP over satellite
>>
>> It's many different things. *Do you mean the sender-side modifications
>> to TCP, or the alternative to IP, or the FTP extensions, or ... ?
>>
>> I have never heard of it before so I can't help -- but due to the
>> vague information, neither can anyone else at this point.

> It is on the receive side. The call originates on a Polycom
> ViewStationFX (10.175.1.3). It then goes through a Linux box
> (10.185.1.1), over a satellite link, then through another Linux box
> (10.175.2.1), then to a PC (10.175.2.2). While setting up the call, I
> can see the "Connect" message is sent from the PC (10.175.2.2) but the
> Linux box (10.175.2.1) intentionally drops it, as mentioned above, in
> the kernel's connection tracking software.
>
> Note, it is the kernel that is dropping the packet, not the SCPS
> software, but enabling the SCPS does cause the "Connect" packet to be
> dropped because this does not happen if SCPS is not enabled.
>
> What other details would you like to know?

I cannot help you either way (sorry!) but you still haven't said which
of the different SCPS protocols you are using. Although perhaps people
who know these things know which one a "Polycom ViewStationFX" uses,
or which one uses the terms "call" and "connect".

But, since noone has replied, probably noone reading this group knows
enough about these things to help you.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Feb 10, 2:04*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Thu, 2011-02-10, Washington Ratso wrote:
> > On Feb 8, 1:47 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> >> On Mon, 2011-02-07, Washington Ratso wrote:
> >> > When I have connection tracking enabled in the kernel and use the
> >> > Space Communications Protocol Standard (SCPS)
>
> >> ^^^^^^^^
> >> The name sounded silly, so I googled it. It's "Space Communications
> >> Protocol Specifications", which sounds much more serious.
>
> >>http://en.wikipedia.org/wiki/Space_C...col_Specificat....
>
> >> > which is a protocol to
> >> > speed up TCP over satellite
>
> >> It's many different things. Do you mean the sender-side modifications
> >> to TCP, or the alternative to IP, or the FTP extensions, or ... ?
>
> >> I have never heard of it before so I can't help -- but due to the
> >> vague information, neither can anyone else at this point.
> > It is on the receive side. *The call originates on a Polycom
> > ViewStationFX (10.175.1.3). It then goes through a Linux box
> > (10.185.1.1), over a satellite link, then through another Linux box
> > (10.175.2.1), then to a PC (10.175.2.2). *While setting up the call, I
> > can see the "Connect" message is sent from the PC (10.175.2.2) but the
> > Linux box (10.175.2.1) intentionally drops it, as mentioned above, in
> > the kernel's connection tracking software.
>
> > Note, it is the kernel that is dropping the packet, not the SCPS
> > software, but enabling the SCPS does cause the "Connect" packet to be
> > dropped because this does not happen if SCPS is not enabled.
>
> > What other details would you like to know?
>
> I cannot help you either way (sorry!) but you still haven't said which
> of the different SCPS protocols you are using. Although perhaps people
> who know these things know which one a "Polycom ViewStationFX" uses,
> or which one uses the terms "call" and "connect".
>
> But, since noone has replied, probably noone reading this group knows
> enough about these things to help you.
>
> /Jorgen
>
> --
> * // Jorgen Grahn <grahn@ *Oo *o. * . *.
> \X/ * * snipabacken.se> * O *o * .


H.225.0 protocol