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
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
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
Joe Veldhuis [EMAIL PROTECTED] wrote:
I have soundmodem working for the most part. It decodes and encodes just
fine except for one problem: when I enable PTT control through the
serial port, it keys the rig whenever it starts decoding. This makes it
impossible to recieve anything, and also
I have a problem with a really near 430Mz transmitter (my own) that is
breaking though to the TV. The Transmitter isn't off tune and as far as I
Know or can see, it isn't producing any side transmissions or birdies.
I had similar problems with my 2-meter transmissions affecting all the TVs
A little off topic for the list, I know, but why can you understand a
manufacturer not releasing driver sources?
a) The driver sources are no good unless you already have the hardware
b) A manufacturer *SHOULD* want to allow people to use their hardware
Therefore, it's in *EVERY*
