[PATCH 1/1] ax25: Fix segfault after sock connection timeout

[PATCH 1/1] ax25: Fix segfault after sock connection timeout

[Basil Gunn]

The ax.25 socket connection timed out & the sock struct has been
previously taken down ie. sock struct is now a NULL pointer. Checking
the sock_flag causes the segfault.  Check if the socket struct pointer
is NULL before checking sock_flag. This segfault is seen in
timed out netrom connections.

Please submit to -stable.

Signed-off-by: Basil Gunn <basil@pacabunga.com>
---

diff --git a/net/ax25/ax25_subr.c b/net/ax25/ax25_subr.c
index 4855d18..038b109 100644
--- a/net/ax25/ax25_subr.c
+++ b/net/ax25/ax25_subr.c
@@ -264,7 +264,7 @@ void ax25_disconnect(ax25_cb *ax25, int reason)
 {
 	ax25_clear_queues(ax25);

-	if (!sock_flag(ax25->sk, SOCK_DESTROY))
+	if (!ax25->sk || !sock_flag(ax25->sk, SOCK_DESTROY))
 		ax25_stop_heartbeat(ax25);
 	ax25_stop_t1timer(ax25);
 	ax25_stop_t2timer(ax25);

Re: [PATCH 1/1] ax25: Fix segfault after sock connection timeout

[David Miller]

From: Basil Gunn <basil@pacabunga.com>
Date: Sat, 14 Jan 2017 12:18:55 -0800

> The ax.25 socket connection timed out & the sock struct has been
> previously taken down ie. sock struct is now a NULL pointer. Checking
> the sock_flag causes the segfault.  Check if the socket struct pointer
> is NULL before checking sock_flag. This segfault is seen in
> timed out netrom connections.
> 
> Please submit to -stable.
> 
> Signed-off-by: Basil Gunn <basil@pacabunga.com>

This is consistent with the ax25->sk NULL check later in this function.

Applied and queued up for -stable, thanks.

Re: [BUG] AX.25 sockets not destroyed

[Ralf Baechle DL5RB]

On Thu, Feb 23, 2017 at 02:53:36PM +0100, f6bvp wrote:

> ffff8c80b5ed5800 ax0 F6BVP-7 F4BWT-9 1 0 0 0 18446744073709549 100 0 3 0 300 0 0 9 10 5 2 256 * * *
> ffff8c80b5ed5400 ax0 F6BVP-7 WA3MEZ-9 1 0 0 0 18446744073709549 100 0 3 0 300 0 0 9 10 5 2 256 * * *

> then it displays a very large number for a while,

The large number is an already expired t1 timer.  That means the time
to expiry is relativly small negative number like -1616 or as a hex
number 0xfffffffffffff9b0 which will be divied by HZ (probably 1000)
and displayed as a something like 18446744073709550.

Looking further into it.

  Ralf

Interesting Rose patch

[f6bvp]

Hi,

I want to acknowledge here a set of very usefull ROSE patches provided 
by richard Stearn.

Since years, it has not been possible to set rose0 device down without 
creating an endless loop of kernel waiting for rose to become free.

Richard found that a number of dev_put(dev) were missing.

Applying the following patch subset cured the issue and allowed a clean 
rose module removal.

The following patches are part of a larger series committed by Richard 
but rejected by Dave Miller mostly for format reasons.

I selected and checked the minimal changes necessary to cure the 
refcount issue.

See :

http://marc.info/?l=linux-hams&m=146873255413533&w=2

Richard does not want to jump in again.

So I would appreciate if someone could help us by confirming that this 
patch is extremely convenient.

Then someone could submit this subset to linux-hams and linux-netdev 
referees.

73 de Bernard, f6bvp

----------------------------------------


diff -ruN a/net/rose/af_rose.c b/net/rose/af_rose.c
--- a/net/rose/af_rose.c        2017-04-03 19:02:14.205800053 +0200
+++ b/net/rose/af_rose.c        2017-04-03 12:18:02.290052819 +0200
@@ -688,8 +688,10 @@
                 rose->source_call = user->call;
                 ax25_uid_put(user);
         } else {
-               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE))
+               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) {
+                       dev_put(dev);
                         return -EACCES;
+               }
                 rose->source_call   = *source;
         }

@@ -710,6 +712,7 @@
         rose_insert_socket(sk);

         sock_reset_flag(sk, SOCK_ZAPPED);
+       dev_put(dev);

         return 0;
  }
diff -ruN a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
--- a/net/rose/rose_loopback.c  2017-04-03 19:02:14.206800010 +0200
+++ b/net/rose/rose_loopback.c  2017-04-03 12:18:02.291052777 +0200
@@ -102,6 +102,7 @@
                         if ((dev = rose_dev_get(dest)) != NULL) {
                                 if (rose_rx_call_request(skb, dev, 
rose_loopback_neigh, lci_o) == 0)
                                         kfree_skb(skb);
+                               dev_put(dev);
                         } else {
                                 kfree_skb(skb);
                         }
diff -ruN a/net/rose/rose_route.c b/net/rose/rose_route.c
--- a/net/rose/rose_route.c     2017-04-03 19:02:14.207799967 +0200
+++ b/net/rose/rose_route.c     2017-04-03 12:18:02.290052819 +0200
@@ -875,6 +875,11 @@
         src_addr  = (rose_address *)(skb->data + 
ROSE_CALL_REQ_SRC_ADDR_OFF);
         dest_addr = (rose_address *)(skb->data + 
ROSE_CALL_REQ_DEST_ADDR_OFF);

+       if (ax25 == NULL) {
+               printk(KERN_ERR "rose_route_frame : called with ax25 
callback == NULL\n");
+               return res;
+       }
+
         spin_lock_bh(&rose_neigh_list_lock);
         spin_lock_bh(&rose_route_list_lock);

Re: Interesting Rose patch

[f6bvp]

Hi,

Here is a short add to my previous post.

Actually rose_route.c patch is independant from the others but very 
important as it removes a rare but fatal bug causing kernel panic.

I could observed the bug after adding an IP address to a secondary 
network to an ethernet port but without giving a route to this network.

Obviously it should be the subject of an separate commit.

Here is original post explanation from Richard  :

List:       linux-netdev
Subject:    [PATCH 3/6]NET:AX25:ROSE  Traps calls to rose_route_frame
with a NULL ax25 callback
From:       Richard Stearn <richard () rns-stearn ! demon ! co ! uk>
Date:       2016-07-16 9:43:59
Message-ID: 201607160943.u6G9hx4i014901 () ux4 ! g1sog

Subject: [PATCH 3/6]NET:AX25:ROSE  Traps calls to rose_route_frame with a
NULL ax25 callback
Traps calls to rose_route_frame with a NULL ax25 callback to
prevent a kernel crash.

Calling rose_route_frame with a NULL ax25 callback parameter indicates a
locally generated frame.  The existing code does not handle the NULL value
and the kernel hard crashes in an interrupt, resulting in the system
stopping
processing.

Signed-off-by: Richard Stearn<richard@rns-stearn.demon.co.uk>




Le 11/04/2017 à 19:26, f6bvp a écrit :
> Hi,
>
> I want to acknowledge here a set of very usefull ROSE patches provided 
> by richard Stearn.
>
> Since years, it has not been possible to set rose0 device down without 
> creating an endless loop of kernel waiting for rose to become free.
>
> Richard found that a number of dev_put(dev) were missing.
>
> Applying the following patch subset cured the issue and allowed a 
> clean rose module removal.
>
> The following patches are part of a larger series committed by Richard 
> but rejected by Dave Miller mostly for format reasons.
>
> I selected and checked the minimal changes necessary to cure the 
> refcount issue.
>
> See :
>
> http://marc.info/?l=linux-hams&m=146873255413533&w=2
>
> Richard does not want to jump in again.
>
> So I would appreciate if someone could help us by confirming that this 
> patch is extremely convenient.
>
> Then someone could submit this subset to linux-hams and linux-netdev 
> referees.
>
> 73 de Bernard, f6bvp
>
> ----------------------------------------
>
>
> diff -ruN a/net/rose/af_rose.c b/net/rose/af_rose.c
> --- a/net/rose/af_rose.c        2017-04-03 19:02:14.205800053 +0200
> +++ b/net/rose/af_rose.c        2017-04-03 12:18:02.290052819 +0200
> @@ -688,8 +688,10 @@
>                 rose->source_call = user->call;
>                 ax25_uid_put(user);
>         } else {
> -               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE))
> +               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) {
> +                       dev_put(dev);
>                         return -EACCES;
> +               }
>                 rose->source_call   = *source;
>         }
>
> @@ -710,6 +712,7 @@
>         rose_insert_socket(sk);
>
>         sock_reset_flag(sk, SOCK_ZAPPED);
> +       dev_put(dev);
>
>         return 0;
>  }
> diff -ruN a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> --- a/net/rose/rose_loopback.c  2017-04-03 19:02:14.206800010 +0200
> +++ b/net/rose/rose_loopback.c  2017-04-03 12:18:02.291052777 +0200
> @@ -102,6 +102,7 @@
>                         if ((dev = rose_dev_get(dest)) != NULL) {
>                                 if (rose_rx_call_request(skb, dev, 
> rose_loopback_neigh, lci_o) == 0)
>                                         kfree_skb(skb);
> +                               dev_put(dev);
>                         } else {
>                                 kfree_skb(skb);
>                         }
> diff -ruN a/net/rose/rose_route.c b/net/rose/rose_route.c
> --- a/net/rose/rose_route.c     2017-04-03 19:02:14.207799967 +0200
> +++ b/net/rose/rose_route.c     2017-04-03 12:18:02.290052819 +0200
> @@ -875,6 +875,11 @@
>         src_addr  = (rose_address *)(skb->data + 
> ROSE_CALL_REQ_SRC_ADDR_OFF);
>         dest_addr = (rose_address *)(skb->data + 
> ROSE_CALL_REQ_DEST_ADDR_OFF);
>
> +       if (ax25 == NULL) {
> +               printk(KERN_ERR "rose_route_frame : called with ax25 
> callback == NULL\n");
> +               return res;
> +       }
> +
>         spin_lock_bh(&rose_neigh_list_lock);
>         spin_lock_bh(&rose_route_list_lock);
>

Re: Interesting Rose patch

[Walter Harms]

> f6bvp <f6bvp@free.fr> hat am 11. April 2017 um 19:26 geschrieben:
> 
> 
> Hi,
> 
> I want to acknowledge here a set of very usefull ROSE patches provided 
> by richard Stearn.
> 
> Since years, it has not been possible to set rose0 device down without 
> creating an endless loop of kernel waiting for rose to become free.
> 
> Richard found that a number of dev_put(dev) were missing.
> 
> Applying the following patch subset cured the issue and allowed a clean 
> rose module removal.
> 
> The following patches are part of a larger series committed by Richard 
> but rejected by Dave Miller mostly for format reasons.
> 
> I selected and checked the minimal changes necessary to cure the 
> refcount issue.
> 
> See :
> 
> http://marc.info/?l=linux-hams&m=146873255413533&w=2
> 
> Richard does not want to jump in again.
> 
> So I would appreciate if someone could help us by confirming that this 
> patch is extremely convenient.
> 
> Then someone could submit this subset to linux-hams and linux-netdev 
> referees.
> 
> 73 de Bernard, f6bvp
> 
> ----------------------------------------
> 
> 
> diff -ruN a/net/rose/af_rose.c b/net/rose/af_rose.c
> --- a/net/rose/af_rose.c        2017-04-03 19:02:14.205800053 +0200
> +++ b/net/rose/af_rose.c        2017-04-03 12:18:02.290052819 +0200
> @@ -688,8 +688,10 @@
>                  rose->source_call = user->call;
>                  ax25_uid_put(user);
>          } else {
> -               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE))
> +               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) {
> +                       dev_put(dev);
>                          return -EACCES;
> +               }
>                  rose->source_call   = *source;
>          }
> 
> @@ -710,6 +712,7 @@
>          rose_insert_socket(sk);
> 
>          sock_reset_flag(sk, SOCK_ZAPPED);
> +       dev_put(dev);
> 
>          return 0;
>   }
> diff -ruN a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> --- a/net/rose/rose_loopback.c  2017-04-03 19:02:14.206800010 +0200
> +++ b/net/rose/rose_loopback.c  2017-04-03 12:18:02.291052777 +0200
> @@ -102,6 +102,7 @@
>                          if ((dev = rose_dev_get(dest)) != NULL) {
>                                  if (rose_rx_call_request(skb, dev, 
> rose_loopback_neigh, lci_o) == 0)
>                                          kfree_skb(skb);
> +                               dev_put(dev);
>                          } else {
>                                  kfree_skb(skb);
>                          }
> diff -ruN a/net/rose/rose_route.c b/net/rose/rose_route.c
> --- a/net/rose/rose_route.c     2017-04-03 19:02:14.207799967 +0200
> +++ b/net/rose/rose_route.c     2017-04-03 12:18:02.290052819 +0200
> @@ -875,6 +875,11 @@
>          src_addr  = (rose_address *)(skb->data + 
> ROSE_CALL_REQ_SRC_ADDR_OFF);
>          dest_addr = (rose_address *)(skb->data + 
> ROSE_CALL_REQ_DEST_ADDR_OFF);
> 
> +       if (ax25 == NULL) {
> +               printk(KERN_ERR "rose_route_frame : called with ax25 
> callback == NULL\n");
> +               return res;
> +       }
> +

you can check this more early and return 0 directly.

just my 2 cents,
re,
 wh

>          spin_lock_bh(&rose_neigh_list_lock);
>          spin_lock_bh(&rose_route_list_lock);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interesting Rose patch

[f6bvp]

Hi,

Unloading rose module issue due to unmatched dev_put() had also been
previously reported here :

http://marc.info/?l=linux-netdev&m=143389465602786&w=2

and here by f6bvp :

http://marc.info/?l=linux-hams&m=148837252410913&w=4


Bernard


>> Hi,
>>
>> I want to acknowledge here a set of very usefull ROSE patches provided 
>> by richard Stearn.
>>
>> Since years, it has not been possible to set rose0 device down without 
>> creating an endless loop of kernel waiting for rose to become free.
>>
>> Richard found that a number of dev_put(dev) were missing.
>>
>> Applying the following patch subset cured the issue and allowed a clean 
>> rose module removal.
>>
>> The following patches are part of a larger series committed by Richard 
>> but rejected by Dave Miller mostly for format reasons.
>>
>> I selected and checked the minimal changes necessary to cure the 
>> refcount issue.
>>
>> See :
>>
>> http://marc.info/?l=linux-hams&m=146873255413533&w=2
>>
>> Richard does not want to jump in again.
>>
>> So I would appreciate if someone could help us by confirming that this 
>> patch is extremely convenient.
>>
>> Then someone could submit this subset to linux-hams and linux-netdev 
>> referees.
>>
>> 73 de Bernard, f6bvp
>>
>> ----------------------------------------
>>
>>
>> diff -ruN a/net/rose/af_rose.c b/net/rose/af_rose.c
>> --- a/net/rose/af_rose.c        2017-04-03 19:02:14.205800053 +0200
>> +++ b/net/rose/af_rose.c        2017-04-03 12:18:02.290052819 +0200
>> @@ -688,8 +688,10 @@
>>                  rose->source_call = user->call;
>>                  ax25_uid_put(user);
>>          } else {
>> -               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE))
>> +               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) {
>> +                       dev_put(dev);
>>                          return -EACCES;
>> +               }
>>                  rose->source_call   = *source;
>>          }
>>
>> @@ -710,6 +712,7 @@
>>          rose_insert_socket(sk);
>>
>>          sock_reset_flag(sk, SOCK_ZAPPED);
>> +       dev_put(dev);
>>
>>          return 0;
>>   }
>> diff -ruN a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
>> --- a/net/rose/rose_loopback.c  2017-04-03 19:02:14.206800010 +0200
>> +++ b/net/rose/rose_loopback.c  2017-04-03 12:18:02.291052777 +0200
>> @@ -102,6 +102,7 @@
>>                          if ((dev = rose_dev_get(dest)) != NULL) {
>>                                  if (rose_rx_call_request(skb, dev, 
>> rose_loopback_neigh, lci_o) == 0)
>>                                          kfree_skb(skb);
>> +                               dev_put(dev);
>>                          } else {
>>                                  kfree_skb(skb);
>>                          }

Re: Interesting Rose patch

[f6bvp]

Hello David,

Thank you for offering to test the rose issue and validate Richard's patch.

You should first download and install fpac package using the related 
script number 3 from here :

http://f6bvp.org/configuration6_RPi.html

The script will install the whole FPAC package, although we will only 
use fpad application to reproduce the bug.

Rose install using fpad application is straightforward.

In order to let fpad node application run, you may use the following 
three configuration files samples you do not need to edit.

I assume you have already set up at least one ax.25 interface, and have 
/etc/ax25/axports,  for rose runs upon AX.25 network .

All three files must be copied into /etc/ax25/ directory.

Here is /etc/ax25/fpac.conf sample :

#
# This file is /usr/local/etc/ax25/fpac.conf (/etc/ax25/fpac.conf)
#
# node configuration
#
L2call    = F6BVP-6
L3call    = F6BVP-7
Trcall    = F6BVP-15
DNIC      = 2080
Address   = 175525
#Coverage  = 175202 175302 175402
InetPort  = 10095
InetAddr  = 44.168.19.22
Password  = 123456789
City      = Paris
State     = 75017
Country   = France
locator   = JN18DV
UserPort  = *
DefPort   = axudp
#
# Other  commands
#
Command
         VERsions  = /usr/local/sbin/versions
End
#for "sysops"
#
Sysop
      SYSop  = /usr/local/sbin/fpacshell
end
#
# Other applications
#
# TEST
Application
#F6BVP-14 = /usr/local/sbin/call_tcp f6bvp.org 6300
End

Second file is /etc/ax25/fpac.routes :

#
# FPAC ROSE route configuration file
#
# This file is in /usr/local/etc/ax25/fpac.routes
#
# Routes to adjacent nodes
#
# DNIC specify a default DNIC for the following addresses
#
# Address is 1 to 6 digits, using hierarchy
#
Routes
DNIC    = 0
2080    = F6BVP-11
2080    = F6BVP-9
2220    = F6BVP-9
3100    = F6BVP-9
3100    = F6BVP-9
3620    = F6BVP-9
7100    = F6BVP-9
# Routes to adjacent nodes full ROSE address
# DNIC + 6 digits
DNIC    = 2080
175502 = F6BVP-11
175520 = F6BVP-9
End

Third file is /etc/ax25/fpac.nodes

# FPAC ROSE route configuration file
#
# This file is in /usr/local/etc/ax25/fpac.nodes
#
# List of adjacent nodes
#
Node = F6BVP-9
  Path = F6BVP-9
  DNIC = 2080
  Address = 175520
  Port = axudp
  NoWp = 0
End
Node = F6BVP-11
  Path = F6BVP-11
  DNIC = 2080
  Address = 175502
  Port = axudp
  NoWp = 0
End

Again, for this test purpose, you don't need to edit those files, as you 
are not willing to get an actual working node switch.

After installing ax25 and fpac package using the script and putting 
above three files in /etc/ax25, then you are ready to perform the test.

Simply start fpad issuing the command /usr/local/sbin/fpad

If you get the following message : "problem with axports file." it would 
mean you did not start AX.25 before running fpad.

If you need, I could send you a script modified from K4GBB to set up 
AX.25 devices.

Otherwise fpad will display this message :

Configuring routes :
Route 2080175520 -> F6BVP-9 (axudp)
Route 2080175502 -> F6BVP-11 (axudp)
Route 7100000000 -> F6BVP-9 (axudp)
Route 3620000000 -> F6BVP-9 (axudp)
Route 3100000000 -> F6BVP-9 (axudp)
Route 3100000000 -> F6BVP-9 (axudp)
Route 2220000000 -> F6BVP-9 (axudp)
Route 2080000000 -> F6BVP-9 (axudp)
Route 2080000000 -> F6BVP-11 (axudp)

FPAD : ROSE address 2080175525 bound to device rose0


And after a while, you will get the following :

FPAD cannot open WP service
Closing opened sockets
Removing ROSE nodes
FPAD aborting

This is because we did not start correctly the full FPAC suite of 
applications.

It does not matter.

Now we have loaded rose module, created a ROSE device and initiated a 
rose socket.

We want to close down rose0 device the same way we would do it for 
NetRom device using command

ifconfig rose0 down.

This command removes rose0 device. However rose module cannot be removed 
by rmmod rose command.

Instead we enter into a kernel loop waiting for rose module to be free.

I hope this is clear enough to let you reproduce the bug.

Then after applying the patch, you will see that removing rose is fine.


Bernard


Le 13/04/2017 à 16:57, David Ranch a écrit :
>
> Hey Bernard,
>
> So how would you like to proceed here?  I can apply you patch to a 
> kernel and see if my machine remains stable.  If you have a test plan 
> you can share to reproduce issues, I can go through that as well.  
> Beyond that, I don't actively use ROSE today. After that, I imagine we 
> should get the patches signed off and submitted upstream.
>
> --David
> KI6ZHD
>
>

Re: Interesting Rose patch

[f6bvp]

Hello David,

I missed something important that needs some explanation.

Port names in fpac.nodes sample file I provided are "axudp"

Obviously those Port names should be edited according to your 
/etc/ax25/axports file !

And the following comment line should be removed in that file :

# FPAC ROSE route configuration file
#
# This file is in /usr/local/etc/ax25/fpac.nodes
#
# List of adjacent nodes
#

Bernard



Le 17/04/2017 à 18:15, f6bvp a écrit :
> Hello David,
>
>
>
> Le 13/04/2017 à 16:57, David Ranch a écrit :
>>
>> Hey Bernard,
>>
>> So how would you like to proceed here?  I can apply you patch to a 
>> kernel and see if my machine remains stable.  If you have a test plan 
>> you can share to reproduce issues, I can go through that as well.  
>> Beyond that, I don't actively use ROSE today. After that, I imagine 
>> we should get the patches signed off and submitted upstream.
>>
>> --David
>> KI6ZHD
>>
>>

Re: Interesting Rose patch

[f6bvp]

Charley K4GBB was kind enough to check "unregister netdevice" bug on two 
of his hosts runing ROSE-FPAC nodes .
Here I forward his two reports.

Bernard


The same condition exists on this host.

root@linuxlab4:~# uname -a
Linux linuxlab4 4.1.21+ #872 Wed Apr 6 17:27:13 BST 2016 armv6l GNU/Linux
root@linuxlab4:~# lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 7.11 (wheezy)
Release:    7.11
Codename:    wheezy



On Tue, Apr 18, 2017 at 2:47 PM, Charles Schuman <k4gbb1@gmail.com 
<mailto:k4gbb1@gmail.com>> wrote:

    Stopping ax25 and verifying ax25 sockets closed and rose module
    still loaded the rmmod rose cmd
    causes a endless loop of the following message.

    root@linuxlab5:~# rmmod rose
    Message from syslogd@linuxlab5 at Apr 18 14:37:20 ...
      kernel:[4229400.605324] unregister_netdevice: waiting for rose0 to
    become free. Usage count = 33

    _root@linuxlab5:~# uname -a_
    Linux linuxlab5 4.1.19+ #858 Tue Mar 15 15:52:03 GMT 2016 armv6l
    GNU/Linux
    _root@linuxlab5:~# lsb_release -a_
    No LSB modules are available.
    Distributor ID:    Debian
    Description:    Debian GNU/Linux 7.11 (wheezy)
    Release:    7.11
    Codename:    wheezy



    On Tue, Apr 18, 2017 at 12:58 PM, f6bvp <f6bvp@free.fr
    <mailto:f6bvp@free.fr>> wrote:

        Hello Charley,

        Glad to hear from you and I hope you are fine.

        I you want, you may confirm that shutting down rose0 (ifconfig rose0
        down) and removing rose module (rmmod rose) can freeze the
        kernel into
        an infinite loop waiting for rose to be free.

        73 de Bernard, f6bvp


        Le 18/04/2017 à 04:24, Charles Schuman a écrit :
         > Bernard,
         >   I have a FPAC Node set up as a Test Bed on m RPi-B1.
         > What would you like me to test.
         >
         > <<Charley>>
         >   k4gbb

Re: [ROSE] rose dereferenced pointer kernel panic

[Dmitry Vyukov]

On Wed, Jan 2, 2019 at 12:12 AM Bernard Pidoux <f6bvp@free.fr> wrote:
>
> Hi David,
>
> In my previous message I should have reported the following patch rather than the one I reported.
>
> The reason is that the bug is better explained here :
>
> https://marc.info/?l=linux-hams&m=154478673812818&w=2
>
> and  I hope the new proposed patch is more convenient.
>
>
> Bernard
>
>
> Le 01/01/2019 à 23:39, Bernard Pidoux a écrit :
>
> Hi David,
>
> As you already know I am still looking for the simplest way to configure a kernel rose failure situation when rose_route_frame is called with a NULL pointer.
>
> Could you explain with full details how to have "TCP/IP over AX.25 fully configured" ?
>
> More specifically how can we configure rose device without NOARP ? This is not the case when performing Dmitry Vyukov :
>
> # ip link set dev rose0 address 11:22:33:44:55
> # ip link set dev rose0 up
>
> 73 de Bernard, f6bvp
>
>
> Le 08/12/2018 à 17:23, David Ranch a écrit :
>
> Hello Bernard, Everyone,
>
> Yes, I've seen a similar behavior with another program I have here that broadcasts on all live TCP/IP interfaces when it loads.  That all depends if you have TCP/IP over AX.25 fully configured on your machine.  If you do, this cp,,amd should key up your radio to send out an ARP:
>
>     ping -b -c 1 <broadcast IP on your ROSE or AX.25 interface>
>    --
>    d710: fm KI6ZHD to QST ctl UI pid=CC(IP) len 84
>    IP: len 84 44.4.10.39->44.4.10.127 ihl 20 ttl 64 DF prot ICMP
>    ICMP: type Echo Request id 50814 seq 1
>    P�.\
>    �~.
>    ................ !"#$%&'()*+,-./01234567
>    --
>
> Btw, I've been aware of this ROSE panic issue for some time and I'm pretty sure I forwarded those details on to you but that was many years ago.  Another way to reproduce a ROSE panic is, if I remember correctly, you remove the backing AX.25 interface's connection (say killing kisssattach for ax0) on a ROSE interface that has an IP, that will also panic the kernel every time.
>
> --David
> KI6ZHD

+mailing lists

Hi Bernard,

I've provided a bit more information on what I did here:
https://groups.google.com/d/msg/syzkaller/v-4B3zoBC-4/MVgYoeSQCgAJ

I really did not do anything fancy.

FWIW I had to do the following locally just to prevent rose from
crashing my machine all the time. I don't know if it's the right fix
or not, I just used this as stop-gap.

diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 77e9f85a2c92..218308a3c02c 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -874,6 +874,8 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
             skb->data[ROSE_CALL_REQ_ADDR_LEN_OFF] !=
             ROSE_CALL_REQ_ADDR_LEN_VAL))
                return res;
+       if (ax25 == NULL)
+               return res;
        src_addr  = (rose_address *)(skb->data + ROSE_CALL_REQ_SRC_ADDR_OFF);
        dest_addr = (rose_address *)(skb->data + ROSE_CALL_REQ_DEST_ADDR_OFF);


rose_xmit calls rose_route_frame with ax25==NULL, then
rose_route_frame uses ax25 without any checks.

Re: Interesting Rose patch

[f6bvp]

Hello David,

It has been a long time since I sent the following message.
Did you read it ?

http://marc.info/?l=linux-hams&m=149495926809205&w=4

As you can read I performed the test of Richard's Walter's ROSE patch
modification and the conclusion is positive.
I do approve and support this important ROSE patch.

You could now proceed and make it introduced into ROSE code.

Bernard


Le 13/04/2017 à 16:57, David Ranch a écrit :
> 
Le 18/04/2017 à 18:14, David Ranch a écrit :
>
> Hey Bernard,
>
> Do you want to consider testing with Walter's modification to 
> Richard's patch mentioned on April 12th (below)?
>
> --David
>
>

> --David
> KI6ZHD

Re: Interesting Rose patch

[David Ranch]

Hello Bernard,

Great to hear the patch is working.  Getting the commit applied is 
mostly a matter of formatting an email in specific ways, sending them to 
the right people, and getting approvals.

   Ralf:  Do you have any concerns on this patch in what it's 
specifically doing, etc?

--David
KI6ZHD


On 06/28/2017 05:24 AM, f6bvp wrote:
> Hello David,
>
> It has been a long time since I sent the following message.
> Did you read it ?
>
> http://marc.info/?l=linux-hams&m=149495926809205&w=4
>
> As you can read I performed the test of Richard's Walter's ROSE patch
> modification and the conclusion is positive.
> I do approve and support this important ROSE patch.
>
> You could now proceed and make it introduced into ROSE code.
>
> Bernard
>
>
> Le 13/04/2017 à 16:57, David Ranch a écrit :
> Le 18/04/2017 à 18:14, David Ranch a écrit :
>> Hey Bernard,
>>
>> Do you want to consider testing with Walter's modification to
>> Richard's patch mentioned on April 12th (below)?
>>
>> --David
>>
>>
>> --David
>> KI6ZHD
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fwd: Re: Interesting Rose patch

[David Ranch]

Hey Bernard,

Do you want to consider testing with Walter's modification to Richard's 
patch mentioned on April 12th (below)?

--David


-------- Forwarded Message --------
Subject: 	Re: Interesting Rose patch
Date: 	Wed, 12 Apr 2017 22:43:15 +0200 (CEST)
From: 	Walter Harms <wharms@bfs.de>
Organization: 	Bundesamt f. Strahlenschutz
To: 	David Ranch <dranch@trinnet.net>, f6bvp <f6bvp@free.fr>, Basil Gunn 
<basil@pacabunga.com>
CC: 	C Schuman <k4gbb1@embarqmail.com>, linux-hams@vger.kernel.org, Ralf 
Bächle DL5RB <ralf@linux-mips.org>, Richard Stearn 
<richard@rns-stearn.co.uk>



> f6bvp <f6bvp@free.fr> hat am 11. April 2017 um 19:26 geschrieben:
>
>
> Hi,
>
> I want to acknowledge here a set of very usefull ROSE patches provided
> by richard Stearn.
>
> Since years, it has not been possible to set rose0 device down without
> creating an endless loop of kernel waiting for rose to become free.
>
> Richard found that a number of dev_put(dev) were missing.
>
> Applying the following patch subset cured the issue and allowed a clean
> rose module removal.
>
> The following patches are part of a larger series committed by Richard
> but rejected by Dave Miller mostly for format reasons.
>
> I selected and checked the minimal changes necessary to cure the
> refcount issue.
>
> See :
>
> http://marc.info/?l=linux-hams&m=146873255413533&w=2
>
> Richard does not want to jump in again.
>
> So I would appreciate if someone could help us by confirming that this
> patch is extremely convenient.
>
> Then someone could submit this subset to linux-hams and linux-netdev
> referees.
>
> 73 de Bernard, f6bvp
>
> ----------------------------------------
>
>
> diff -ruN a/net/rose/af_rose.c b/net/rose/af_rose.c
> --- a/net/rose/af_rose.c        2017-04-03 19:02:14.205800053 +0200
> +++ b/net/rose/af_rose.c        2017-04-03 12:18:02.290052819 +0200
> @@ -688,8 +688,10 @@
>                  rose->source_call = user->call;
>                  ax25_uid_put(user);
>          } else {
> -               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE))
> +               if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) {
> +                       dev_put(dev);
>                          return -EACCES;
> +               }
>                  rose->source_call   = *source;
>          }
>
> @@ -710,6 +712,7 @@
>          rose_insert_socket(sk);
>
>          sock_reset_flag(sk, SOCK_ZAPPED);
> +       dev_put(dev);
>
>          return 0;
>   }
> diff -ruN a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> --- a/net/rose/rose_loopback.c  2017-04-03 19:02:14.206800010 +0200
> +++ b/net/rose/rose_loopback.c  2017-04-03 12:18:02.291052777 +0200
> @@ -102,6 +102,7 @@
>                          if ((dev = rose_dev_get(dest)) != NULL) {
>                                  if (rose_rx_call_request(skb, dev,
> rose_loopback_neigh, lci_o) == 0)
>                                          kfree_skb(skb);
> +                               dev_put(dev);
>                          } else {
>                                  kfree_skb(skb);
>                          }
> diff -ruN a/net/rose/rose_route.c b/net/rose/rose_route.c
> --- a/net/rose/rose_route.c     2017-04-03 19:02:14.207799967 +0200
> +++ b/net/rose/rose_route.c     2017-04-03 12:18:02.290052819 +0200
> @@ -875,6 +875,11 @@
>          src_addr  = (rose_address *)(skb->data +
> ROSE_CALL_REQ_SRC_ADDR_OFF);
>          dest_addr = (rose_address *)(skb->data +
> ROSE_CALL_REQ_DEST_ADDR_OFF);
>
> +       if (ax25 == NULL) {
> +               printk(KERN_ERR "rose_route_frame : called with ax25
> callback == NULL\n");
> +               return res;
> +       }
> +

you can check this more early and return 0 directly.

just my 2 cents,
re,
  wh

>          spin_lock_bh(&rose_neigh_list_lock);
>          spin_lock_bh(&rose_route_list_lock);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interesting Rose patch

[f6bvp]

Hello David,

Walter's suggested to modify Richard's rose patch 3/6.

List:       linux-netdev
Subject:    [PATCH 3/6]NET:AX25:ROSE  Traps calls to rose_route_frame
with a NULL ax25 callback
From:       Richard Stearn <richard () rns-stearn ! demon ! co ! uk>
Date:       2016-07-16 9:43:59

This patch intends to remove a kernel panic cause due to ax25 parameter 
that

is fatal when, locally generated NULL argument, in calling ax25cmp() 
function later in the code.

However, this is a separate issue from "rose waiting to be free" and as 
such it should committed separately from the other.

I agree that NULL ax25 could be checked more early at the beginning of 
rose_route() and I will consider moving it at the top of rose_route().

Then I will report the result.

Bernard


Le 18/04/2017 à 18:14, David Ranch a écrit :
>
> Hey Bernard,
>
> Do you want to consider testing with Walter's modification to 
> Richard's patch mentioned on April 12th (below)?
>
> --David
>

Re: Fwd: Re: Interesting Rose patch

[f6bvp]

Hi David,

I applied the following Walter's modification to Richard's patch with 
success to both kernels 4.10 and 4.11.

diff -ruN a/net/rose/rose_route.c a/net/rose/rose_route.c
--- a/net/rose/rose_route.c     2016-04-04 00:26:26.000000000 +0200
+++ b/net/rose/rose_route.c     2017-02-26 23:46:10.468772036 +0100
@@ -867,6 +866,11 @@
         int res = 0;
         char buf[11];

+       if (ax25 == NULL) {
+               printk(KERN_ERR "rose_route_frame : called with ax25 
callback == NULL\n");
+               return res;
+       }
+
         if (skb->len < ROSE_MIN_LEN)
                 return res;

Sending connect request ROSE/AX.25 frames through an IP device without 
routing gateway originated a NULL ax25 condition

that have been extensively explained in previous messages.

I used netconsole on local and remote machines to capture kernel message 
after applying the patch.

Here are /var/log/dmesg content

[    0.000000] Linux version 4.10.0 (root@f6bvp-6) (gcc version 4.9.2 
(GCC) ) #1 SMP Mon Feb 20 15:44:42 CET 2017
[    0.000000] Command line: BOOT_IMAGE=4.10.0 
root=UUID=f3cbe7d7-7b6d-4618-bc72-a044a0b20958 splash quiet noiswmd 
resume=UUID=cd3d43f3-1c51-46a1-8d40-6c693d50b0d4 vga=788
--------------
[   17.718171] NET: Registered protocol family 17
[  103.173995] console [netcon0] enabled
[  103.174040] netconsole: network logging started
[  103.180494] netconsole: network logging has already stopped
[  103.192495] printk: continuation disabled due to ext consoles, expect 
more fragments in /dev/kmsg
[  103.192527] console [netcon_ext0] enabled
[  103.192534] netpoll: netconsole: local port 6665
[  103.192543] netpoll: netconsole: local IPv4 address 192.168.0.119
[  103.192550] netpoll: netconsole: interface 'enp0s9'
[  103.192558] netpoll: netconsole: remote port 6666
[  103.192565] netpoll: netconsole: remote IPv4 address 192.168.0.115
[  103.192573] netpoll: netconsole: remote ethernet address 
b8:27:eb:9b:43:e5
[  103.192610] netconsole: netconsole: network logging started
[  103.270048] NET: Registered protocol family 3
[  103.273377] mkiss: AX.25 Multikiss, Hans Albas PE1AYX
[  103.274250] mkiss: ax0: crc mode is auto.
[  103.275388] IPv6: ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready
[  103.361158] NET: Registered protocol family 11
[  106.376322] mkiss: ax0: Trying crc-smack
[  106.376876] mkiss: ax0: Trying crc-flexnet
[  237.193538] IPv4: martian source 255.255.255.255 from 44.168.19.17, 
on dev enp0s9
[  237.195491] ll header: 00000000: ff ff ff ff ff ff 00 0c 42 91 13 ac 
08 00        ........B.....
[  263.136213] rose_route_frame : called with ax25 callback == NULL
[  263.138758] rose_route_frame : called with ax25 callback == NULL
[  263.149080] rose_route_frame : called with ax25 callback == NULL
[  297.195431] IPv4: martian source 255.255.255.255 from 44.168.19.17, 
on dev enp0s9
[  297.195512] ll header: 00000000: ff ff ff ff ff ff 00 0c 42 91 13 ac 
08 00        ........B.....
[  324.576251] rose_route_frame : called with ax25 callback == NULL
[  324.576380] rose_route_frame : called with ax25 callback == NULL
[  324.576827] rose_route_frame : called with ax25 callback == NULL
[  357.205313] IPv4: martian source 255.255.255.255 from 44.168.19.17, 
on dev enp0s9
[  357.205391] ll header: 00000000: ff ff ff ff ff ff 00 0c 42 91 13 ac 
08 00        ........B.....
[  398.304379] rose_route_frame : called with ax25 callback == NULL
[  398.304520] rose_route_frame : called with ax25 callback == NULL
[  398.304874] rose_route_frame : called with ax25 callback == NULL
[  417.211572] IPv4: martian source 255.255.255.255 from 44.168.19.17, 
on dev enp0s9
[  417.213627] ll header: 00000000: ff ff ff ff ff ff 00 0c 42 91 13 ac 
08 00        ........B.....
---------------

This is remote console capture with nc :

3,822,623584407,-;rose_route_frame : called with ax25 callback == NULL
3,823,623586390,-;rose_route_frame : called with ax25 callback == NULL
3,824,623588128,-;rose_route_frame : called with ax25 callback == NULL
4,825,673724925,-;IPv4: martian source 255.255.255.255 from 
44.168.19.17, on dev enp0s9
4,826,673726146,-;ll header: 00000000: ff ff ff ff ff ff 00 0c 42 91 13 
ac 08 00        ........B.....
4,827,684896180,-;IPv4: martian source 44.168.19.20 from 44.168.19.17, 
on dev enp0s9
4,828,684897494,-;ll header: 00000000: ff ff ff ff ff ff 00 0c 42 91 13 
ac 08 06        ........B.....
4,829,685890394,-;IPv4: martian source 44.168.19.20 from 44.168.19.17, 
on dev enp0s9
4,830,685891811,-;ll header: 00000000: ff ff ff ff ff ff 00 0c 42 91 13 
ac 08 06        ........B.....
4,831,686890384,-;IPv4: martian source 44.168.19.20 from 44.168.19.17, 
on dev enp0s9
4,832,686891872,-;ll header: 00000000: ff ff ff ff ff ff 00 0c 42 91 13 
ac 08 06        ........B.....
3,833,697313405,-;rose_route_frame : called with ax25 callback == NULL
3,834,697315376,-;rose_route_frame : called with ax25 callback == NULL
3,835,697318136,-;rose_route_frame : called with ax25 callback == NULL

Above listing show that the patch is doing the job identifying the NULL 
condition and avoiding a kernel panic.


Bernard


Le 18/04/2017 à 18:14, David Ranch a écrit :
>
> Hey Bernard,
>
> Do you want to consider testing with Walter's modification to 
> Richard's patch mentioned on April 12th (below)?
>
> --David
>
>

[BUG] AX.25 sockets not destroyed

[f6bvp]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Bug_AX25_sockets_not_destroyed.txt --]
[-- Type: text/plain, Size: 4714 bytes --]

Hi,

It's nice to have no more kernel panic, thanks to Basil Gunn's AX.25 recently applied patch.

However, an issue remains when an AX.25 connection fails or after disconnecting from a remote station.

/proc/net/ax25 remains populated by a number of entries forever as shown here :

[root@f6bvp-6 bernard]# cat /proc/net/ax25
ffff8c80b5ed6c00 ax0 TM6BVP-1 FE6BVP-1 1 0 0 0 15 50 0 3 0 300 0 0 4 10 5 2 256 0 0 18495
ffff8c80b5ed6400 ax0 TM6BVP-1 F6BVP-1 1 0 0 0 15 50 0 3 0 300 0 0 4 10 5 2 256 0 0 18493
ffff8c80b5ef5800 ax0 F6BVP-6 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18299
ffff8c80b5ef6000 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18296
ffff8c80b5ed7400 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18472
ffff8c80b5ed5800 ax0 F6BVP-7 F4BWT-9 1 0 0 0 1 60 0 3 0 300 0 0 5 10 5 2 256 * * *
ffff8c80b5ed5400 ax0 F6BVP-7 WA3MEZ-9 1 0 0 0 1 60 0 3 0 300 0 0 5 10 5 2 256 * * *
[root@f6bvp-6 bernard]# cat /proc/net/ax25
ffff8c80b5ed6c00 ax0 TM6BVP-1 FE6BVP-1 1 0 0 0 14 50 0 3 0 300 0 0 4 10 5 2 256 0 0 18495
ffff8c80b5ed6400 ax0 TM6BVP-1 F6BVP-1 1 0 0 0 14 50 0 3 0 300 0 0 4 10 5 2 256 0 0 18493
ffff8c80b5ef5800 ax0 F6BVP-6 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18299
ffff8c80b5ef6000 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18296
ffff8c80b5ed7400 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18472
ffff8c80b5ed5800 ax0 F6BVP-7 F4BWT-9 1 0 0 0 0 60 0 3 0 300 0 0 5 10 5 2 256 * * *
ffff8c80b5ed5400 ax0 F6BVP-7 WA3MEZ-9 1 0 0 0 0 60 0 3 0 300 0 0 5 10 5 2 256 * * *
[root@f6bvp-6 bernard]# cat /proc/net/ax25
ffff8c80b5ed6c00 ax0 TM6BVP-1 FE6BVP-1 1 0 0 0 13 50 0 3 0 300 0 0 4 10 5 2 256 0 0 18495
ffff8c80b5ed6400 ax0 TM6BVP-1 F6BVP-1 1 0 0 0 13 50 0 3 0 300 0 0 4 10 5 2 256 0 0 18493
ffff8c80b5ef5800 ax0 F6BVP-6 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18299
ffff8c80b5ef6000 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18296
ffff8c80b5ed7400 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18472
ffff8c80b5ed5800 ax0 F6BVP-7 F4BWT-9 1 0 0 0 18446744073709550 60 0 3 0 300 0 0 5 10 5 2 256 * * *
ffff8c80b5ed5400 ax0 F6BVP-7 WA3MEZ-9 1 0 0 0 18446744073709550 60 0 3 0 300 0 0 5 10 5 2 256 * * *
[root@f6bvp-6 bernard]# cat /proc/net/ax25
ffff8c80b5ed6c00 ax0 TM6BVP-1 FE6BVP-1 1 0 0 0 75 100 0 3 0 300 0 0 9 10 5 2 256 0 0 18495
ffff8c80b5ed6400 ax0 TM6BVP-1 F6BVP-1 1 0 0 0 75 100 0 3 0 300 0 0 9 10 5 2 256 0 0 18493
ffff8c80b5ef5800 ax0 F6BVP-6 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18299
ffff8c80b5ef6000 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18296
ffff8c80b5ed7400 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18472
ffff8c80b5ed5800 ax0 F6BVP-7 F4BWT-9 1 0 0 0 18446744073709549 100 0 3 0 300 0 0 9 10 5 2 256 * * *
ffff8c80b5ed5400 ax0 F6BVP-7 WA3MEZ-9 1 0 0 0 18446744073709549 100 0 3 0 300 0 0 9 10 5 2 256 * * *

[root@f6bvp-6 bernard]# cat /proc/net/ax25
ffff8c809025a800 ax0 TM6BVP-1 FE6BVP-1 1 0 0 0 25 60 0 3 0 300 0 0 5 10 5 2 256 0 0 29417
ffff8c809025bc00 ax0 TM6BVP-1 F6BVP-1 1 0 0 0 25 60 0 3 0 300 0 0 5 10 5 2 256 0 0 29416
ffff8c80b5ef5800 ax0 F6BVP-6 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18299
ffff8c80b5ef6000 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18296
ffff8c80b5ed7400 ax0 TM6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 18472
ffff8c80b5ed5800 ax0 F6BVP-7 F4BWT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
ffff8c80b5ed5400 ax0 F6BVP-7 WA3MEZ-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *

While AX.25 connections are attempted with adjacent nodes (4th field =1) when system is started-up, one can see that 8th field  
of /proc/net/ax25 first two lines is counting down from 15 to 13 in above samples.
At the same time, for example on line 
"ax0 F6BVP-7 WA3MEZ-9 1 0 0 0 1 60 0 3 0 300" 
the 8th field goes down from some number to 0,
F6BVP-7 WA3MEZ-9 1 0 0 0 0 60 0 3 0 300 0 
then it displays a very large number for a while,
ax0 F6BVP-7 F4BWT-9 1 0 0 0 18446744073709549 100 0 3 0 300 0
then it starts again with a "normal" number.
After a while, all unconnected entries stay stable :
ax0 F6BVP-7 F4BWT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
And /proc/net/ax25 display the same unconnected entries forever.

I also observed that this situation prevents a new connection to occur for the same destination call.

I tried to apply some AX.25 patch I had received previously without success on stable kernel 4.1.38, and kernels 4.9.11 and 4.10.0.
Same symptoms are seen on all my computers : i686 and RPis.

I think this means that AX.25 sockets are never closed (destroyed) when a timer is expired after a connection attempt or a disconnection.

Bernard, f6bvp