Hallo all I've found an old thread about IP over AX25 packets duplicated (you can find in the bottom some details of your interesting answer)
I can confirm that the problem is still present now in the last Raspbian kernel 4.9.59-v7+ (Raspberry Debian) with: - ax25-apps 0.0.8-rc4-2 - ax25-node 0.3.2-7.4 - ax25-tools 0.0.10-rc4-1 - libax25 0.0.12-rc4-1 from the official respository with apt-get. I can also confirm that problem was non present on older Linux kernel (2.4.xx, i used since 2005. Here is my simple Raspbian PING test results with axlisten -a (there are only the tx packets) Take notes of the interesting second test via DIGI... packet are not simple duplicated but also the first one has the radio calls inverted. Are there any news or possibile solutions? Is there anyone could explain better if is possibile to patch and recompile also the current kernel and send me some suggestions? thanks in advance 73 de Lorenzo iw3her -------------- ping FROM IW3HER (44.134.177.45) TO IR3IP ( 44.134.177.204) first TEST: DIRECT CALL (NO DIGI) sp0: fm IW3HER-14 to IR3IP ctl UI pid=CC(IP) len 84 IP: len 84 44.134.177.45->44.134.177.204 ihl 20 ttl 64 DF prot ICMP ICMP: type Echo Request id 2522 seq 1 0000 �7.Zy�.......................... !"#$%&'()*+,-./01234567 sp0: fm IW3HER-14 to IR3IP ctl UI pid=CC(IP) len 84 IP: len 84 44.134.177.45->44.134.177.204 ihl 20 ttl 64 DF prot ICMP ICMP: type Echo Request id 2522 seq 1 0000 �7.Zy�.......................... !"#$%&'()*+,-./01234567 second TEST: CALL VIA DIGI: Setting route via IR3UDZ: sudo axparms -route add sp0 IR3IP IR3UDZ pi@iw3her:~ $ sudo axparms -route list callsign dev mode digipeaters IR3IP-0 sp0 * IR3UDZ-0 PING sp0: fm IR3UDZ to IW3HER-14 ctl UI pid=CC(IP) len 84 IP: len 84 44.134.177.45->44.134.177.204 ihl 20 ttl 64 DF prot ICMP ICMP: type Echo Request id 2503 seq 1 0000 .7.Zpa.......................... !"#$%&'()*+,-./01234567 sp0: fm IW3HER-14 to IR3IP via IR3UDZ ctl UI^ pid=CC(IP) len 84 IP: len 84 44.134.177.45->44.134.177.204 ihl 20 ttl 64 DF prot ICMP ICMP: type Echo Request id 2503 seq 1 0000 .7.Zpa.......................... !"#$%&'()*+,-./01234567 ---------------- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783160 From: Richard Stearn <rich...@rns-stearn.demon.co.uk> To: 783...@bugs.debian.org Subject: Results of my investigations into this packet "duplication" Date: Wed, 10 Jun 2015 20:03:01 +0100 A mildly edited copy of my post to the linux-hams mailing list. --------------------------------------------------------------- I think I have got to the bottom of this issue. The good news is that it is not a bug in the AX25 protocol or driver code, the bad news is that it is the result of an architectural change in the kernel. Originally I thought the "duplication" was on the transmit side, my investigations indicate that it is on receive. In kernels upto and including 2.4 where an AX25 payload was IP or ARP the packet was handed off by calling the ip or arp protocol driver directly. In kernels 2.6 onwards after adjusting the packet details the payload is handed back to the network interface for that interface to reroute the packet into the IP or ARP protocol drivers. A couple of code fragments: from 2.4.37.11: net/ax25/ax25_in.c 287 case AX25_P_IP: 288 skb_pull(skb,2); /* drop PID/CTRL */ 289 skb->h.raw = skb->data; 290 skb->nh.raw = skb->data; 291 skb->dev = dev; 292 skb->pkt_type = PACKET_HOST; 293 skb->protocol = htons(ETH_P_IP); 294 ip_rcv(skb, dev, ptype); /* Note ptype here is the wrong one, fix me later */ 295 break; 296 from 2.6.32.65: net/ax25/ax25_in.c 244 case AX25_P_IP: 245 skb_pull(skb,2); /* drop PID/CTRL */ 246 skb_reset_transport_header(skb); 247 skb_reset_network_header(skb); 248 skb->dev = dev; 249 skb->pkt_type = PACKET_HOST; 250 skb->protocol = htons(ETH_P_IP); 251 netif_rx(skb); 252 break; All the testing has been done using virtual machines linked by a virtual serial link. Testing was done to establish connections using AX25-UI, AX25-VC, NETROM, ROSE IP/ICMP, IP/UDP & IP/TCP. The first setup was of two 2.4.37.11 kernels. The second setup was of one 2.4.37.11 kernel and one 2.6.32.65 kernel. The third setup was of one 2.4.37.11 kernel and one 3.2.69 kernel. For the first setup no duplicates were seen at any point. For the second setup, duplicates of received packets were seen on the 2.6 kernel wherever IP was involved. No duplicates were seen on the 2.4 kernel. For the third setup, duplicates of received packets were seen on the 3.2 kernel wherever IP was involved. No duplicates were seen on the 2.4 kernel. These duplicate packets are seen by both "listen" and libpcap (and thus tcpdump or wireshark). From the protocol analysis point of view any kernel 2.6 onwards is suspect where encapsulated protocols, such as IP-over-AX25, are concerned. Notably NETROM and ROSE are not affected, this may be related to the manner in which those protocols "register" their handlers with AX25. The AX25 protocol driver considers AX25_P_TEXT, AX25_P_SEGMENT, AX25_P_IP or AX25_P_ARP as "internal" protocols (ax25/ax25_iface.c). IP-over-NETROM was not tested, however from inspection of the code I expect it to exhibit the same issue as IP-over-AX25. I was able to revert kernel 2.6.32.65 to the 2.4 method as ip_rcv & arp_rcv still exist and it was a simple matter to expose the functions (exporting the symbols and adding to the header files). Once reverted the duplicated packets in the 2.6 kernel disappeared. The above explains why the amateur radio protocols work however when one starts to look at the packets analytically what is seen at the network interface for IP & ARP is, in part, false. I believe the solution is to implement IP-over-AX25 as a tunnelled protocol in a similar manner to IP-over-IP. This will probably require an additional driver modelled on ipip.c. The same is true for IP-over-NETROM. There may, of course, be other issues present as well. -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html