AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

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;
        }

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

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 ?

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

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. For IP it's obviously allowed although you wouldn't be using an AX.25 socket then.

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.

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

Hi,

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.

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.

But, we do have fragmentation logic in ax25_output.

73 de Tihomir, 9a4gl

socket(7) doesn't make any distinction between SOCK_DGRAM and SOCK_SEQPACKET with regard to fragmentation. SOCK_SEQPACKET just adds reliability and order.

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.

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]>

Hi,

Hm, socket(2) or (7) ? Both documents do not mention fragmentation. But, according to socket(2), difference between SOCK_STREAM and SOCK_SEQPACKET is that first one supports out-of-band data which is not (easy) doable in AX.25 world. So, it is ok to use SOCK_SEQPACKET for what we/I call AX.25 connection.

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.

73 de Tihomir Heidelberg, 9a4gl

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 :-)

Hi,

Yes, but we do not have SOCK_STREAM for AX.25 :-(

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

Yes I meant socket(2).

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?

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

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!

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.

Hi,

In TCP there ARE some kind of record delimiters, the PUSH flags. Take a look n RFC793 at chapter 2.8. It is probably not used to implement fragmented SOCK_SEQPACKET because it is not guaranteed that receiver will get whole packet, but only that the end of the packet will not finish somewhere in middle of some data. Also, a lot of TCP stacks used (especially in embedded devices) do not support usage of PUSH flag.

What I wanted to say, AX.25 protocol is not capable of doing SOCK_SEQPACKET because any node in chain can split packet due to lower paclen, so SOCK_STREAM is only doable in AX.25 world. Before 2.6.2 we had SOCK_STREAM behavior, but it was named as SOCK_SEQPACKET. After 2.6.2 we have SOCK_SEQPACKET that behaves like somewhere between :)

I agree with Dave that adding SOCK_STREAM will solve this problem and then we have a bit compatibility issue.

73 de Tihomir Heidelberg, 9a4gl

Hi,

I found a bug in libax25./proc/net/rose_neigh "use" field not read by read_proc_rs_neigh and was missing in struct declaration.

For ROSE FPAC application development with 2.6 kernel I needed to check 'restart' in rose_neigh and found that it was not correctly read by the library.I was getting 'mode' state instead of 'restart. This was because 'use' field was not taken into account. Of course, t0 and tf timers were
also no read correctly.

Here is an extract of ChangeLog file.

libax25 0.0.11.4
* BUG in procutils.h and procutils.c
in structure proc_rs_neigh field "use" was missing, in function read_proc_rs_neigh proc_rs_neigh use was not read, corrected.

Patched libax25 package can be downloaded from here :

http://f6bvp.free.fr/logiciels/ax25/libax25-0.0.11.4src_f6bvp.tgz

After compiling new libraries, AX25 applications must be re-compiled too and restarted in order to take into account the newly built libax25.

73 de Bernard, f6bvp

I merged your fix to my libax25 changes:

http://ham.zmailer.org/oh2mqk/libax25/libax25-0.0.13-6.tar.gz

the package is buildable in RPM systems with command:

rpmbuild -tb libax25-0.0.13-6.tar.gz

and something similar in Debian systems.

I did rewrite the ax25_config_load_ports() (and nr- and rose-versions too) so that there is no longer mandatory need to have IP addresses in interfaces, and those functions still find all AX25/NETROM/ROSE ports that system has.

I have in that same directory also ax25-tools where kissattach does not mandate IP address, and mkiss has changed radically -- not that I have had opportunity to test the mkiss properly. (mkiss uses dynamic pty:s and forks individual kissattach commands for demuxed sub-interfaces.)

.. unless they are dynamically linked, where just restart is enough after rebuilt library is installed.

73 de Matti, OH2MQK

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]>

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 89aebaffff7545d7a2947e2f8f5fdee70f841c14 which is only available in tglx's history tree on kernel.org)

Agreed.

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.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21
Packet: DL5RB@DB0FHN.#BAY.DEU.EU

From 89aebaffff7545d7a2947e2f8f5fdee70f841c14 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.

index 4fb1519..43472c6 100644
@@ -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;

Hi,

Great. Who is going to fix this ? :)

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

I have no memory of adding this, as long as lower layers handle it the check should be there.

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]>