* [PATCH 2.6.11.7] x25: Call accept with call request CUD
@ 2005-04-10 6:52 Michael Flower
2005-04-11 4:39 ` Andrew Hendry
0 siblings, 1 reply; 2+ messages in thread
From: Michael Flower @ 2005-04-10 6:52 UTC (permalink / raw)
To: eis, linux-x25
I believe that I have found a bug in the X25 code in the kernel and have
attached a simple patch.
An incoming x25 connecton request with call user data (CUD) generates a
call accept with a copy of the user data in the packet.
I do not believe that the X25 spec allows such a call accept
packet.
The problem arose using XOT from a linux box, through a cisco router
(doing the de-encapsulation) and forwarding to a telecom switch via X25.
When switch tried to connect to the Linux box the router encapsulated
the connection request into an XOT packet and sent it to the linux box.
The connection request had CUD.
The linux box (running xotd), de-encapsulated the packet, and routed it
to X25.
The X25 system sent a call accept packet back to the router
(XOT encapsulated) which had the original CUD inside the packet.
The router immediately barfed, and sent a clear request back
to the linux box and the switch. The Cisco router complained
that the X25 call acknowledgement packet was too long in its debug log.
It seems reasonable that it did barf. I am not sure that sending the CUD
back with the connect accept packet makes sense, and the
only reference I can find on the X25 protocol doesn't allow for
CUD in call accept packets.
The fix is to remove the offending four lines of code in X25_utilities.c
that append the CUD to the call acknowledgement packet. It certainly
fixes the problems described above with cisco routers.
The XOT stuff, lately ported to 2.6 by Andrew Hendry
(ahendry@tusc.com.au) appears to be very useful in a telecoms arena.
There are some issues with x25 module useage counting, that I will
fix ASAP. I hope that all this can then be integrated into future
kernels.
The patch
--- linux-2.6.11.7/net/x25/x25_subr.c 2005-04-08 04:57:26.000000000
+1000
+++ linux-2.6.11.7_new/net/x25/x25_subr.c 2005-04-08 17:46:32.591950835
+1000
@@ -203,10 +203,6 @@
x25->vc_facil_mask);
dptr = skb_put(skb, len);
memcpy(dptr, facilities, len);
- dptr = skb_put(skb,x25->calluserdata.cudlength);
- memcpy(dptr, x25->calluserdata.cuddata,
- x25->calluserdata.cudlength);
- x25->calluserdata.cudlength = 0;
break;
case X25_CLEAR_REQUEST:
Michael Flower
mcf-tech@windsurfwa.com
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH 2.6.11.7] x25: Call accept with call request CUD
2005-04-10 6:52 [PATCH 2.6.11.7] x25: Call accept with call request CUD Michael Flower
@ 2005-04-11 4:39 ` Andrew Hendry
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Hendry @ 2005-04-11 4:39 UTC (permalink / raw)
To: Michael Flower; +Cc: eis, linux-x25
Hi Michael,
We have noticed the same issue.
Im not sure blocking the cud on call accept outright covers all cases.
It looks like there is one case (fast select) where a call accept may
contain call user data, but it is not an exact copy of the received cud.
Shaun here is working on a patch to better control this call accept
packet and its contents.
Not much life on this linux-x25 list, ive found its best to CC patches
to the main kernel list for someone to pickup.
Andrew.
On Sun, 2005-04-10 at 16:52, Michael Flower wrote:
> I believe that I have found a bug in the X25 code in the kernel and have
> attached a simple patch.
>
> An incoming x25 connecton request with call user data (CUD) generates a
> call accept with a copy of the user data in the packet.
>
> I do not believe that the X25 spec allows such a call accept
> packet.
>
> The problem arose using XOT from a linux box, through a cisco router
> (doing the de-encapsulation) and forwarding to a telecom switch via X25.
>
> When switch tried to connect to the Linux box the router encapsulated
> the connection request into an XOT packet and sent it to the linux box.
>
> The connection request had CUD.
>
> The linux box (running xotd), de-encapsulated the packet, and routed it
> to X25.
>
> The X25 system sent a call accept packet back to the router
> (XOT encapsulated) which had the original CUD inside the packet.
>
> The router immediately barfed, and sent a clear request back
> to the linux box and the switch. The Cisco router complained
> that the X25 call acknowledgement packet was too long in its debug log.
>
> It seems reasonable that it did barf. I am not sure that sending the CUD
> back with the connect accept packet makes sense, and the
> only reference I can find on the X25 protocol doesn't allow for
> CUD in call accept packets.
>
> The fix is to remove the offending four lines of code in X25_utilities.c
> that append the CUD to the call acknowledgement packet. It certainly
> fixes the problems described above with cisco routers.
>
> The XOT stuff, lately ported to 2.6 by Andrew Hendry
> (ahendry@tusc.com.au) appears to be very useful in a telecoms arena.
> There are some issues with x25 module useage counting, that I will
> fix ASAP. I hope that all this can then be integrated into future
> kernels.
>
> The patch
>
> --- linux-2.6.11.7/net/x25/x25_subr.c 2005-04-08 04:57:26.000000000
> +1000
> +++ linux-2.6.11.7_new/net/x25/x25_subr.c 2005-04-08 17:46:32.591950835
> +1000
> @@ -203,10 +203,6 @@
> x25->vc_facil_mask);
> dptr = skb_put(skb, len);
> memcpy(dptr, facilities, len);
> - dptr = skb_put(skb,x25->calluserdata.cudlength);
> - memcpy(dptr, x25->calluserdata.cuddata,
> - x25->calluserdata.cudlength);
> - x25->calluserdata.cudlength = 0;
> break;
>
> case X25_CLEAR_REQUEST:
>
> Michael Flower
>
> mcf-tech@windsurfwa.com
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-x25" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-04-11 4:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-10 6:52 [PATCH 2.6.11.7] x25: Call accept with call request CUD Michael Flower
2005-04-11 4:39 ` Andrew Hendry
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox