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
