Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
On Sun, Oct 07, 2007 at 09:58:06PM +0200, Tihomir Heidelberg - 9a4gl wrote:
Hi ax25 developers,
Using kernel 2.6.21.6 here. If you write to AX.25 socket bytes more then
MTU, write will return -1 and errno will be set to 90 (EMSGSIZE =
[Message too long]).
This happend in net/ax25/af_ax25.c in function ax25_sendmsg at:
if (len ax25-ax25_dev-dev-mtu) {
err = -EMSGSIZE;
goto out;
}
The change seems to be requested here:
http://oss.sgi.com/archives/netdev/2004-01/msg00097.html
with the rationale that there is no fragmentation logic, as I suggested
in my other followup (which hasn't arrived back here yet...)
Hamish
--
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-hams in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
On Sun, Oct 07, 2007 at 09:58:06PM +0200, Tihomir Heidelberg - 9a4gl wrote:
Using kernel 2.6.21.6 here. If you write to AX.25 socket bytes more then
MTU, write will return -1 and errno will be set to 90 (EMSGSIZE =
[Message too long]).
This happend in net/ax25/af_ax25.c in function ax25_sendmsg at:
if (len ax25-ax25_dev-dev-mtu) {
err = -EMSGSIZE;
goto out;
}
This is a Linux 2.6.2 change, I append the patch which introduced the
change below. I'm cc'ing Stephen Hemminger who hopefully recalls why his
patch did introduce this change.
(git users: commit id is 89aeba7545d7a2947e2f8f5fdee70f841c14 which is
only available in tglx's history tree on kernel.org)
Old kernels, 2.2.x and 2.4.x accepted write with data length larger then
MTU and for SOCK_SEQPACKET sockets the ax25_output function did the
fragmentation job.
According to man 2 write, write should return number of bytes written.
I think that:
1. ax25_sendmsg should accept data larger then mtu and pass the data to
ax25_output.
2. ax25_output should do fragmentation and queue frames into device queue.
3. ax25_output should stop fragmenting when device queue is full
4. ax25_output should return number of bytes queued on device
5. ax25_sendmsg should return number of bytes accepted for xmiting
Agreed.
Also, as I see, currently ax25 stack is not checking if dev_queue_xmit
fails. Does this means that AX.25 kernel can loose some frames when
device queue is full ?
Yes. This isn't a bug - packet delivery is unreliable. But what I'd
really like to see is the AX.25 stack to throttle itself instead of
continuing to stuff packets into an overflowing queue.
By the way, this problem is having OpenBCM V1.07b3, very popular BBS
software (http://dnx274.dyndns.org/baybox/) which writes as much data as
it prepared.
73 de Tihomir Heidelberg, 9a4gl(_a_t_)hamradio(d_o_t)hr
73 de DL5RB op Ralf
--
Loc.JN47BS / CQ 14 / ITU 28 / DOK A21
Packet: [EMAIL PROTECTED]
From 89aeba7545d7a2947e2f8f5fdee70f841c14 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 8 Jan 2004 09:53:15 -0800
Subject: [PATCH] [AX25]: Use size_t for size in {send,recv}msg.
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 4fb1519..43472c6 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1401,7 +1401,7 @@ out:
}
static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *msg, int len)
+ struct msghdr *msg, size_t len)
{
struct sockaddr_ax25 *usax = (struct sockaddr_ax25 *)msg-msg_name;
struct sock *sk = sock-sk;
@@ -1410,7 +1410,8 @@ static int ax25_sendmsg(struct kiocb *iocb, struct socket
*sock,
ax25_digi dtmp, *dp;
unsigned char *asmptr;
ax25_cb *ax25;
- int lv, size, err, addr_len = msg-msg_namelen;
+ size_t size;
+ int lv, err, addr_len = msg-msg_namelen;
if (msg-msg_flags ~(MSG_DONTWAIT|MSG_EOR)) {
return -EINVAL;
@@ -1435,6 +1436,11 @@ static int ax25_sendmsg(struct kiocb *iocb, struct
socket *sock,
goto out;
}
+ if (len ax25-ax25_dev-dev-mtu) {
+ err = -EMSGSIZE;
+ goto out;
+ }
+
if (usax != NULL) {
if (usax-sax25_family != AF_AX25) {
err = -EINVAL;
@@ -1580,7 +1586,7 @@ out:
}
static int ax25_recvmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *msg, int size, int flags)
+ struct msghdr *msg, size_t size, int flags)
{
struct sock *sk = sock-sk;
struct sk_buff *skb;
-
To unsubscribe from this list: send the line unsubscribe linux-hams in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
Hi, Hamish Moffatt wrote: On Sun, Oct 07, 2007 at 09:58:06PM +0200, Tihomir Heidelberg - 9a4gl wrote: Using kernel 2.6.21.6 here. If you write to AX.25 socket bytes more then MTU, write will return -1 and errno will be set to 90 (EMSGSIZE = [Message too long]). Is it sensible to fragment raw AX.25 packets? I think that would depend on what the next layer protocol is. For APRS, each packet is significant (ie it's datagram rather than stream oriented) so fragmenting a packet would not be correct. No, only SOCK_SEQPACKET should be fragmented. APRS is using SOCK_DGRAM and in most cases SOCK_DGRAM should not be fragmented, but I think we should leave that to application. Comparing to IP world, TCP sockets may survive additional fragmentation, but UDP maybe. By the way, this problem is having OpenBCM V1.07b3 In your application (the other end of call, for example?) the packets may just be a stream and therefore fragmenting at arbitrary points would be ok. Although SOCK_SEQPACKET doesn't sound right in that case. Hm, you mean I should use SOCK_STREAM ? As I see that kind of socket is not supported in AX.25 stack, right ? When it would be, then it makes sense to fragment for SOCK_STREAM and return EMSGSIZE for SOCK_SEQPACKET. Hamish Moffatt wrote: The change seems to be requested here: http://oss.sgi.com/archives/netdev/2004-01/msg00097.html with the rationale that there is no fragmentation logic, as I suggested in my other followup (which hasn't arrived back here yet...) But, we do have fragmentation logic in ax25_output. 73 de Tihomir, 9a4gl - To unsubscribe from this list: send the line unsubscribe linux-hams in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
Hi, Ralf Baechle DL5RB wrote: I think that: 1. ax25_sendmsg should accept data larger then mtu and pass the data to ax25_output. 2. ax25_output should do fragmentation and queue frames into device queue. 3. ax25_output should stop fragmenting when device queue is full 4. ax25_output should return number of bytes queued on device 5. ax25_sendmsg should return number of bytes accepted for xmiting Agreed. Great. Who is going to fix this ? :) Also, as I see, currently ax25 stack is not checking if dev_queue_xmit fails. Does this means that AX.25 kernel can loose some frames when device queue is full ? Yes. This isn't a bug - packet delivery is unreliable. But what I'd really like to see is the AX.25 stack to throttle itself instead of continuing to stuff packets into an overflowing queue. Hm, AX.25 connection is unrealible, why ? Shouldn't it be reliable ? Throttle ? You mean write would block or will return EAGAIN in non-blocking mode ? That would be nice. By the way, who is ax25 stack maintainer ? I did some work on AX.25 stack to support AX.25 frame extension needed for node software which needs to be compatible with SuperVozelj node by Matjaž Vidmar, S53MV. This node is very popular in Slovenia, Italy and Croatia. I can prepare patch, the SuperVozelj compatibility will be enabled/disabled in Linux kernel configuration, and if enabled do not affect other applications. Where to send the patch and who is doing code review ? 73 de Tihomir, 9a4gl - To unsubscribe from this list: send the line unsubscribe linux-hams in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
On Mon, Oct 08, 2007 at 01:10:45PM +0200, Tihomir Heidelberg - 9a4gl wrote: Hi, Hamish Moffatt wrote: On Sun, Oct 07, 2007 at 09:58:06PM +0200, Tihomir Heidelberg - 9a4gl wrote: Using kernel 2.6.21.6 here. If you write to AX.25 socket bytes more then MTU, write will return -1 and errno will be set to 90 (EMSGSIZE = [Message too long]). Is it sensible to fragment raw AX.25 packets? I think that would depend on what the next layer protocol is. For APRS, each packet is significant (ie it's datagram rather than stream oriented) so fragmenting a packet would not be correct. No, only SOCK_SEQPACKET should be fragmented. APRS is using SOCK_DGRAM and in most cases SOCK_DGRAM should not be fragmented, but I think we socket(7) doesn't make any distinction between SOCK_DGRAM and SOCK_SEQPACKET with regard to fragmentation. SOCK_SEQPACKET just adds reliability and order. Hm, you mean I should use SOCK_STREAM ? As I see that kind of socket is not supported in AX.25 stack, right ? When it would be, then it makes sense to fragment for SOCK_STREAM and return EMSGSIZE for SOCK_SEQPACKET. Yes, except that it doesn't exactly make sense to have streams on a raw socket (which is I guess why they are not supported for AX.25). Streams would be implemented by the transport layer and above, which is above what a raw socket provides. Hamish Moffatt wrote: The change seems to be requested here: http://oss.sgi.com/archives/netdev/2004-01/msg00097.html with the rationale that there is no fragmentation logic, as I suggested in my other followup (which hasn't arrived back here yet...) But, we do have fragmentation logic in ax25_output. So I see. I could not turn up a standard for this on Google. Perhaps I am wrong.. Ralf seems to agree with you and so I defer to his judgement. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-hams in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
Hm, as I see AX.25 sockets supports SOCK_DGRAM, SOCK_SEQPACKET and SOCK_RAW. I am not talking about raw and I am not using raw socket. IMHO, users of raw sockets should be aware of MTU and I would not fragment raw sockets in kernel. What I want is to have SOCK_SEQPACKET reliable, accepting any amount of data and on write returning number of bytes accepted. I do not care much if fragmentation will take place or not, but currently I do not see any reason why not. As I understand it, SOCK_SEQPACKET is intended to be used in protocols where the packet-to-packet boundary is significant - that is, each packet is supposed to be interpreted as a whole entity, and the packet length is significant to the application. It is probably not a transport method which should be fragmented by the lower layers of the protocol stack, unless the stack can reassemble the fragments into a single packet of the correct boundary and size before presenting it to the application at the receiving end. For the same reason, it's probably appropriate for the kernel to return a size exceeds MTU error, rather than writing as much as it can and returning MTU to the application, since this would fragment the packet and thus violate the intended semantics of SOCK_SEQPACKET. It is more usual to use SOCK_STREAM to establish connections, in which you wish to write arbitrary amounts of data across the connection, and don't care whether the data is received in precisely the same chunk-sizes as it was written. Fragmentation of SOCK_STREAM data is fine... but it's probably best done by the protocol layers up above the raw-packet level, by the same code which does flow control and packet acknowledgement. Applications which wish to use SOCK_SEQPACKET rather than SOCK_STREAM, but wish to write arbitrary amounts of data... well, I'm not certain why they would wish to do this, but if they do they should probably query the MTU value out of the network interface/stack, and limit their write() calls to that amount of data, just as they would have to do if they were using SOCK_DGRAM. That's my $.02 worth :-) - To unsubscribe from this list: send the line unsubscribe linux-hams in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
On Mon, 8 Oct 2007 11:45:41 +0100
Ralf Baechle DL5RB [EMAIL PROTECTED] wrote:
On Sun, Oct 07, 2007 at 09:58:06PM +0200, Tihomir Heidelberg - 9a4gl wrote:
Using kernel 2.6.21.6 here. If you write to AX.25 socket bytes more then
MTU, write will return -1 and errno will be set to 90 (EMSGSIZE =
[Message too long]).
This happend in net/ax25/af_ax25.c in function ax25_sendmsg at:
if (len ax25-ax25_dev-dev-mtu) {
err = -EMSGSIZE;
goto out;
}
This is a Linux 2.6.2 change, I append the patch which introduced the
change below. I'm cc'ing Stephen Hemminger who hopefully recalls why his
patch did introduce this change.
I have no memory of adding this, as long as lower layers handle it
the check should be there.
Also, as I see, currently ax25 stack is not checking if dev_queue_xmit
fails. Does this means that AX.25 kernel can loose some frames when
device queue is full ?
Yes. This isn't a bug - packet delivery is unreliable. But what I'd
really like to see is the AX.25 stack to throttle itself instead of
continuing to stuff packets into an overflowing queue.
The traditional definition of X.25 was reliable (except for network
resets), so it seems odd that AX.25 would change that. It might be that
AX.25 doesn't really implement traditional X.25 but just uses the formatting
and framing??
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-hams in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
Hi, Dave Platt wrote: It is more usual to use SOCK_STREAM to establish connections, in which you wish to write arbitrary amounts of data across the connection, and don't care whether the data is received in precisely the same chunk-sizes as it was written. Fragmentation of SOCK_STREAM data is fine... but it's probably best done by the protocol layers up above the raw-packet level, by the same code which does flow control and packet acknowledgement. Yes, but we do not have SOCK_STREAM for AX.25 :-( Applications which wish to use SOCK_SEQPACKET rather than SOCK_STREAM, but wish to write arbitrary amounts of data... well, I'm not certain why they would wish to do this, but if they do they should probably query the MTU value out of the network interface/stack, and limit their write() calls to that amount of data, just as they would have to do if they were using SOCK_DGRAM. I think that in AX.25 world there is no real situation for SOCK_SEQPACKET, because any node in chain may have lower MTU and can fragment your frame and you do not have any guarantee that packet will reach end as you sent it. So you just define what will be in first hop. Actually, you always have stream. Anyway, why checking MTU, why not PACLEN ? Because PACLEN is the one which limits maximum length of frame, not MTU ! Right ? 73 de Tihomir Heidelberg, 9a4gl - To unsubscribe from this list: send the line unsubscribe linux-hams in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
What I want is to have SOCK_SEQPACKET reliable, accepting any amount of data and on write returning number of bytes accepted. I do not care much if fragmentation will take place or not, but currently I do not see any reason why not. I think you want SOCK_STREAM. You just want a byte stream which is arbitrarily split into packets; SOCK_DGRAM and SEQPACKET are intended for applications which care about packet boundaries. Since SOCK_STREAM is apparently not so different from SOCK_SEQPACKET, perhaps you could implement it for AX.25? I agree, that's probably the cleanest approach, and it ought not to be very much work at all within the AX.25 layer. On reading through the various man pages and looking at the code, I'm frankly not sure why the Linux AX.25 implemented SOCK_SEQPACKET and not SOCK_STREAM. It looks to me as if the only substantial differences between these two connection types are: - SOCK_STREAM is intended to allow writes of arbitrary amounts of data, and does not guarantee that the reader of the data received it in pieces whose boundaries correspond to those given by the writer. All of the data is guaranteed to be delivered, reliably and in sequence, or the connection will be broken. - SOCK_SEQPACKET is *not* defined to allow writes of arbitrarily large sizes... it's specifically defined to limit writes to a fixed maximum size (with the maximum size being connection-dependent, apparently). Packets are guaranteed to get through the connection, reliably and in sequence, and the reader is guaranteed that each read will return data from precisely one sender-packet (i.e. if the network fragments them, the fragments must be reassembled before any of the data can be delivered). If the reader requests less data than is present in an incoming packet, the reader gets only the amount asked for, and the remainder is discarded (!) rather than being delivered during a subsequent read. These two methods use the same APIs, and should both be able to run over AX.25 I packets. I *think* that adding SEQ_STREAM to the AX.25 code, in addition to SEQ_SEQPACKET in each of the places that it appears, would do most of the work in adding support for this protocol. As far as re-enabling packet fragmentation in the AX.25 packet layer... seems to me that it would be legitimate to do so as long as the lower-level code does the fragmentation properly (i.e. breaking the write into small-enough chunks to fit within the path's maximum frame length limit) and as long as the receiving code does the reassembly properly. Any app which uses SOCK_SEQPACKET, and wants to be able to write arbitrarily-large amounts of data, had better be *very* sure that its peer is issuing reads which are large enough to swallow the largest-possible write! Otherwise, data will be lost (according to the semantics for SOCK_SEQPACKET). That's why I'd favor using SOCK_STREAM for AX.25 connections (just as TCP uses SOCK_STREAM) - there's no requirement with SOCK_STREAM that the sender and receiver coordinate on the size of the largest write operation. This would seem to ease the software compatibility problem quite a bit! - To unsubscribe from this list: send the line unsubscribe linux-hams in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !
Chris Kantarjiev wrote: That's why I'd favor using SOCK_STREAM for AX.25 connections (just as TCP uses SOCK_STREAM) - there's no requirement with SOCK_STREAM that the sender and receiver coordinate on the size of the largest write operation. This would seem to ease the software compatibility problem quite a bit! But TCP is a reliable stream, without internal record delimeters. SOCK_SEQPACKET is meant to retain the record delimiters and make them visible to the endpoints. So it depends entirely on what the application level is trying to do. Quite right! I think that there are plenty of places for both sorts of protocols. I do think that having SOCK_STREAM available for AX.25 would be a good idea. It would make it easier for TCP-based applications to be ported over to AX.25. - To unsubscribe from this list: send the line unsubscribe linux-hams in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
