asgardius/android_kernel_motorola_sm6225
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
android_kernel_motorola_sm6225/include/net/x25.h

307 lines
9.3 KiB
C
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
/*
* Declarations of X.25 Packet Layer type objects.
*
* History
* nov/17/96 Jonathan Naylor Initial version.
* mar/20/00 Daniela Squassoni Disabling/enabling of facilities
* negotiation.
*/
#ifndef _X25_H
#define _X25_H
#include <linux/x25.h>
#include <net/sock.h>
#define X25_ADDR_LEN 16
#define X25_MAX_L2_LEN 18 /* 802.2 LLC */
#define X25_STD_MIN_LEN 3
#define X25_EXT_MIN_LEN 4
#define X25_GFI_SEQ_MASK 0x30
#define X25_GFI_STDSEQ 0x10
#define X25_GFI_EXTSEQ 0x20
#define X25_Q_BIT 0x80
#define X25_D_BIT 0x40
#define X25_STD_M_BIT 0x10
#define X25_EXT_M_BIT 0x01
#define X25_CALL_REQUEST 0x0B
#define X25_CALL_ACCEPTED 0x0F
#define X25_CLEAR_REQUEST 0x13
#define X25_CLEAR_CONFIRMATION 0x17
#define X25_DATA 0x00
#define X25_INTERRUPT 0x23
#define X25_INTERRUPT_CONFIRMATION 0x27
#define X25_RR 0x01
#define X25_RNR 0x05
#define X25_REJ 0x09
#define X25_RESET_REQUEST 0x1B
#define X25_RESET_CONFIRMATION 0x1F
#define X25_REGISTRATION_REQUEST 0xF3
#define X25_REGISTRATION_CONFIRMATION 0xF7
#define X25_RESTART_REQUEST 0xFB
#define X25_RESTART_CONFIRMATION 0xFF
#define X25_DIAGNOSTIC 0xF1
#define X25_ILLEGAL 0xFD
/* Define the various conditions that may exist */
#define X25_COND_ACK_PENDING 0x01
#define X25_COND_OWN_RX_BUSY 0x02
#define X25_COND_PEER_RX_BUSY 0x04
/* Define Link State constants. */
enum {
X25_STATE_0, /* Ready */
X25_STATE_1, /* Awaiting Call Accepted */
X25_STATE_2, /* Awaiting Clear Confirmation */
X25_STATE_3, /* Data Transfer */
X25_STATE_4 /* Awaiting Reset Confirmation */
};
enum {
X25_LINK_STATE_0,
X25_LINK_STATE_1,
X25_LINK_STATE_2,
X25_LINK_STATE_3
};
#define X25_DEFAULT_T20 (180 * HZ) /* Default T20 value */
#define X25_DEFAULT_T21 (200 * HZ) /* Default T21 value */
#define X25_DEFAULT_T22 (180 * HZ) /* Default T22 value */
#define X25_DEFAULT_T23 (180 * HZ) /* Default T23 value */
#define X25_DEFAULT_T2 (3 * HZ) /* Default ack holdback value */
#define X25_DEFAULT_WINDOW_SIZE 2 /* Default Window Size */
#define X25_DEFAULT_PACKET_SIZE X25_PS128 /* Default Packet Size */
#define X25_DEFAULT_THROUGHPUT 0x0A /* Deafult Throughput */
#define X25_DEFAULT_REVERSE 0x00 /* Default Reverse Charging */
[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-23 07:16:17 +02:00
#define X25_DENY_ACCPT_APPRV 0x01 /* Default value */
#define X25_ALLOW_ACCPT_APPRV 0x00 /* Control enabled */
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
#define X25_SMODULUS 8
#define X25_EMODULUS 128
/*
* X.25 Facilities constants.
*/
#define X25_FAC_CLASS_MASK 0xC0
#define X25_FAC_CLASS_A 0x00
#define X25_FAC_CLASS_B 0x40
#define X25_FAC_CLASS_C 0x80
#define X25_FAC_CLASS_D 0xC0
[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-23 07:16:17 +02:00
#define X25_FAC_REVERSE 0x01 /* also fast select */
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
#define X25_FAC_THROUGHPUT 0x02
#define X25_FAC_PACKET_SIZE 0x42
#define X25_FAC_WINDOW_SIZE 0x43
[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 09:01:31 +01:00
#define X25_MAX_FAC_LEN 60
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
#define X25_MAX_CUD_LEN 128
[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 09:01:31 +01:00
#define X25_FAC_CALLING_AE 0xCB
#define X25_FAC_CALLED_AE 0xC9
#define X25_MARKER 0x00
#define X25_DTE_SERVICES 0x0F
#define X25_MAX_AE_LEN 40 /* Max num of semi-octets in AE - OSI Nw */
#define X25_MAX_DTE_FACIL_LEN 21 /* Max length of DTE facility params */
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
/**
* struct x25_route - x25 routing entry
* @node - entry in x25_list_lock
* @address - Start of address range
* @sigdigits - Number of sig digits
* @dev - More than one for MLP
* @refcnt - reference counter
*/
struct x25_route {
struct list_head node;
struct x25_address address;
unsigned int sigdigits;
struct net_device *dev;
atomic_t refcnt;
};
struct x25_neigh {
struct list_head node;
struct net_device *dev;
unsigned int state;
unsigned int extended;
struct sk_buff_head queue;
unsigned long t20;
struct timer_list t20timer;
unsigned long global_facil_mask;
atomic_t refcnt;
};
struct x25_sock {
struct sock sk;
struct x25_address source_addr, dest_addr;
struct x25_neigh *neighbour;
[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>
2005-06-23 07:15:01 +02:00
unsigned int lci, cudmatchlength;
[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-23 07:16:17 +02:00
unsigned char state, condition, qbitincl, intflag, accptapprv;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
unsigned short vs, vr, va, vl;
unsigned long t2, t21, t22, t23;
unsigned short fraglen;
struct sk_buff_head ack_queue;
struct sk_buff_head fragment_queue;
struct sk_buff_head interrupt_in_queue;
struct sk_buff_head interrupt_out_queue;
struct timer_list timer;
struct x25_causediag causediag;
struct x25_facilities facilities;
[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 09:01:31 +01:00
struct x25_dte_facilities dte_facilities;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
struct x25_calluserdata calluserdata;
unsigned long vc_facil_mask; /* inc_call facilities mask */
};
[X.25]: Add call forwarding Adds call forwarding to X.25, allowing it to operate like an X.25 router. Useful if one needs to manipulate X.25 traffic with tools like tc. This is an update/cleanup based off a patch submitted by Daniel Ferenci a few years ago. Thanks Alan for the feedback. Added the null check to the clones. Moved the skb_clone's into the forwarding functions. Worked ok with Cisco XoT, linux X.25 back to back, and some old NTUs/PADs. Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-08 22:34:02 +01:00
struct x25_forward {
struct list_head node;
unsigned int lci;
struct net_device *dev1;
struct net_device *dev2;
atomic_t refcnt;
};
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
static inline struct x25_sock *x25_sk(const struct sock *sk)
{
return (struct x25_sock *)sk;
}
/* af_x25.c */
extern int sysctl_x25_restart_request_timeout;
extern int sysctl_x25_call_request_timeout;
extern int sysctl_x25_reset_request_timeout;
extern int sysctl_x25_clear_request_timeout;
extern int sysctl_x25_ack_holdback_timeout;
[X.25]: Adds /proc/sys/net/x25/x25_forward to control forwarding. echo "1" > /proc/sys/net/x25/x25_forward To turn on x25_forwarding, defaults to off Requires the previous patch. Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-08 22:34:36 +01:00
extern int sysctl_x25_forward;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
extern int x25_addr_ntoa(unsigned char *, struct x25_address *,
struct x25_address *);
extern int x25_addr_aton(unsigned char *, struct x25_address *,
struct x25_address *);
extern struct sock *x25_find_socket(unsigned int, struct x25_neigh *);
extern void x25_destroy_socket(struct sock *);
extern int x25_rx_call_request(struct sk_buff *, struct x25_neigh *, unsigned int);
extern void x25_kill_by_neigh(struct x25_neigh *);
/* x25_dev.c */
extern void x25_send_frame(struct sk_buff *, struct x25_neigh *);
[NET]: Kill skb->real_dev Bonding just wants the device before the skb_bond() decapsulation occurs, so simply pass that original device into packet_type->func() as an argument. It remains to be seen whether we can use this same exact thing to get rid of skb->input_dev as well. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-10 04:34:12 +02:00
extern int x25_lapb_receive_frame(struct sk_buff *, struct net_device *, struct packet_type *, struct net_device *);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
extern void x25_establish_link(struct x25_neigh *);
extern void x25_terminate_link(struct x25_neigh *);
/* x25_facilities.c */
[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 09:01:31 +01:00
extern int x25_parse_facilities(struct sk_buff *, struct x25_facilities *,
struct x25_dte_facilities *, unsigned long *);
extern int x25_create_facilities(unsigned char *, struct x25_facilities *,
struct x25_dte_facilities *, unsigned long);
extern int x25_negotiate_facilities(struct sk_buff *, struct sock *,
struct x25_facilities *,
struct x25_dte_facilities *);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
extern void x25_limit_facilities(struct x25_facilities *, struct x25_neigh *);
[X.25]: Add call forwarding Adds call forwarding to X.25, allowing it to operate like an X.25 router. Useful if one needs to manipulate X.25 traffic with tools like tc. This is an update/cleanup based off a patch submitted by Daniel Ferenci a few years ago. Thanks Alan for the feedback. Added the null check to the clones. Moved the skb_clone's into the forwarding functions. Worked ok with Cisco XoT, linux X.25 back to back, and some old NTUs/PADs. Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-08 22:34:02 +01:00
/* x25_forward.c */
extern void x25_clear_forward_by_lci(unsigned int lci);
extern void x25_clear_forward_by_dev(struct net_device *);
extern int x25_forward_data(int, struct x25_neigh *, struct sk_buff *);
extern int x25_forward_call(struct x25_address *, struct x25_neigh *,
struct sk_buff *, int);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
/* x25_in.c */
extern int x25_process_rx_frame(struct sock *, struct sk_buff *);
extern int x25_backlog_rcv(struct sock *, struct sk_buff *);
/* x25_link.c */
extern void x25_link_control(struct sk_buff *, struct x25_neigh *, unsigned short);
extern void x25_link_device_up(struct net_device *);
extern void x25_link_device_down(struct net_device *);
extern void x25_link_established(struct x25_neigh *);
extern void x25_link_terminated(struct x25_neigh *);
extern void x25_transmit_clear_request(struct x25_neigh *, unsigned int, unsigned char);
extern void x25_transmit_link(struct sk_buff *, struct x25_neigh *);
extern int x25_subscr_ioctl(unsigned int, void __user *);
extern struct x25_neigh *x25_get_neigh(struct net_device *);
extern void x25_link_free(void);
/* x25_neigh.c */
static __inline__ void x25_neigh_hold(struct x25_neigh *nb)
{
atomic_inc(&nb->refcnt);
}
static __inline__ void x25_neigh_put(struct x25_neigh *nb)
{
if (atomic_dec_and_test(&nb->refcnt))
kfree(nb);
}
/* x25_out.c */
extern int x25_output(struct sock *, struct sk_buff *);
extern void x25_kick(struct sock *);
extern void x25_enquiry_response(struct sock *);
/* x25_route.c */
extern struct x25_route *x25_get_route(struct x25_address *addr);
extern struct net_device *x25_dev_get(char *);
extern void x25_route_device_down(struct net_device *dev);
extern int x25_route_ioctl(unsigned int, void __user *);
extern void x25_route_free(void);
static __inline__ void x25_route_hold(struct x25_route *rt)
{
atomic_inc(&rt->refcnt);
}
static __inline__ void x25_route_put(struct x25_route *rt)
{
if (atomic_dec_and_test(&rt->refcnt))
kfree(rt);
}
/* x25_subr.c */
extern void x25_clear_queues(struct sock *);
extern void x25_frames_acked(struct sock *, unsigned short);
extern void x25_requeue_frames(struct sock *);
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);
/* x25_timer.c */
[X25]: proper prototype for x25_init_timers() This patch adds a proper prototype for x25_init_timers() in include/net/x25.h Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-01-04 03:48:13 +01:00
extern void x25_init_timers(struct sock *sk);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
extern void x25_start_heartbeat(struct sock *);
extern void x25_start_t2timer(struct sock *);
extern void x25_start_t21timer(struct sock *);
extern void x25_start_t22timer(struct sock *);
extern void x25_start_t23timer(struct sock *);
extern void x25_stop_heartbeat(struct sock *);
extern void x25_stop_timer(struct sock *);
extern unsigned long x25_display_timer(struct sock *);
extern void x25_check_rbuf(struct sock *);
/* sysctl_net_x25.c */
extern void x25_register_sysctl(void);
extern void x25_unregister_sysctl(void);
struct x25_skb_cb {
unsigned flags;
};
#define X25_SKB_CB(s) ((struct x25_skb_cb *) ((s)->cb))
extern struct hlist_head x25_list;
extern rwlock_t x25_list_lock;
extern struct list_head x25_route_list;
extern rwlock_t x25_route_list_lock;
[X.25]: Add call forwarding Adds call forwarding to X.25, allowing it to operate like an X.25 router. Useful if one needs to manipulate X.25 traffic with tools like tc. This is an update/cleanup based off a patch submitted by Daniel Ferenci a few years ago. Thanks Alan for the feedback. Added the null check to the clones. Moved the skb_clone's into the forwarding functions. Worked ok with Cisco XoT, linux X.25 back to back, and some old NTUs/PADs. Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-08 22:34:02 +01:00
extern struct list_head x25_forward_list;
extern rwlock_t x25_forward_list_lock;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
extern int x25_proc_init(void);
extern void x25_proc_exit(void);
#endif
Reference in a new issue Copy permalink