summaryrefslogtreecommitdiff
path: root/include/net
diff options
context:
space:
mode:
authorShaun Pereira <spereira@tusc.com.au>2005-06-22 22:15:01 -0700
committerDavid S. Miller <davem@davemloft.net>2005-06-22 22:15:01 -0700
commitcb65d506c34c86df5bcef939ce5a8666a451bd8b (patch)
tree4cf281ba2e90c9c20d28a80d1efc8292aaba699a /include/net
parent68d318720052154bc6b2513b0f15d0d947cc53c9 (diff)
downloadlinux-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.h3
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 *);