Bug#783160: Further detail
Hello everyone, also if it should be already known, also Fedora21 AX25 implementation is affected (Fedora 21, kernel 3.19.5-200.fc21.i686). Exactly the same behavior More details if required Regards UP
Bug#783160: Duplication packets grave issue further details
Hello everyone, I made several tests about this bug, still trying to reduce the magnitude of the problem. For reducing noise I used some Debian virtual machines set-up on Oracle VirtualBox and on QEMU, avoiding the use of real radio link and adopting both SOCAT connections and VirtualBox com0com serial pipes as basis of the kissattach. I can confirm that the duplication problem is always there in all the following configurations : Debian Wheezy 64bits up-to-date (3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64) Debian Wheezy 32bits up-to-date (3.2.0-4-486 #1 Debian 3.2.68-1+deb7u1 i686 GNU/Linux) Raspbian on real RaspberryPIb+ up-to-date (Linux 3.18.12+ #780 PREEMPT Mon Apr 20 14:46:05 BST 2015 armv6l GNU/Linux) . and last but not least : Debian Jessie 32bits installed yesterday (3.16.0-4-586 #1 Debian 3.16.7-ckt9-3~deb8u1) After a preliminary check made by Richard Stearn (G1SOG), who is meritoriously dedicating a lot of time to this issue and who will report asap his data, it seems that a regression happened among kernel 2.4.29 (where the problem is not there) and 2.6.33.3 (where the problem is already present). You can find the capture files related to the test over Jessie at this link (valid till May, 11st) : http://we.tl/Wg4arIkaBG Buy the way, analyzing the problem I would like to recommend you to test the case where the ICMP payload it's greater than the normal MTU (256 bytes) : the ICMP answers are quite interesting in this case. I'm at your disposal for any further need. Let me know if I have to open also this bug report on the libAX25 bug report log. cheer 73, Ugo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783160: ax25-tools: The most part of IP-over-AX25 outbound packets (e.g. ICMP requests) are sent duplicated
Hello Thomas, Thank-you for your kind answer. As described above (but you can check also the .pcap files that I attached : http://we.tl/z2XuajAbqJ) I'm using AX25-UI for transferring IP. In any case the duplication problem is still there also using VC (I can provide to you a sniffing). Regarding using VC in place of DG for TCP : I'm not happy to replicate twice the data integrity function (AX25-CM and TCP)..it sounds quite incorrect.isn't it ? Ax0 configuration : ax25_default_mode = 0 backoff_type = 1 connect_mode = 2 extended_window_size = 32 idle_timeout = 0 ip_default_mode = 0 maximum_packet_length = 256 maximum_retry_count = 2 protocol = 0 standard_window_size = 2 t1 = 1 t2 = 3000 t3 = 30 73, Ugo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783160: ax25-tools: The most part of IP-over-AX25 outbound packets (e.g. ICMP requests) are sent duplicated
Package: ax25-tools Version: 0.0.10-rc2+cvs20120204-3 Justification: renders package unusable Severity: grave Dear Maintainer, * What led up to the situation? During a simple IP-over-AX25 activity (1200 baud) I found high number of TCP errors (duplicated, out of sequence ). The detailed analysis shows that the most part of packet are sent twice. In the attachment you can find a sniffing pcap file showing a simple case of an ICMP request. The problem affects Wheezie versions both on 32 and 64bits machines and also over Raspbian. In the attachment you will see two sniffing files related to the same simple ICMP exchange (one hop) : 7 pings of 100 bytes (less then the MTU, that is 256) spaced of 10 sec (-i 10 -s 100). What I found strange its that each ping seems to be duplicated in two requests (same checksum both at IP and TCP level) : for example (see ax0) frame 1 and frame 2 , frames 5 and 6, frames 9 and 20 and so on. The effects are : Ø That the ICMP seems unable to match request and answer Ø That a multiple useless transmissions are generated (there are a huge number of duplicated and out-of-order TCP packets in a real transmission, FTP or telnet ) Ø Im afraid also that the stack incorrectly calculated window and smoothed average bit rate (but not sure) * What exactly did you do (or not do) that was effective (or ineffective)? Im working with the default settings. Using alternative ax25 stack (Lin-BPQ) on the same machines show a normal situation (ICMP request not duplicated) -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) (but also on 64bits or Raspbian machine) Kernel: Linux 3.2.0-4-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ax25-tools depends on: ii libax25 0.0.12-rc2+cvs20120204-2 ii libc62.13-38+deb7u8 ii zlib1g 1:1.2.7.dfsg-13 ax25-tools recommends no packages. Versions of packages ax25-tools suggests: pn ax25-apps none pn talkd none -- no debconf information Regards, 73 Ugo
