Bug#783160: Results of my investigations into this packet "duplication"
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.
Reply to: