diff options
author | Shaun Pereira <spereira@tusc.com.au> | 2005-06-22 22:15:01 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2005-06-22 22:15:01 -0700 |
commit | cb65d506c34c86df5bcef939ce5a8666a451bd8b (patch) | |
tree | 4cf281ba2e90c9c20d28a80d1efc8292aaba699a /include/net | |
parent | 68d318720052154bc6b2513b0f15d0d947cc53c9 (diff) | |
download | linux-3.10-cb65d506c34c86df5bcef939ce5a8666a451bd8b.tar.gz linux-3.10-cb65d506c34c86df5bcef939ce5a8666a451bd8b.tar.bz2 linux-3.10-cb65d506c34c86df5bcef939ce5a8666a451bd8b.zip |
[X25]: Selective sub-address matching with call user data.
From: Shaun Pereira <spereira@tusc.com.au>
This is the first (independent of the second) patch of two that I am
working on with x25 on linux (tested with xot on a cisco router). Details
are as follows.
Current state of module:
A server using the current implementation (2.6.11.7) of the x25 module will
accept a call request/ incoming call packet at the listening x.25 address,
from all callers to that address, as long as NO call user data is present
in the packet header.
If the server needs to choose to accept a particular call request/ incoming
call packet arriving at its listening x25 address, then the kernel has to
allow a match of call user data present in the call request packet with its
own. This is required when multiple servers listen at the same x25 address
and device interface. The kernel currently matches ALL call user data, if
present.
Current Changes:
This patch is a follow up to the patch submitted previously by Andrew
Hendry, and allows the user to selectively control the number of octets of
call user data in the call request packet, that the kernel will match. By
default no call user data is matched, even if call user data is present.
To allow call user data matching, a cudmatchlength > 0 has to be passed
into the kernel after which the passed number of octets will be matched.
Otherwise the kernel behavior is exactly as the original implementation.
This patch also ensures that as is normally the case, no call user data
will be present in the Call accepted / call connected packet sent back to
the caller
Future Changes on next patch:
There are cases however when call user data may be present in the call
accepted packet. According to the X.25 recommendation (ITU-T 10/96)
section 5.2.3.2 call user data may be present in the call accepted packet
provided the fast select facility is used. My next patch will include this
fast select utility and the ability to send up to 128 octets call user data
in the call accepted packet provided the fast select facility is used. I
am currently testing this, again with xot on linux and cisco.
Signed-off-by: Shaun Pereira <spereira@tusc.com.au>
(With a fix from Alexey Dobriyan <adobriyan@gmail.com>)
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/net')
-rw-r--r-- | include/net/x25.h | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/include/net/x25.h b/include/net/x25.h index 7a1ba5bbb86..9dd70dd4a9b 100644 --- a/include/net/x25.h +++ b/include/net/x25.h @@ -134,7 +134,7 @@ struct x25_sock { struct sock sk; struct x25_address source_addr, dest_addr; struct x25_neigh *neighbour; - unsigned int lci; + unsigned int lci, cudmatchlength; unsigned char state, condition, qbitincl, intflag; unsigned short vs, vr, va, vl; unsigned long t2, t21, t22, t23; @@ -242,7 +242,6 @@ extern int x25_validate_nr(struct sock *, unsigned short); extern void x25_write_internal(struct sock *, int); extern int x25_decode(struct sock *, struct sk_buff *, int *, int *, int *, int *, int *); extern void x25_disconnect(struct sock *, int, unsigned char, unsigned char); -extern int x25_check_calluserdata(struct x25_calluserdata *,struct x25_calluserdata *); /* x25_timer.c */ extern void x25_start_heartbeat(struct sock *); |