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
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_
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
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 sens
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_
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 retu
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), differ
> 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, accept
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 (E
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 dat
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 (
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 whi
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
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
p
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
15 matches
Mail list logo
