[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#783160: R: Bug#783160: ax25-tools: The most part of IP-over-AX25 outbound packets (e.g. ICMP requests) are sent duplicated



Hello Iain and Brian,

I've just read the answer of Brian (Brian Rogers - N1URO), sorry for the delay in answering.
First of all I'm not sure that Brian was able to see the "sniffing" files : I have sent them directly to Ian also in form of link, but I see that he doesn’t download them.
The link is in anycase at http://we.tl/z2XuajAbqJ expiring on April 30. The sniffing were got using the following statement : tcpdump -w <file>.pcap -i ax0 on transmitting side.
>From the sniffing it's easy to see that I was using AX25-UI / datagram mode.
But I'm a bit surprised reading the answer of Brian, when he wrote that " IP over RF works best in a virtual circuit mode" for different reasons :

a) first of all, for theoretical reasons : if we use TCP over AX25, the layer responsible of data integrity and retransmissions is surely TCP (OSI4). This also if the protocol responsible for data integrity is NET-ROM or DTN. AX25-CM is practically, for historic reasons and due to his age - implementing features that are typical of OSI3 and OSI4, but we need to use it only as OSI2 if specialized "upper level" protocols are used (again : TCP, NET-ROM, DTN...). It's not correct (and can generated probably several problems : windows calculation, TTL, Nagle effects...) making redundant the data integrity function !
b) the most part of (known) consolidated TCP-over-AX25 implementations uses AX25-UI as pure Layer2 protocols (e.g. Flexnet, some Italian experiences or several US implementations as described in 2006 tapr.org conversations or on 2008 gmane.linux.hams for California networks : I can share with you the bibliography, avoiding the Italian one :-) ), and I supposed it was a consolidated scenario...
c) LinBPQ / BPQ32 TCP-IP over ax25 UI connection works as expected without any special problem : if you need I can send to you the same SSH/telnet conversation  that I sniffed and attached, replicated over Lin-BPQ (using normal BPQ settings - datagram mode under TCP) : it sounds surely better... 
d) Last but not least, on my opinion, the problem that I have raised it's in any case not dependent to the choice CM / datagram mode. If you check the "ax25" sniffing the duplication happens well before the data transmission ! Each ICMP ping request is duplicated at source BOTH if the stack is set as UI and if it's set as CM... and also if the system is not transmitting at all because it's detached (that is : Debian + soundmodem whatever + soundcard, nothing else).

Thank-you for your help, in any case. Please feel free to ask any further data I can provide.
Cheer
73, IZ1YPS-Ugo

PS : on my opinion the severity of the problem is still "grave", in any case ;-) 







Iain et al;

Like with xNOS, the TCP MSS needs to be set per interface, also Ugo
doesn't specify which mode he's using (VC vs. DG) The "out of sequence"
frames may be caused by using datagram mode instead of virtual circuit
mode. IP over RF works best in a virtual circuit mode which is what
NetRom uses as well. Datagram mode often can (and will) drop frames thus
making them appear "out of order".

With a properly set interface, the ip window will auto-adjust within the
maximum limit specified within the parameters of the interface. While
finding the setting is a bit obscure IMHO, it can be done.

>From the URONode at tapr.org mail list:
iptables -t mangle -A POSTROUTING -o <interface> -p tcp --tcp-flags
SYN,RST SYN  -j TCPMSS --set-mss 216

Since your send is outbound only, this is fine. Your interfaces for the
above would be for a standard ax25 only interface (ie: ax0/ax1/etc). For
a NetRom interface (ie: nr0/nr1/etc) subtract another 20 from the ending
216 to make room for the protocol headers of NetRom. Repeat the above
for UDP if required.

Iain, I can have a discussion with you offlist re: LinBPQ if you wish
and save you some time.

-- 
The most difficult egg to beat is one that is hard boiled.

73 de Brian Rogers - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.net
http://axmail.sourceforge.net


Reply to: