Control: tags -1 + moreinfo Hi, On Thu, Apr 23, 2015 at 08:57:00AM +0200, Ugo Poddine su Gmail wrote: > Justification: renders package unusable > Severity: grave I don't agree with this assessment. I've successfully used ax25-tools for TCP/IP to load images over HTTP on a 1200 baud link, and so the package is not unusable. You appear to be using a mail client that did not format the email correctly and so the default severity of normal was used instead, I think normal is the appropriate severity for this bug. > 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. Yes, I've seen similar duplications of TCP packets, but I assumed it was due to TCP retransmissions and not a problem with the AX.25 stack. This is something I'm currently investigating when I have the time. > In the attachment you can find a “sniffing” pcap file showing a simple > case of an ICMP request. It looks like the attachment was dropped by the bug system. I don't believe it likes binary attachments. Could you upload your trace to a webserver and provide the URL? > 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 it’s 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. It is possible that tcpdump is capturing the packets both when they enter and leave the interface and so the capture is happening twice. Is it possible for you to determine whether or not these packets are in fact duplicated on-the-air? > Ø That the ICMP seems unable to match request and answer I've not noticed this problem. Can you expand on this? > Ø 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…) For TCP, I believe this is a problem with the Linux kernel now having an initial congestion window value of 10 instead of the old value of 3. It is possible to change the inital congestion window value on a per-route basis as well as the minimum TCP RTO value. ip route change 44.0.0.0/8 dev ax0 initcwnd 1 rto_min 10s I am still playing with these values to find an optimal set of values to use. > Ø I’m afraid also that the stack incorrectly calculated window and > smoothed average bit rate (but not sure) I'm not sure if you're referring to the problems with TCP I've mentioned above or if this refers to another problem. What do you mean by "the stack"? > I’m working with the default settings. Are you using a software or hardware TNC? Which one? > Using alternative ax25 stack (Lin-BPQ) on the same machines show a > normal situation (ICMP request not duplicated) ax25-tools makes use of the kernel's AX.25 implementation. I'm not familiar with Lin-BPQ but will have to take a look to see what is happening here that makes it different. Thanks, Iain. -- e: irl@fsfe.org w: iain.learmonth.me x: irl@jabber.fsfe.org t: EPVPN 2105 c: 2M0STB g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49
Attachment:
pgpLEtzi7ebq4.pgp
Description: PGP signature