AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Tihomir Heidelberg - 9a4gl]

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

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Hamish Moffatt]

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

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.

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

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 <hamish@debian.org> <hamish@cloud.net.au>

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Tihomir Heidelberg - 9a4gl]

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

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Hamish Moffatt]

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 <hamish@debian.org> <hamish@cloud.net.au>

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Tihomir Heidelberg - 9a4gl]

Hi,

Hamish Moffatt wrote:
> 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, 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.
> 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.
>   

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

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Dave Platt]

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

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Tihomir Heidelberg - 9a4gl]

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

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Hamish Moffatt]

On Mon, Oct 08, 2007 at 04:53:10PM +0200, Tihomir Heidelberg - 9a4gl wrote:
> Hi,
> 
> Hamish Moffatt wrote:
> > 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, 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.

Yes I meant socket(2).

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

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Dave Platt]

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

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Chris Kantarjiev]

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

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Dave Platt]

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.

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Tihomir Heidelberg - 9a4gl]

Hi,

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.

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

[BUG] [AX25] in libax25

[Bernard Pidoux F6BVP]

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

Re: [BUG] [AX25] in libax25

[Matti Aarnio]

On Tue, Feb 12, 2008 at 11:40:27AM +0100, Bernard Pidoux F6BVP wrote:
> 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

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

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

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

> 73 de Bernard, f6bvp

73 de Matti, OH2MQK

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Hamish Moffatt]

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 <hamish@debian.org> <hamish@cloud.net.au>

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Ralf Baechle DL5RB]

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 89aebaffff7545d7a2947e2f8f5fdee70f841c14 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: DL5RB@DB0FHN.#BAY.DEU.EU

From 89aebaffff7545d7a2947e2f8f5fdee70f841c14 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <shemminger@osdl.org>
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;

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Tihomir Heidelberg - 9a4gl]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Stephen Hemminger]

On Mon, 8 Oct 2007 11:45:41 +0100
Ralf Baechle DL5RB <ralf@linux-mips.org> 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 <shemminger@linux-foundation.org>