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
On 12/08/2018 07:17 AM, f6bvp wrote:
Hi All,
While running packet radio network switch ROSE node a kernel panic
occurs systematically when opening a Chromium session.
kernel is 4.14.79-v7+ on a Raspberry Pi with Compass Linux (Debian stretch).
According to Kernel message panic is related to ax25cmp() performed with
a null pointer argument.
The function from which ax25cmp() gets a NULL pointer is rose_route_frame().
Function rose_route_frame() is called by rose_xmit() in the following
code sequence with explicit NULL pointer argument :
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
Why kernel panic was usually not observed is a big question ? However
kernel panic is now systematically occuring as soon as a Chromium window
is opened. Annaliese McDermond wrote "I’d guess that Chromium is trying
to do a broadcast to all interfaces for some reason. Once you load the
ax25 stack, the packet modem becomes a network interface. This
broadcast packet is probably triggering a bug in the ax25 stack due to
it having some sort of freaky address (or more accurately no address) by
the time it gets there."
In order to avoid fatal ax25cmp() comparison we could use the following
patch that has been already proposed by a number of observers facing
such dereferenced pointer. See for example :
https://marc.info/?l=linux-hams&m=145607584303977&w=2
https://marc.info/?l=linux-hams&m=146866282201792&w=2
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 452bbb38d943..8f2f1fb1707d 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -863,6 +863,10 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb
*ax25)
int res = 0;
char buf[11];
+ if (ax25 == NULL) {
+ return res;
+ }
+
if (skb->len < ROSE_MIN_LEN)
return res;
frametype = skb->data[2];
To let my RPi work correctly I patched rose module kernel 4.14.79-v7+ on
my Raspberry Pi and it succeeded in preventing kernel panic.
However, this is not satisfactory as the code sequence calling
rose_route_frame with a NULL argument should have been written on
purpose. My concern is that I don't understand the significance of this
code in case it would not trigger a kernel panic. Is this a bug ?
Instead of NULL argument, did the author want actually to send an empty
value ?
Richard Stearn explained formerly :
https://marc.info/?l=linux-hams&m=146866282201792&w=2
"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." Read :
https://marc.info/?l=linux-netdev&m=145720784703135&w=2
I someone understands the purpose of the offending call sequence, could
he explain the meaning to us ?
Regards,
Bernard Pidoux, f6bvp
