2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* X.25 Packet Layer release 002
|
|
|
|
*
|
|
|
|
* This is ALPHA test software. This code may break your machine,
|
|
|
|
* randomly fail to work with new releases, misbehave and/or generally
|
|
|
|
* screw up. It might even work.
|
|
|
|
*
|
|
|
|
* This code REQUIRES 2.1.15 or higher
|
|
|
|
*
|
|
|
|
* This module:
|
|
|
|
* This module is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* History
|
|
|
|
* X.25 001 Split from x25_subr.c
|
|
|
|
* mar/20/00 Daniela Squassoni Disabling/enabling of facilities
|
|
|
|
* negotiation.
|
[X25]: Fast select with no restriction on response
This patch is a follow up to patch 1 regarding "Selective Sub Address
matching with call user data". It allows use of the Fast-Select-Acceptance
optional user facility for X.25.
This patch just implements fast select with no restriction on response
(NRR). What this means (according to ITU-T Recomendation 10/96 section
6.16) is that if in an incoming call packet, the relevant facility bits are
set for fast-select-NRR, then the called DTE can issue a direct response to
the incoming packet using a call-accepted packet that contains
call-user-data. This patch allows such a response.
The called DTE can also respond with a clear-request packet that contains
call-user-data. However, this feature is currently not implemented by the
patch.
How is Fast Select Acceptance used?
By default, the system does not allow fast select acceptance (as before).
To enable a response to fast select acceptance,
After a listen socket in created and bound as follows
socket(AF_X25, SOCK_SEQPACKET, 0);
bind(call_soc, (struct sockaddr *)&locl_addr, sizeof(locl_addr));
but before a listen system call is made, the following ioctl should be used.
ioctl(call_soc,SIOCX25CALLACCPTAPPRV);
Now the listen system call can be made
listen(call_soc, 4);
After this, an incoming-call packet will be accepted, but no call-accepted
packet will be sent back until the following system call is made on the socket
that accepts the call
ioctl(vc_soc,SIOCX25SENDCALLACCPT);
The network (or cisco xot router used for testing here) will allow the
application server's call-user-data in the call-accepted packet,
provided the call-request was made with Fast-select NRR.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-22 22:16:17 -07:00
|
|
|
* apr/14/05 Shaun Pereira - Allow fast select with no restriction
|
|
|
|
* on response.
|
2005-04-16 15:20:36 -07:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/skbuff.h>
|
|
|
|
#include <net/sock.h>
|
|
|
|
#include <net/x25.h>
|
|
|
|
|
|
|
|
/*
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
* Parse a set of facilities into the facilities structures. Unrecognised
|
2005-04-16 15:20:36 -07:00
|
|
|
* facilities are written to the debug log file.
|
|
|
|
*/
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
|
|
|
|
struct x25_dte_facilities *dte_facs, unsigned long *vc_fac_mask)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
unsigned char *p = skb->data;
|
|
|
|
unsigned int len = *p++;
|
|
|
|
|
|
|
|
*vc_fac_mask = 0;
|
|
|
|
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
/*
|
|
|
|
* The kernel knows which facilities were set on an incoming call but
|
|
|
|
* currently this information is not available to userspace. Here we
|
|
|
|
* give userspace who read incoming call facilities 0 length to indicate
|
|
|
|
* it wasn't set.
|
|
|
|
*/
|
|
|
|
dte_facs->calling_len = 0;
|
|
|
|
dte_facs->called_len = 0;
|
|
|
|
memset(dte_facs->called_ae, '\0', sizeof(dte_facs->called_ae));
|
|
|
|
memset(dte_facs->calling_ae, '\0', sizeof(dte_facs->calling_ae));
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
while (len > 0) {
|
|
|
|
switch (*p & X25_FAC_CLASS_MASK) {
|
|
|
|
case X25_FAC_CLASS_A:
|
|
|
|
switch (*p) {
|
|
|
|
case X25_FAC_REVERSE:
|
[X25]: Fast select with no restriction on response
This patch is a follow up to patch 1 regarding "Selective Sub Address
matching with call user data". It allows use of the Fast-Select-Acceptance
optional user facility for X.25.
This patch just implements fast select with no restriction on response
(NRR). What this means (according to ITU-T Recomendation 10/96 section
6.16) is that if in an incoming call packet, the relevant facility bits are
set for fast-select-NRR, then the called DTE can issue a direct response to
the incoming packet using a call-accepted packet that contains
call-user-data. This patch allows such a response.
The called DTE can also respond with a clear-request packet that contains
call-user-data. However, this feature is currently not implemented by the
patch.
How is Fast Select Acceptance used?
By default, the system does not allow fast select acceptance (as before).
To enable a response to fast select acceptance,
After a listen socket in created and bound as follows
socket(AF_X25, SOCK_SEQPACKET, 0);
bind(call_soc, (struct sockaddr *)&locl_addr, sizeof(locl_addr));
but before a listen system call is made, the following ioctl should be used.
ioctl(call_soc,SIOCX25CALLACCPTAPPRV);
Now the listen system call can be made
listen(call_soc, 4);
After this, an incoming-call packet will be accepted, but no call-accepted
packet will be sent back until the following system call is made on the socket
that accepts the call
ioctl(vc_soc,SIOCX25SENDCALLACCPT);
The network (or cisco xot router used for testing here) will allow the
application server's call-user-data in the call-accepted packet,
provided the call-request was made with Fast-select NRR.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-22 22:16:17 -07:00
|
|
|
if((p[1] & 0x81) == 0x81) {
|
|
|
|
facilities->reverse = p[1] & 0x81;
|
|
|
|
*vc_fac_mask |= X25_MASK_REVERSE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if((p[1] & 0x01) == 0x01) {
|
|
|
|
facilities->reverse = p[1] & 0x01;
|
|
|
|
*vc_fac_mask |= X25_MASK_REVERSE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if((p[1] & 0x80) == 0x80) {
|
|
|
|
facilities->reverse = p[1] & 0x80;
|
|
|
|
*vc_fac_mask |= X25_MASK_REVERSE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(p[1] == 0x00) {
|
|
|
|
facilities->reverse
|
|
|
|
= X25_DEFAULT_REVERSE;
|
|
|
|
*vc_fac_mask |= X25_MASK_REVERSE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
case X25_FAC_THROUGHPUT:
|
|
|
|
facilities->throughput = p[1];
|
|
|
|
*vc_fac_mask |= X25_MASK_THROUGHPUT;
|
|
|
|
break;
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
case X25_MARKER:
|
|
|
|
break;
|
2005-04-16 15:20:36 -07:00
|
|
|
default:
|
|
|
|
printk(KERN_DEBUG "X.25: unknown facility "
|
|
|
|
"%02X, value %02X\n",
|
|
|
|
p[0], p[1]);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
p += 2;
|
|
|
|
len -= 2;
|
|
|
|
break;
|
|
|
|
case X25_FAC_CLASS_B:
|
|
|
|
switch (*p) {
|
|
|
|
case X25_FAC_PACKET_SIZE:
|
|
|
|
facilities->pacsize_in = p[1];
|
|
|
|
facilities->pacsize_out = p[2];
|
|
|
|
*vc_fac_mask |= X25_MASK_PACKET_SIZE;
|
|
|
|
break;
|
|
|
|
case X25_FAC_WINDOW_SIZE:
|
|
|
|
facilities->winsize_in = p[1];
|
|
|
|
facilities->winsize_out = p[2];
|
|
|
|
*vc_fac_mask |= X25_MASK_WINDOW_SIZE;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printk(KERN_DEBUG "X.25: unknown facility "
|
|
|
|
"%02X, values %02X, %02X\n",
|
|
|
|
p[0], p[1], p[2]);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
p += 3;
|
|
|
|
len -= 3;
|
|
|
|
break;
|
|
|
|
case X25_FAC_CLASS_C:
|
|
|
|
printk(KERN_DEBUG "X.25: unknown facility %02X, "
|
|
|
|
"values %02X, %02X, %02X\n",
|
|
|
|
p[0], p[1], p[2], p[3]);
|
|
|
|
p += 4;
|
|
|
|
len -= 4;
|
|
|
|
break;
|
|
|
|
case X25_FAC_CLASS_D:
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
switch (*p) {
|
|
|
|
case X25_FAC_CALLING_AE:
|
|
|
|
if (p[1] > X25_MAX_DTE_FACIL_LEN)
|
|
|
|
break;
|
|
|
|
dte_facs->calling_len = p[2];
|
|
|
|
memcpy(dte_facs->calling_ae, &p[3], p[1] - 1);
|
|
|
|
*vc_fac_mask |= X25_MASK_CALLING_AE;
|
|
|
|
break;
|
|
|
|
case X25_FAC_CALLED_AE:
|
|
|
|
if (p[1] > X25_MAX_DTE_FACIL_LEN)
|
|
|
|
break;
|
|
|
|
dte_facs->called_len = p[2];
|
|
|
|
memcpy(dte_facs->called_ae, &p[3], p[1] - 1);
|
|
|
|
*vc_fac_mask |= X25_MASK_CALLED_AE;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printk(KERN_DEBUG "X.25: unknown facility %02X,"
|
|
|
|
"length %d, values %02X, %02X, "
|
|
|
|
"%02X, %02X\n",
|
|
|
|
p[0], p[1], p[2], p[3], p[4], p[5]);
|
|
|
|
break;
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
len -= p[1] + 2;
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
p += p[1] + 2;
|
2005-04-16 15:20:36 -07:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return p - skb->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a set of facilities.
|
|
|
|
*/
|
|
|
|
int x25_create_facilities(unsigned char *buffer,
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
struct x25_facilities *facilities,
|
|
|
|
struct x25_dte_facilities *dte_facs, unsigned long facil_mask)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
unsigned char *p = buffer + 1;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
if (!facil_mask) {
|
|
|
|
/*
|
|
|
|
* Length of the facilities field in call_req or
|
|
|
|
* call_accept packets
|
|
|
|
*/
|
|
|
|
buffer[0] = 0;
|
|
|
|
len = 1; /* 1 byte for the length field */
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (facilities->reverse && (facil_mask & X25_MASK_REVERSE)) {
|
|
|
|
*p++ = X25_FAC_REVERSE;
|
[X25]: Fast select with no restriction on response
This patch is a follow up to patch 1 regarding "Selective Sub Address
matching with call user data". It allows use of the Fast-Select-Acceptance
optional user facility for X.25.
This patch just implements fast select with no restriction on response
(NRR). What this means (according to ITU-T Recomendation 10/96 section
6.16) is that if in an incoming call packet, the relevant facility bits are
set for fast-select-NRR, then the called DTE can issue a direct response to
the incoming packet using a call-accepted packet that contains
call-user-data. This patch allows such a response.
The called DTE can also respond with a clear-request packet that contains
call-user-data. However, this feature is currently not implemented by the
patch.
How is Fast Select Acceptance used?
By default, the system does not allow fast select acceptance (as before).
To enable a response to fast select acceptance,
After a listen socket in created and bound as follows
socket(AF_X25, SOCK_SEQPACKET, 0);
bind(call_soc, (struct sockaddr *)&locl_addr, sizeof(locl_addr));
but before a listen system call is made, the following ioctl should be used.
ioctl(call_soc,SIOCX25CALLACCPTAPPRV);
Now the listen system call can be made
listen(call_soc, 4);
After this, an incoming-call packet will be accepted, but no call-accepted
packet will be sent back until the following system call is made on the socket
that accepts the call
ioctl(vc_soc,SIOCX25SENDCALLACCPT);
The network (or cisco xot router used for testing here) will allow the
application server's call-user-data in the call-accepted packet,
provided the call-request was made with Fast-select NRR.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-22 22:16:17 -07:00
|
|
|
*p++ = facilities->reverse;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (facilities->throughput && (facil_mask & X25_MASK_THROUGHPUT)) {
|
|
|
|
*p++ = X25_FAC_THROUGHPUT;
|
|
|
|
*p++ = facilities->throughput;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((facilities->pacsize_in || facilities->pacsize_out) &&
|
|
|
|
(facil_mask & X25_MASK_PACKET_SIZE)) {
|
|
|
|
*p++ = X25_FAC_PACKET_SIZE;
|
|
|
|
*p++ = facilities->pacsize_in ? : facilities->pacsize_out;
|
|
|
|
*p++ = facilities->pacsize_out ? : facilities->pacsize_in;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((facilities->winsize_in || facilities->winsize_out) &&
|
|
|
|
(facil_mask & X25_MASK_WINDOW_SIZE)) {
|
|
|
|
*p++ = X25_FAC_WINDOW_SIZE;
|
|
|
|
*p++ = facilities->winsize_in ? : facilities->winsize_out;
|
|
|
|
*p++ = facilities->winsize_out ? : facilities->winsize_in;
|
|
|
|
}
|
|
|
|
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
if (facil_mask & (X25_MASK_CALLING_AE|X25_MASK_CALLED_AE)) {
|
|
|
|
*p++ = X25_MARKER;
|
|
|
|
*p++ = X25_DTE_SERVICES;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dte_facs->calling_len && (facil_mask & X25_MASK_CALLING_AE)) {
|
|
|
|
unsigned bytecount = (dte_facs->calling_len % 2) ?
|
|
|
|
dte_facs->calling_len / 2 + 1 :
|
|
|
|
dte_facs->calling_len / 2;
|
|
|
|
*p++ = X25_FAC_CALLING_AE;
|
|
|
|
*p++ = 1 + bytecount;
|
|
|
|
*p++ = dte_facs->calling_len;
|
|
|
|
memcpy(p, dte_facs->calling_ae, bytecount);
|
|
|
|
p += bytecount;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dte_facs->called_len && (facil_mask & X25_MASK_CALLED_AE)) {
|
|
|
|
unsigned bytecount = (dte_facs->called_len % 2) ?
|
|
|
|
dte_facs->called_len / 2 + 1 :
|
|
|
|
dte_facs->called_len / 2;
|
|
|
|
*p++ = X25_FAC_CALLED_AE;
|
|
|
|
*p++ = 1 + bytecount;
|
|
|
|
*p++ = dte_facs->called_len;
|
|
|
|
memcpy(p, dte_facs->called_ae, bytecount);
|
|
|
|
p+=bytecount;
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
len = p - buffer;
|
|
|
|
buffer[0] = len - 1;
|
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to reach a compromise on a set of facilities.
|
|
|
|
*
|
|
|
|
* The only real problem is with reverse charging.
|
|
|
|
*/
|
|
|
|
int x25_negotiate_facilities(struct sk_buff *skb, struct sock *sk,
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
struct x25_facilities *new, struct x25_dte_facilities *dte)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
struct x25_sock *x25 = x25_sk(sk);
|
|
|
|
struct x25_facilities *ours = &x25->facilities;
|
|
|
|
struct x25_facilities theirs;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
memset(&theirs, 0, sizeof(theirs));
|
|
|
|
memcpy(new, ours, sizeof(*new));
|
|
|
|
|
[X25]: allow ITU-T DTE facilities for x25
Allows use of the optional user facility to insert ITU-T
(http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
packets. This feature is optional; no facilities will be added if the ioctl
is not used, and call setup packet remains the same as before.
If the ioctls provided by the patch are used, then a facility marker will be
added to the x25 packet header so that the called dte address extension
facility can be differentiated from other types of facilities (as described in
the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
Facility markers are made up of two octets, and may be present in the x25
packet headers of call-request, incoming call, call accepted, clear request,
and clear indication packets. The first of the two octets represents the
facility code field and is set to zero by this patch. The second octet of the
marker represents the facility parameter field and is set to 0x0F because the
marker will be inserted before ITU-T type DTE facilities.
Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
will support the facility markers with a facility parameter field set to all
ones or to 00001111", therefore this patch should work with all x.25 networks.
While there are many ITU-T DTE facilities, this patch implements only the
called and calling address extension, with placeholders in the
x25_dte_facilities structure for the rest of the facilities.
Testing:
This patch was tested using a cisco xot router connected on its serial ports
to an X.25 network, and on its lan ports to a host running an xotd daemon.
It is also possible to test this patch using an xotd daemon and an x25tap
patch, where the xotd daemons work back-to-back without actually using an x.25
network. See www.fyonne.net for details on how to do this.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Acked-by: Andrew Hendry <ahendry@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-22 01:01:31 -07:00
|
|
|
len = x25_parse_facilities(skb, &theirs, dte, &x25->vc_facil_mask);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* They want reverse charging, we won't accept it.
|
|
|
|
*/
|
[X25]: Fast select with no restriction on response
This patch is a follow up to patch 1 regarding "Selective Sub Address
matching with call user data". It allows use of the Fast-Select-Acceptance
optional user facility for X.25.
This patch just implements fast select with no restriction on response
(NRR). What this means (according to ITU-T Recomendation 10/96 section
6.16) is that if in an incoming call packet, the relevant facility bits are
set for fast-select-NRR, then the called DTE can issue a direct response to
the incoming packet using a call-accepted packet that contains
call-user-data. This patch allows such a response.
The called DTE can also respond with a clear-request packet that contains
call-user-data. However, this feature is currently not implemented by the
patch.
How is Fast Select Acceptance used?
By default, the system does not allow fast select acceptance (as before).
To enable a response to fast select acceptance,
After a listen socket in created and bound as follows
socket(AF_X25, SOCK_SEQPACKET, 0);
bind(call_soc, (struct sockaddr *)&locl_addr, sizeof(locl_addr));
but before a listen system call is made, the following ioctl should be used.
ioctl(call_soc,SIOCX25CALLACCPTAPPRV);
Now the listen system call can be made
listen(call_soc, 4);
After this, an incoming-call packet will be accepted, but no call-accepted
packet will be sent back until the following system call is made on the socket
that accepts the call
ioctl(vc_soc,SIOCX25SENDCALLACCPT);
The network (or cisco xot router used for testing here) will allow the
application server's call-user-data in the call-accepted packet,
provided the call-request was made with Fast-select NRR.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-22 22:16:17 -07:00
|
|
|
if ((theirs.reverse & 0x01 ) && (ours->reverse & 0x01)) {
|
2005-04-16 15:20:36 -07:00
|
|
|
SOCK_DEBUG(sk, "X.25: rejecting reverse charging request");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
new->reverse = theirs.reverse;
|
|
|
|
|
|
|
|
if (theirs.throughput) {
|
|
|
|
if (theirs.throughput < ours->throughput) {
|
|
|
|
SOCK_DEBUG(sk, "X.25: throughput negotiated down");
|
|
|
|
new->throughput = theirs.throughput;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (theirs.pacsize_in && theirs.pacsize_out) {
|
|
|
|
if (theirs.pacsize_in < ours->pacsize_in) {
|
|
|
|
SOCK_DEBUG(sk, "X.25: packet size inwards negotiated down");
|
|
|
|
new->pacsize_in = theirs.pacsize_in;
|
|
|
|
}
|
|
|
|
if (theirs.pacsize_out < ours->pacsize_out) {
|
|
|
|
SOCK_DEBUG(sk, "X.25: packet size outwards negotiated down");
|
|
|
|
new->pacsize_out = theirs.pacsize_out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (theirs.winsize_in && theirs.winsize_out) {
|
|
|
|
if (theirs.winsize_in < ours->winsize_in) {
|
|
|
|
SOCK_DEBUG(sk, "X.25: window size inwards negotiated down");
|
|
|
|
new->winsize_in = theirs.winsize_in;
|
|
|
|
}
|
|
|
|
if (theirs.winsize_out < ours->winsize_out) {
|
|
|
|
SOCK_DEBUG(sk, "X.25: window size outwards negotiated down");
|
|
|
|
new->winsize_out = theirs.winsize_out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Limit values of certain facilities according to the capability of the
|
|
|
|
* currently attached x25 link.
|
|
|
|
*/
|
|
|
|
void x25_limit_facilities(struct x25_facilities *facilities,
|
|
|
|
struct x25_neigh *nb)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (!nb->extended) {
|
|
|
|
if (facilities->winsize_in > 7) {
|
|
|
|
printk(KERN_DEBUG "X.25: incoming winsize limited to 7\n");
|
|
|
|
facilities->winsize_in = 7;
|
|
|
|
}
|
|
|
|
if (facilities->winsize_out > 7) {
|
|
|
|
facilities->winsize_out = 7;
|
|
|
|
printk( KERN_DEBUG "X.25: outgoing winsize limited to 7\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|