Re: Status of the LISTENING stuck state machine bug

[David Ranch]

Hell Gavin,

Yes, this is still an active issue but it doesn't happen to all users.  
Can you elaborate a little bit on your setup?  Regardless, there are 
some people looking at the issue for it but there isn't anything 
available yet.  Until then, it's understood that 4.1.21 and older 
kernels have a properly functioning AX.25 stack.  Can you downgrade your 
kernel?


--David
KI6ZHD


On 10/22/2019 01:13 AM, Gavin Rogers wrote:

Hello.

Does anyone know the status of the bug in 4.x kernels causing the 
kernel to become stuck after an AX.25 connection has closed down, 
causing it to permanently stay in a callsign-1 callsign-2 LISTENING 
status?


i.e. https://www.spinics.net/lists/linux-hams/msg04029.html

The latest kernel machine I have ready access to is running 4.19 and 
it's still there.


I don't know much about kernel development - is this an open bug or 
how can it get attention to be fixed?


Gavin
VK6HGR

Re: fldigi

[David Ranch]

Hello Paul,

I recommend you take this question to the Fldigi list at 
linux...@groups.io as you'll get more traction there. Anyway..



I have a laptop running ubuntu 18-10 i have wsjt-x running smoothly 
BUT fldigi is killing me.


Define "killing you".  Is it just a lack of PTT?


Does anyone have some sample config's for me i have a ft950 with a 
microham 3 interface.
I have hamlib installed and fldigi starts and decodes ok but does no 
transmit.


Please follow 
http://www.w1hkj.com/doku/doku.php?id=howto:linux_user_group_configuration_for_serial_ports 
to make sure your login name is in the right Unix groups.  There is also 
reports that with bleeding edge distros like Mint 19.1 that you need to 
be in the "tty" group as well.  You must log out and back in for the 
changes to go into effect.  If your issues persist and after you join 
the Groups.IO list, post the unique output of dmesg after you plug in 
the MicroHam3 interface.




I hope this mailing list is still alive.


This list is barely alive and it mostly covers incoming Linux AX.25 
patches coming from developers that are trying to keep things modern but 
aren't doing any testing.


--David
KI6ZHD

Re: Is AX.25 UI frame destination address case-sensitive?

[David Ranch]

Hello Stuart,


The thinking here is if I want to send a message to a station, VK4BWI-0,
if it's just to that station, I'd address it to "VK4BWI-0" as normal.

However, supposing a few of us in Brisbane WICEN had a little chat group
on our digipeater network, and we wished to have a common UI frame
destination address that we all listen for to receive real-time messages.


So you're looking to use unconnected UI frames to communicate to 
multiple people at the same time?  Are you looking to have those remote 
stations listen and *only* selectively show the traffic either to their 
own callsign+ssid or to a specific "multicast" group?


In my area, we have a weekly UI net where different HAMs essentially 
send beacons along a 7-hop digi path to chat.  Everyone monitors the 
channel in a promiscuous method to hear everyone's traffic.  It's not an 
ideal system as we see all the other traffic on the channel as well but 
it does work well enough.  If you wanted to filter on this traffic to 
only your net, you could have everyone send their traffic to a specific 
destination across your digipeaters and filter all promiscuous traffic 
to a specific destination address, say "vk4cht-0". If you're looking for 
a guaranteed delivery transport, you could do something at the 
application layer to put a sequence number in the UI payload to identify 
missing packets and re-request a re-transmit.  This is something that 
D-RATS had developed years ago.  That could become a challenge in a 
lossy multi-point network but it it works fine when someone is acting as 
a net control.


In the TCP/IP world, Pragmatic General Multicast (PGM) attempts to solve 
this problem:


https://en.wikipedia.org/wiki/Reliable_multicast

--David
KI6ZHD

Re: Socket stuck listening after incoming SABM with no listener

[David Ranch]

Hey Thomas,


Good find! This does look pretty similar. I'm running a fairly up-to-date Raspbian. uname 
-r reports "4.9.27-v7+".


Running new kernels is supposed to be a GOOD thing but unfortunately, 
there are kernel developers out there that are making changes to the 
AX.25 code.  They are  thinking they are helping keep the kernel modern
and other developers rubber-stamp approve the changes without *any* 
testing!  Compiling code is NOT testing! Gah!..


Sorry, it's not a good situation.



Hmm that's getting pretty old now isn't it. Good to know it's probably not my 
config at fault.


Yes.. 3.18 is quite old and EOL but the 3.16.x series is still 
maintained.  The older kernels in the Ubuntu 14.04 series, Debian 
Wheezy, etc. are known to work well, etc.  All depends on what distro

you're running.

Btw, I was going through some of my previous emails from the UroNode and 
linux-hams email lists and there is various evidence of
these kernel issues cropping up.  If it's possible on your system, try 
an old kernel or even an older distro and see if your issues go away.


--David
KI6ZHD

Re: Socket stuck listening after incoming SABM with no listener

[David Ranch]

>

Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: *** Secure Gateway Logon
Mar 25 12:36:19 LinuxRMSGatewayBox rmsgw[1490]: ; INFO: Connection 
closed by CMS (sense = 0x)#015
Mar 25 12:36:20 LinuxRMSGatewayBox rmsgw[1490]: Logout WA7FPVtx:81 
rx:2 32.0s 2.6 Bytes/s (0)
Mar 25 12:41:59 LinuxRMSGatewayBox kernel: [  857.739997] perf interrupt 
took too long (5003 > 5000), lowering kernel.perf_event_max_sample_rate 
to 25000


Not sure where to go from here. I'm going to recreate this setup on 
another box using Ubuntu 12.04.5. I'm currently on Ubuntu 14.04.4 LTS 
(GNU/Linux 4.2.0-34-generic i686).


Thanks,

-Josh


On Thu, Mar 24, 2016 at 9:35 PM, Josh Gibbs <mailto:gibb...@gmail.com>> wrote:


   Thanks for this David... I'm going to run netstat a few times during
   disconnect like you did and see what I see. Will report back in the
   morning... time to put kids to bed.

   Really appreciate your help!

   -Josh WA7FPV

   On Thu, Mar 24, 2016 at 8:22 PM, David Ranch mailto:dra...@trinnet.net>> wrote:


   Hey Josh,

   Btw, I tried to reproduce your issue from home using a local
   command like the following where I'm not actively using -4 but
   -1 is a service that should answer:

   sudo call -s KI6ZHD-4 d710 ki6zhd-1 via k6fb-7   (you cannot
   make local connections so I'm using a remote digitpeater)

   You can see below, I have the established connection, from
   within the session I request to disconnect, and it does
   disconnect.  For a moment, I see the same condition as your
   station but then KI6ZHD-4 receives the final "-UA" frame to
   acknowledge the session should go away and then the funky
   session goes away.  Unless something is really wrong, I'm
   thinking you're Direwolf audio levels might not be very good to
   copy the end connections OR the timing of your TXDELAY and
   TXTAIL might be too short.

   Anyway.. reply to my first email and then this one.

   --David
   KI6ZHD


   hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
   ax25 -an
   Active AX.25 sockets
   Dest   Source Device StateVr/VsSend-Q  Recv-Q
   KI6ZHD-4   KI6ZHD-1   ax0 ESTABLISHED  000/001  0   0
   <-- Good connectionbut I request to disconnect
   KI6ZHD-1   KI6ZHD-4   ax0 ESTABLISHED  001/000  0   0
   *  KI6ZHD-2   ax0 LISTENING000/000  0   0
   *  KI6ZHD-1   ax0 LISTENING000/000  0   0
   *  KI6ZHD-0   ax0 LISTENING000/000  0   0
   *  KI6ZHD-5   ax0 LISTENING000/000  0   0
   hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
   ax25 -an
   Active AX.25 sockets
   Dest   Source Device StateVr/VsSend-Q  Recv-Q
   KI6ZHD-4   KI6ZHD-1   ax0 DISC SENT001/002  0   0
   <--- Connection is going down
   KI6ZHD-1   KI6ZHD-4 ax0 ESTABLISHED  001/001  768 0
   *  KI6ZHD-2   ax0 LISTENING000/000  0   0
   *  KI6ZHD-1   ax0 LISTENING000/000  0   0
   *  KI6ZHD-0   ax0 LISTENING000/000  0   0
   *  KI6ZHD-5   ax0 LISTENING000/000  0   0
   hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
   ax25 -an
   Active AX.25 sockets
   Dest   Source Device StateVr/VsSend-Q  Recv-Q
   KI6ZHD-4   KI6ZHD-1   ax0 DISC SENT001/002  0   0
   <  One side is gone, the other side needs to be ACKed
   *  KI6ZHD-2   ax0 LISTENING000/000  0   0
   *  KI6ZHD-1   ax0 LISTENING000/000  0   0
   *  KI6ZHD-0   ax0 LISTENING000/000  0   0
   *  KI6ZHD-5   ax0 LISTENING000/000  0   0
   hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
   ax25 -an
   Active AX.25 sockets
   Dest   Source Device StateVr/VsSend-Q  Recv-Q
   KI6ZHD-4   KI6ZHD-1   ax0 LISTENING001/002  0  
   0<-- This is the screwy state you are seeing; I

   think this is a display bug but it's minor
   *  KI6ZHD-2   ax0 LISTENING000/000  0   0
   *  KI6ZHD-1   ax0 LISTENING000/000  0   0
   *  KI6ZHD-0   ax0 LISTENING000/000  0   0
   *  KI6ZHD-5   ax0 LISTENING000/000  0   0
   hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
   ax25 -an < I receive the -UA frame and now the
   session goes away
   Active AX.25 sockets
   Dest   Source Device StateVr/VsSend-Q  Recv-Q
   *  KI6ZHD-2   ax0 LISTENING000/000  0   0
   *  KI6ZHD-1   ax0 LISTENING000/000  0   0
   

Re: [ROSE] rose dereferenced pointer kernel panic

[David Ranch]

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 
   --
   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

Re: axlisten: colors for command line

[David Ranch]

Hello Folkert,

Thanks for the patch!  Any chance of posting a before and after screen 
capture to see what it looks like?


--David
KI6ZHD



On 11/19/2018 05:30 AM, folkert wrote:

Hi,

Below you'll find a patch against ax25-apps. It adds the '-C' command
line switch (uppercase c). -c (lowercase) gave you an ncurses colored
listing of all packets received. -C (uppercase) does the same but
without ncurses, e.g. directly on the commandline. It does this with
ANSI-escape codes. You may want this if you want to be able to more
easily scroll back (which can be problematic for ncurses applications)
and to redirect the output (colored) to a file.


diff --git a/AUTHORS b/AUTHORS
index 7b91e72..d0d 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -17,6 +17,7 @@ Heikki Hannikainen OH7LZB
  Alan Cox GW4PTS
  Jean-Paul for rose decoding
  Jeroen Vreeken for INP decoding
+Folkert van Heusden
  
  call:

  Alexander Tietzel DG6XA
diff --git a/listen/listen.c b/listen/listen.c
index 6504ed5..c922fe1 100644
--- a/listen/listen.c
+++ b/listen/listen.c
@@ -203,7 +203,7 @@ int main(int argc, char **argv)
int proto = ETH_P_AX25;
int exit_code = EXIT_SUCCESS;
  
-	while ((s = getopt(argc, argv, "8achip:rtv")) != -1) {

+   while ((s = getopt(argc, argv, "8acChip:rtv")) != -1) {
switch (s) {
case '8':
sevenbit = 0;
@@ -214,6 +214,9 @@ int main(int argc, char **argv)
case 'c':
color = 1;
break;
+   case 'C':
+   a_color = 1;
+   break;
case 'h':
dumpstyle = HEX;
break;
diff --git a/listen/listen.h b/listen/listen.h
index 46ec397..72c185e 100644
--- a/listen/listen.h
+++ b/listen/listen.h
@@ -36,6 +36,7 @@
  
  /* In utils.c */

  extern int color; /* Colorized mode */
+extern int a_color;/* ANSI-colorized mode */
  extern int sevenbit;  /* Are we on a 7-bit terminal? */
  extern int ibmhack;   /* IBM mapping? */
  
diff --git a/listen/utils.c b/listen/utils.c

index 4d99e10..26653a4 100644
--- a/listen/utils.c
+++ b/listen/utils.c
@@ -16,6 +16,7 @@
  #include "listen.h"
  
  int color = 0;			/* Colorized? */

+int a_color = 0;   /* ANSI-colorized mode */
  int sevenbit = 1; /* Are we on a 7-bit terminal? */
  int ibmhack = 0;  /* IBM mapping? */
  
@@ -45,7 +46,7 @@ void lprintf(int dtype, char *fmt, ...)

vsnprintf(str, 1024, fmt, args);
va_end(args);
  
-	if (color) {

+   if (color || a_color) {
for (p = str; *p != '\0'; p++) {
ch = *p;
  
@@ -63,9 +64,20 @@ void lprintf(int dtype, char *fmt, ...)

|| (dtype == T_TIMESTAMP))
ch |= A_BOLD;
  
-			ch |= COLOR_PAIR(dtype);

+   if (color) {
+   ch |= COLOR_PAIR(dtype);
+   addch(ch);
+   }
+   else { /* a_color */
+   if (ch & A_BOLD)
+   printf("\x1b[1m");
+   if (ch & A_REVERSE)
+   printf("\x1b[7m");
  
-			addch(ch);

+   printf("\x1b[%dm%c", 30 + (dtype & 7), ch & 
255);
+
+   printf("\x1b[0m");
+   }
}
} else {
for (p = str; *p != '\0'; p++)


Folkert van Heusden

Linux AX.25 listen program to decode Huffman compressed packets?

[David Ranch]

Hello Everyone,

I'm curious if anyone has seen any Linux "listen" patches that 
incorporate decoding Huffman compressed AX.25 packets?  These compressed 
packets are quite common with Winlink traffic and other programs support 
this compress as well.  Maybe it hasn't been done because of 
difficulties in how the listen program could differentiate compressed 
and non-compressed packets since this is all in the payload of the 
packet not identified in the AX.25 header anywhere.


Some details on it can be found on

   http://www.danplanet.com/blog/2009/11/09/winlink-1988/

--David
KI6ZHD

Re: Fw: ax25d

[David Ranch]

Hello Folkert,


Debian stretch, 4.9.0-4-amd64

ii  ax25-apps 0.0.8-rc4-2amd64
ii  ax25-tools0.0.10-rc4-3   amd64
ii  libax25   0.0.12-rc4-1   amd64


Do not use the stock Debian packages.  They are very very old and have 
TONS of known bugs.  Compile either the top of tree "Official AX.25" 
sources from their Git repo or the VE7FET repo.  There is no clear cut 
recommendation on which to use as it depends on your uses.  You can read 
more about this here:


http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#3.ax25tools



/etc/ax25/ax25ipd.conf
--
mycall FH8GOU-1
socket udp 93
route FH9GOU-1 192.168.64.112 udp 10093 b d


I have an ax25ipd example here:

http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#10d.ax25-ax25ipd

It's worth mentioning that there are known fixes to ax25ipd in the above 
two source trees.  Just updating your code and things might start working.



Btw.. there are also known Linux kernel issues with the AX.25 stack.  I 
don't think it you'll see them with ax25ipd but it's worth mentioning.  
This is a well worn issue and the best I can tell you is to revert to an 
early 3.19.x kernel as a test if you suspect a kernel issue.




ii  ax25-apps0.0.8-rc4-2
ii  ax25-node0.3.2-7.4
ii  ax25-tools   0.0.10-rc4-1
ii  ax25-xtools  0.0.10-rc4-1
ii  libax25  0.0.12-rc4-1


Like above.. please upgrade to the newer TIP code.  Btw, please also do 
NOT use the ax25-node code.  It's known to have functional and security 
issues.  I can whole heartedly recommend URONode:


   http://uronode.sf.net/



/etc/ax25/axports
-
axportu FH9GOU-138400   236 7   AXUDP gateway


It's recommended to have the MTU the same on the same side.  If you plan 
on running Netrom over this like, using a smaller MTU like this is required.




oot@nieteentplink:/etc/ax25# axlisten -8 -a -t axportu
axportu: fm FH8GOU-1 to FH9GOU-1 ctl SABM+ 21:20:25
axportu: fm FH8GOU-1 to FH9GOU-1 ctl SABM+ 21:20:35
axportu: fm FH8GOU-1 to FH9GOU-1 ctl SABM+ 21:20:56
axportu: fm FH8GOU-1 to FH9GOU-1 ctl SABM+ 21:21:26

So traffic comes in but it is unhandled.
I did an strace on ax25d and it just sits there in a select() doing
nothing.


There are also known issues with ax25d too.  Upgrade.  ;-)


--David
KI6ZHD
--
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

Linpac 0.25 released!

[David Ranch]

Hello Everyone,

I'm happy to announce that Linpac 0.25 has been released. This new 
version has some badly needed fixes to resolve known segfault issues 
upon start for newest Linux distros with newer GCC versions. This 
release also lowers the CPU load on your system when running Linpac 
(previously consumed an entire core). More work is needed here to get it 
as low as it should but this is a substantial improvement. Various other 
mail bugs, broken pipe errors, code cleanups, and compiler warning have 
been addressed.


Give it a try!
https://sourceforge.net/projects/linpac/

--David
KI6ZHD
--
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

Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs

[David Ranch]

Hello David,

Thanks for the reply.  I completely admit that there aren't many changes 
going into this section of code.  Unfortunately, we've had some nasty 
breaks that took quite a long while to get fixed.


Can you point me in the direction of this kbuild test robot (URLs, etc) 
so I can better understand if it makes sense to add tests there?  For 
example, do you know if it's "changed based" so only certain tests will 
run if given files are updated?


--David
KI6ZHD


On 10/28/2017 06:45 PM, David Miller wrote:

From: David Ranch 
Date: Sat, 28 Oct 2017 10:53:24 -0700


Does anyone else have thoughts on this topic?


I think you are making a mountain out of a mole hill.

If you care so much about this, set things up so that entities such as
the kbuild test robot run whatever tests you think are necessary.

Otherwise, continually test the stack yourself and report any
regressions here as fast as you can.

If soemone can't be bothered to verify or test someone's change in 2
or 3 days, except in extreme circumstances, I absolutely refuse to
burdon the submitter and let their patches rot in the queue.

That's unacceptable.

That's the proper way to deal with this, without unreasonably
burdoning people who just want to keep the code across the tree modern
and more up to date.

Thank you.

--
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

Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs

[David Ranch]

Hello Gustavo,

Thanks for the reply.  I do appreciate the work but we've had other 
people contribute to keep things up to date but previous minor patches 
broke parts of the AX.25 stack in strange ways.  The fixes weren't hard 
to repair or backout but due to the timing, various Linux distros based 
their releases on the broken kernel code and it's taken a LONG time to
get things healthy for them.  We need be able provide a test harness to 
developers to unit test / regression test their proposed code ideally 
AHEAD of the commit but at least after the commit.


I'm still failing to find any Linux groups that offer some sort of 
automated build & test environment (Travis, Jenkins, etc) tracking 
various kernel branches, etc.  It's gotta be out there (many of them in 
fact) but I'm struggling to find them.


For example, here is an excellent article about what *Intel* is doing 
for their graphics drivers but I need something that the general 
community can leverage for say various protocol stacks (TCP/IP, AX.25, 
whatever):


   https://lwn.net/Articles/735468/

From that article, it seems that maybe this could be a good place to start:

   https://01.org/lkp
   https://github.com/intel/lkp-tests

Looks like a good start but is that what the majority of the Linux 
kernel folk use today?  Is it the right group for non-scaled out unit 
testing that I seek?  I also think this email-centric approach might be 
an overly broad approach with WAY too much noise for various development 
areas.


Does anyone else have thoughts on this topic?

--David
KI6ZHD


On 10/27/2017 12:48 PM, Gustavo A. R. Silva wrote:

Hi David,

Quoting David Ranch :


Hello Gustavo,

I appreciate you working on keeping up the kernel and maintaining some
of the older feature areas like AX.25, Netrom, etc.  Other than
auditing your code changes, can you tell me what you're changing? I've
been attempting to find who / where does regression tests for the
Linus kernel to potentially ADD test suites for this area.  In the
recent past, we have seen a lot of toxicity creep into the kernel
because no one is testing their changes and backing out this toxic
code out of released Linux distributions takes a VERY long time.



Here you can see the patch I'm proposing to refactor some code:
https://patchwork.kernel.org/patch/10029119/

It does not add any new functionality. It's just a small function that
helps to modularize and reduce the size of the code in the nr_add_node()
function.

The function I'm proposing (re_sort_routes) re-sort the routes in
quality order. It takes as arguments a pointer to the nr_node structure
which contains the routes within and the indexes of the routes to re-sort.

This function also replaces a "manual" swap of the routes with a call to
the swap macro.

Thanks
--
Gustavo A. R. Silva


I'm willing to try and help here but I really would like to follow
some team's guidelines of how they would like tests to be created,
supported, etc.  Be it in VMs, containers, specific automation
languages, etc.

--David
KI6ZHD




On 10/26/2017 10:50 PM, Gustavo A. R. Silva wrote:

The aim of this patchset is firstly to refactor code in nr_route.c in
order to make it
easier to read and maintain and, secondly, to mark some expected
switch fall-throughs
in preparation to enabling -Wimplicit-fallthrough.

I have to mention that I did not implement any unit test.
If someone has any suggestions on how I could test this piece of code
it'd be greatly appreciated.

Thanks

Changes in v2:
 - Make use of the swap macro and remove inline keyword as suggested by
   Walter Harms and Kevin Dawson.

Changes in v3:
 - Update subject for both patches.
 - Add this cover letter as suggested by David Miller.

Gustavo A. R. Silva (2):
  net: netrom: nr_route: refactor code in nr_add_node
  net: netrom: nr_route: mark expected switch fall-throughs

 net/netrom/nr_route.c | 62
---
 1 file changed, 19 insertions(+), 43 deletions(-)








--
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

Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs

[David Ranch]

Hello Gustavo,

I appreciate you working on keeping up the kernel and maintaining some 
of the older feature areas like AX.25, Netrom, etc.  Other than auditing 
your code changes, can you tell me what you're changing? I've been 
attempting to find who / where does regression tests for the Linus 
kernel to potentially ADD test suites for this area.  In the recent 
past, we have seen a lot of toxicity creep into the kernel because no 
one is testing their changes and backing out this toxic code out of 
released Linux distributions takes a VERY long time.


I'm willing to try and help here but I really would like to follow some 
team's guidelines of how they would like tests to be created, supported, 
etc.  Be it in VMs, containers, specific automation languages, etc.


--David
KI6ZHD




On 10/26/2017 10:50 PM, Gustavo A. R. Silva wrote:

The aim of this patchset is firstly to refactor code in nr_route.c in order to 
make it
easier to read and maintain and, secondly, to mark some expected switch 
fall-throughs
in preparation to enabling -Wimplicit-fallthrough.

I have to mention that I did not implement any unit test.
If someone has any suggestions on how I could test this piece of code
it'd be greatly appreciated.

Thanks

Changes in v2:
  - Make use of the swap macro and remove inline keyword as suggested by
Walter Harms and Kevin Dawson.

Changes in v3:
  - Update subject for both patches.
  - Add this cover letter as suggested by David Miller.

Gustavo A. R. Silva (2):
   net: netrom: nr_route: refactor code in nr_add_node
   net: netrom: nr_route: mark expected switch fall-throughs

  net/netrom/nr_route.c | 62 ---
  1 file changed, 19 insertions(+), 43 deletions(-)



--
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

Fwd: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node

[David Ranch]

Hey Everyone,

There are a LOT of patches coming in for the Linux AX.25 stack such as 
this one below where people are proposing changes and they OPENLY state:


   "This code was tested by compilation only"

That's NOT testing.  We have seen over the last year or two, several 
toxic commits have come into the kernel that have been extremely painful 
to rollback and/or modify to remove the toxicity.  I completely 
appreciate people trying to keep the AX.25 stack cleaned up but it's 
CRITICAL that we get some AX.25 regress suites running so people can 
confirm that their proposed commits don't break anything before allowing 
the commits.   I've been trying to find out who to discuss this proposed 
testing harness but I've been unable to get a name.  Once I get a name, 
I'm happy to help contribute some testing suites, etc. once I understand 
the framework that this team(s) use.


--David
KI6ZHD


 Forwarded Message 
Subject:[PATCH v2 2/2] net: netrom: refactor code in nr_add_node
Date:   Sun, 22 Oct 2017 20:08:40 -0500
From:   Gustavo A. R. Silva 
To: 	Ralf Baechle , David S. Miller 
, walter harms 
CC: 	linux-hams@vger.kernel.org, net...@vger.kernel.org, 
linux-ker...@vger.kernel.org, Gustavo A. R. Silva 




Code refactoring in order to make it easier to read and maintain.

Signed-off-by: Gustavo A. R. Silva 
---
This code was tested by compilation only.

Changes in v2:
 Make use of the swap macro and remove inline keyword.

 net/netrom/nr_route.c | 59 ++-
 1 file changed, 16 insertions(+), 43 deletions(-)

diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index fc9cadc..505e142 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -80,6 +80,19 @@ static struct nr_neigh *nr_neigh_get_dev(ax25_address 
*callsign,
 
 static void nr_remove_neigh(struct nr_neigh *);
 
+/*  re-sort the routes in quality order.*/

+static void re_sort_routes(struct nr_node *nr_node, int x, int y)
+{
+   if (nr_node->routes[y].quality > nr_node->routes[x].quality) {
+   if (nr_node->which == x)
+   nr_node->which = y;
+   else if (nr_node->which == y)
+   nr_node->which = x;
+
+   swap(nr_node->routes[x], nr_node->routes[y]);
+   }
+}
+
 /*
  * Add a new route to a node, and in the process add the node and the
  * neighbour if it is new.
@@ -90,7 +103,6 @@ static int __must_check nr_add_node(ax25_address *nr, const 
char *mnemonic,
 {
struct nr_node  *nr_node;
struct nr_neigh *nr_neigh;
-   struct nr_route nr_route;
int i, found;
struct net_device *odev;
 
@@ -251,50 +263,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,

/* Now re-sort the routes in quality order */
switch (nr_node->count) {
case 3:
-   if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
-   switch (nr_node->which) {
-   case 0:
-   nr_node->which = 1;
-   break;
-   case 1:
-   nr_node->which = 0;
-   break;
-   }
-   nr_route   = nr_node->routes[0];
-   nr_node->routes[0] = nr_node->routes[1];
-   nr_node->routes[1] = nr_route;
-   }
-   if (nr_node->routes[2].quality > nr_node->routes[1].quality) {
-   switch (nr_node->which) {
-   case 1:  nr_node->which = 2;
-   break;
-
-   case 2:  nr_node->which = 1;
-   break;
-
-   default:
-   break;
-   }
-   nr_route   = nr_node->routes[1];
-   nr_node->routes[1] = nr_node->routes[2];
-   nr_node->routes[2] = nr_route;
-   }
+   re_sort_routes(nr_node, 0, 1);
+   re_sort_routes(nr_node, 1, 2);
/* fall through */
case 2:
-   if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
-   switch (nr_node->which) {
-   case 0:  nr_node->which = 1;
-   break;
-
-   case 1:  nr_node->which = 0;
-   break;
-
-   default: break;
-   }
-   nr_route   = nr_node->routes[0];
-   nr_node->routes[0] = nr_node->routes[1];
-   nr_node->routes[1] = nr_route;
-   }
+   re_sort_routes(nr_node, 0, 1);
case 1:
break;
}
--
2.7.4

--
To unsubscribe fro

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 majord...@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 majord...@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 
Organization:   Bundesamt f. Strahlenschutz
To: 	David Ranch , f6bvp , Basil Gunn 

CC: 	C Schuman , linux-hams@vger.kernel.org, Ralf 
Bächle DL5RB , Richard Stearn 






f6bvp  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.c2017-04-03 19:02:14.205800053 +0200
+++ b/net/rose/af_rose.c2017-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 majord...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 20/39] Annotate hardware config module parameters in drivers/net/hamradio/

[David Ranch]

Hello Everyone,

Considering some of the recent toxicity that snuck into the Linux AX.25 
codebase, is there anyone here that is still using some of the Baycom 
TNC hardware that could apply this patch and TEST their systems to 
ensure they continue to work as expected?


--David
KI6ZHD


On 12/01/2016 04:32 AM, David Howells wrote:

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/hamradio/.

Suggested-by: One Thousand Gnomes 
Signed-off-by: David Howells 
cc: Thomas Sailer 
cc: Joerg Reuter 
cc: linux-hams@vger.kernel.org
cc: net...@vger.kernel.org
---

  drivers/net/hamradio/baycom_epp.c |2 +-
  drivers/net/hamradio/baycom_par.c |2 +-
  drivers/net/hamradio/baycom_ser_fdx.c |4 ++--
  drivers/net/hamradio/baycom_ser_hdx.c |4 ++--
  drivers/net/hamradio/dmascc.c |2 +-
  5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/hamradio/baycom_epp.c 
b/drivers/net/hamradio/baycom_epp.c
index 78dbc44540f6..a50b72144b93 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -1172,7 +1172,7 @@ static int iobase[NR_PORTS] = { 0x378, };
  
  module_param_array(mode, charp, NULL, 0);

  MODULE_PARM_DESC(mode, "baycom operating mode");
-module_param_array(iobase, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
  MODULE_PARM_DESC(iobase, "baycom io base address");
  
  MODULE_AUTHOR("Thomas M. Sailer, sai...@ife.ee.ethz.ch, hb9...@hb9w.che.eu");

diff --git a/drivers/net/hamradio/baycom_par.c 
b/drivers/net/hamradio/baycom_par.c
index 072cddce9264..cb7fe200f347 100644
--- a/drivers/net/hamradio/baycom_par.c
+++ b/drivers/net/hamradio/baycom_par.c
@@ -481,7 +481,7 @@ static int iobase[NR_PORTS] = { 0x378, };
  
  module_param_array(mode, charp, NULL, 0);

  MODULE_PARM_DESC(mode, "baycom operating mode; eg. par96 or picpar");
-module_param_array(iobase, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
  MODULE_PARM_DESC(iobase, "baycom io base address");
  
  MODULE_AUTHOR("Thomas M. Sailer, sai...@ife.ee.ethz.ch, hb9...@hb9w.che.eu");

diff --git a/drivers/net/hamradio/baycom_ser_fdx.c 
b/drivers/net/hamradio/baycom_ser_fdx.c
index 7b916d5b14b9..36d49c89d601 100644
--- a/drivers/net/hamradio/baycom_ser_fdx.c
+++ b/drivers/net/hamradio/baycom_ser_fdx.c
@@ -614,9 +614,9 @@ static int baud[NR_PORTS] = { [0 ... NR_PORTS-1] = 1200 };
  
  module_param_array(mode, charp, NULL, 0);

  MODULE_PARM_DESC(mode, "baycom operating mode; * for software DCD");
-module_param_array(iobase, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
  MODULE_PARM_DESC(iobase, "baycom io base address");
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
  MODULE_PARM_DESC(irq, "baycom irq number");
  module_param_array(baud, int, NULL, 0);
  MODULE_PARM_DESC(baud, "baycom baud rate (300 to 4800)");
diff --git a/drivers/net/hamradio/baycom_ser_hdx.c 
b/drivers/net/hamradio/baycom_ser_hdx.c
index f9a8976195ba..1b310493ba8a 100644
--- a/drivers/net/hamradio/baycom_ser_hdx.c
+++ b/drivers/net/hamradio/baycom_ser_hdx.c
@@ -642,9 +642,9 @@ static int irq[NR_PORTS] = { 4, };
  
  module_param_array(mode, charp, NULL, 0);

  MODULE_PARM_DESC(mode, "baycom operating mode; * for software DCD");
-module_param_array(iobase, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
  MODULE_PARM_DESC(iobase, "baycom io base address");
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
  MODULE_PARM_DESC(irq, "baycom irq number");
  
  MODULE_AUTHOR("Thomas M. Sailer, sai...@ife.ee.ethz.ch, hb9...@hb9w.che.eu");

diff --git a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c
index e4137c1b3df9..f94ca7b91899 100644
--- a/drivers/net/hamradio/dmascc.c
+++ b/drivers/net/hamradio/dmascc.c
@@ -274,7 +274,7 @@ static unsigned long rand;
  
  MODULE_AUTHOR("Klaus Kudielka");

  MODULE_DESCRIPTION("Driver for high-speed SCC boards");
-module_param

Re: [PATCH v05 69/72] uapi rose.h: glibc netrose/rose.h header file compatibility fixes

[David Ranch]

Hello Mikko,

It would be great to see a solution to this long standing issue.  I 
would highlight that we have two pockets of AX.25 that need to be 
considered aligned IMHO:


#Official AX.25 repo but sometimes doesn't include all available fixes
http://git.linux-ax25.org/cgit/libax25.git/tree/netax25/ax25.h

#Unofficial AX.25 repo which sometimes has more fixes
https://github.com/ve7fet/linuxax25/blob/master/libax25/netax25/ax25.h

#Current Glibc version
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/unix/sysv/linux/netax25/ax25.h;hb=HEAD


Fortunately, it looks like both of these repos have the same file 
(confirmed with a diff).  Comparing to the Glibc versio, the differences 
are minimal:



diff -u ax25.h-officialax25 ax25.h-glibc
--- ax25.h-officialax25 2016-11-16 13:53:27.0 -0800
+++ ax25.h-glibc2016-11-16 14:14:03.0 -0800
@@ -1,4 +1,4 @@
-/* Copyright (C) 1997, 1999 Free Software Foundation, Inc.
+/* Copyright (C) 1997-2016 Free Software Foundation, Inc.
This file is part of the GNU C Library.

The GNU C Library is free software; you can redistribute it and/or
@@ -12,15 +12,14 @@
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
-   License along with the GNU C Library; if not, write to the Free
-   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
-   02111-1307 USA.  */
+   License along with the GNU C Library; if not, see
+   .  */

 #ifndef _NETAX25_AX25_H
 #define _NETAX25_AX25_H1

 #include 
-#include 
+#include 

 /* Setsockoptions(2) level.  Thanks to BSD these must match 
IPPROTO_xxx.  */

 #define SOL_AX25   257


--David
--
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

Re: [PATCH v05 69/72] uapi rose.h: glibc netrose/rose.h header file compatibility fixes

[David Ranch]

Hello Mikko,

Somewhat related, the ax25.h file from libax25-devel also has conflicts 
with the Glibc's ax.25.h.  This creates trouble so if we could get a fix 
for that, that would be appreciated as well though it might be a Glibc 
issue and not a kernel issue.


--David



On 08/27/2016 10:59 PM, Mikko Rapeli wrote:

On Fri, Aug 26, 2016 at 05:38:00PM +0200, walter harms wrote:

perhaps this not tested snipped would make sure that
you have included linux/rose.h ?

#ifndef ROSE_KERNEL_H
#include 
#endif

#include 

Sorry, I did not quite get this.

 has conflicting definitions with glibc .
The patches fixes the uapi headers  so that it hides
definitions if  from glibc was already included.

-Mikko
--
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


--
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

Re: PATCH 1/1] AX.25: Close socket connection on session completion

[David Ranch]

Hello David,

Unless I'm doing something wrong, it seems this patch has only been 
applied to the newest

kernel:

   Git/linux-stable$ git tag -l --contains 
4a7d99ea1b27734558feb6833f180cd38a159940

   v4.7-rc6

How can we get this critical fix applied to the other stable kernel 
versions?  I would really hate
to depend on all the various Distro packagers to miss on picking this up 
as this is a critical

toxicity fix.


Reference: http://www.spinics.net/lists/linux-hams/msg03628.html

--David




On 06/18/2016 08:55 PM, David Miller wrote:

From: Basil Gunn 
Date: Thu, 16 Jun 2016 09:42:30 -0700


A socket connection made in ax.25 is not closed when session is
completed.  The heartbeat timer is stopped prematurely and this is
where the socket gets closed. Allow heatbeat timer to run to close
socket. Symptom occurs in kernels >= 4.2.0

Originally sent 6/15/2016. Resend with distribution list matching
scripts/maintainer.pl output.

Signed-off-by: Basil Gunn 

Applied.
--
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


--
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

Re: PATCH 1/1] AX.25: Close socket connection on session completion

[David Ranch]

Hello David,

I don't have a specific commit # for you at the moment but there have been a 
few serious regressions since 4.1.x.  When new code gets commited, are there 
any systems to run regession tests on?  I'd be willing to build up a pair of 
VMs that can be run with scripts to verify say basic sanity for kissattach, 
ax.25, netrom, rose, etc.

Btw, once I get back, I hope to pursue some additional negative case fixes:  
(pulling a usb-to-serial adapter when used with kiss-attach will panic the 
kernel, ifconfig rose0 down will take the kernel to 100%, and a data corruption 
issue for large transfers (2MB+).

Thanks for your help!

--David
KI6ZHD
--David

On June 17, 2016 12:33:19 PM CST, David Miller  wrote:
>From: Basil Gunn 
>Date: Thu, 16 Jun 2016 09:42:30 -0700
>
>> A socket connection made in ax.25 is not closed when session is
>> completed.  The heartbeat timer is stopped prematurely and this is
>> where the socket gets closed. Allow heatbeat timer to run to close
>> socket. Symptom occurs in kernels >= 4.2.0
>> 
>> Originally sent 6/15/2016. Resend with distribution list matching
>> scripts/maintainer.pl output.
>> 
>> Signed-off-by: Basil Gunn 
>
>What changed in 4.2.x that broke this?
>--
>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

--
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

Re: Can only connect to RMS gateway once

[David Ranch]

+ David Miller for comments


I see a change on June 25, 2015, and a few others on that file that seem 
like they could be the issue:


https://github.com/torvalds/linux/commits/master/net/ax25/af_ax25.c


--David


On 06/04/2016 01:43 PM, Basil Gunn wrote:

This isn't a final solution but the problem is in:

  sock_set_flag(sk, SOCK_DESTROY);

in routine ax25_release() in file net/ax25/af_ax25.c which does what it
is supposed to do in kernel 4.1.21 but NOT in kernels 4.2.8 & above. It
should destroy & free the socket when disconnecting.

For my 4.2.8 kernel If I add this after the sock_set_flag() call in
ax25_release() then the connection is released after disconnect & I can
reconnect again.

 release_sock(sk);
 ax25_disconnect(ax25, 0);
 lock_sock(sk);
 ax25_destroy_socket(ax25);

>From the af_ax25 code in the 4.1.21 kernel, it expects sock_set_flag(sk, 
SOCK_DESTROY); to
  ax25_destroy_socket
  ax25_free_sock



/Basil n7nix

--
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


--
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

Re: Can only connect to RMS gateway once

[David Ranch]

Hey Basil,

Thanks for digging into this.  Few things to check:

GOOD - the 4.1.21 kernel was released on 4/6/16
BAD - 4.2.8 kernel was released on 12/16/15

Can you try a vanilla kernel with:
   - 4.2.7, released on 12/9/16 to see if that's OK
   - 4.1.25, released on 5/23/16 to see if that's ok?  (a worse case 
4.1.x test)


If 4.1.25 is bad:
   - Try 4.1.14, released on 12/9/15 to see if that's ok?

If that's ok, try:
   - 4.1.15 released on 12/15/15
   - 4.1.16 released on 1/23/16

--David




On 06/03/2016 01:16 PM, Basil Gunn wrote:

Have you tried to disable smp (in grub, boot the kernel with the
cmdline option nosmp)? Did then the problem still occur?

I disabled SMP and the problem of socket remains open after disconnect
still occurs with kernels >= 4.2.

cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1
root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes
maxcpus=0 rootwait


I built a 4.1.21 kernel from the raspbian repo
https://github.com/raspberrypi/linux/tree/rpi-4.1.y

and the problem does NOT exist with that kernel.

I built a 4.2.8 kernel from the raspbian repo
https://github.com/raspberrypi/linux/tree/rpi-4.2.y

and the problem DOES exist with that kernel.
Showing connection listening after final disconnect.

Active AX.25 sockets
Dest   Source Device  StateVr/VsSend-Q  Recv-Q
N7NIX-0N7NIX-11   ax0 LISTENING001/004  0   0
*  N7NIX-11   ax0 LISTENING000/000  0   0


--
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

Re: Can only connect to RMS gateway once

[David Ranch]

Hey Thomas,

I followed up with Greg Kroah-Hartman who has been very helpful in the 
past for some of my kernel contributions.  He had the following to say:


--
 Forwarded Message 
Subject: Re: Fwd: Re: Can only connect to RMS gateway once - AX.25 stack 
issues in recent kernel versions..

Date: Fri, 3 Jun 2016 08:45:23 -0700
From: Greg Kroah-Hartman 
To: David Ranch 

On Fri, Jun 03, 2016 at 08:39:39AM -0700, David Ranch wrote:
>
> [Resend to move past your email bot]
>
> Hey Greg,
>
> I know you're a busy guy in the world of everything Linux but I was 
curious
> if you can help direct some resources (people time) towards the AX.25 
stack.

> There are a few issues that have crept into the kernel here due to it's
> ongoing cleanup efforts and though patches have been offered, they 
weren't

> committed into Git.

I don't see where the patches were sent, do you have pointers to them?
What subsystem were they for? And why were they rejected?

And if you need/want help with this, please post on the driverdevel
mailing list (for the staging tree, the address is in the MAINTAINERS
file), there are lots of people there looking for things to help out
with.

thanks,

greg k-h
--

Can you find your previous patches and any other troubleshooting details 
you've recorded (SMP issues, etc) put them into a easy to follow email? 
 With that, I'd be happy to cheerlead this effort to Greg and the 
driverdevel group to see if we can get some help here.


--David
KI6ZHD



On 06/03/2016 01:19 AM, Thomas Osterried wrote:



Am 03.06.2016 um 02:01 schrieb David Ranch :


Hey Basil,

Good to hear from you.. hope all is well.

Yes.. it's been reported and Thomas verified it but I haven't heard of any 
fixes yet ( I did send out a prod last month but no response)


In another thread (Message-Id: <56fad2ca.5060...@trinnet.net> you answered my 
question, that those machines are running with an smp-kernel.
Have you tried to disable smp (in grub, boot the kernel with the cmdline option 
nosmp)?
Did then the problem still occur?

Those bugs are very hard to trace, because you cannot really provoke them; they 
occur suddenly.

With kernel ax25 on smp machines I have discovered other severe bugs (ax25 data 
corruption), that also needs to be fixed.

Imho, our greatest problem is that there too few kernel ax25 developers around 
in our ham community.

In the meantime, I encourage to disable SMP to minimize the problems with 
kernel ax25.


Also look at my posting Message-Id: 
<20160215140035.gf24...@x-berg.in-berlin.de> from 2016-02-15. There was no 
response on the list, and nothing got into the kernel
(as far as I can see - my approach is to look at 
https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/master/drivers/net/hamradio
 ; perhaps I'm wrong with that ).

And on 2016-02-17 I asked for submitting my patch to mkiss.c that fixes a race 
condition that leads to kernel panic (): when the kernel ax25 stack sends 
data to the interface right after you plugged off your usb-serial-adapter.
It took me hours to discover, test and submit that, but nothing happens.
(David, it was in my mail to you with Message-Id: 
<9e57f6d5-9bfc-4c64-b2e4-7c332c502...@osterried.de> )


Thus, those problems are discussed here year after year, again and again, and 
periodically people spend time to develop fixes others have already done (but 
never made it into the mainline kernel).

I'm very frustrated in that, and in a review of my past efforts I simply have to say now 
"sorry, I cannot help".


vy 73,
- Thomas  dl9sau



--David
KI6ZHD



 Forwarded Message 
Subject:Re: AX.25 / ax25d socket close issue on Ubuntu 14.04 but not on 
12.04
Date:   Tue, 29 Mar 2016 09:00:37 +0200
From:   Thomas Osterried 
To: David Ranch 
CC: Ralf Bächle DL5RB , Bernard, f6bvp 




Am 28.03.2016 um 22:21 schrieb David Ranch :

Hey Ralf, Thomas, Bernard,

I've been helping a user here who is running the LinuxRMS gateway on his Ubuntu 
14.04 machine and when the remote station terminates the session, it leaves an 
AX.25 session on his computer *forever*.. never times out:

Active AX.25 sockets
Dest   Source Device  StateVr/VsSend-Q  Recv-Q
WA7FPV-0   WA7FPV-10  ax0 LISTENING001/003  0   0

He built up an Ubuntu 12.04 machine with the same LinuxRMS/ax25d service and 
this does NOT happen.  He then sent me the below strace.  Any thoughts on where 
this issue is coming from?


Hello David,

just for a quick answer (I'm on journey): it's coming from a kernel bug in the 
ax25 part.
You already have Cc'ed Ralf .
If I remember correctly, he spoke some weeks ago also about this issue.
I also know of those problems, which are very rare.

My question is: does it happen on SMP (multiprocessor-machine)?

vy 73,
- Thomas  dl9sau

Re: Can only connect to RMS gateway once

[David Ranch]

Hey Basil,

Good to hear from you.. hope all is well.

Yes.. it's been reported and Thomas verified it but I haven't heard of 
any fixes yet ( I did send out a prod last month but no response)


--David
KI6ZHD



 Forwarded Message 
Subject: 	Re: AX.25 / ax25d socket close issue on Ubuntu 14.04 but not 
on 12.04

Date:   Tue, 29 Mar 2016 09:00:37 +0200
From:   Thomas Osterried 
To: David Ranch 
CC: Ralf Bächle DL5RB , Bernard, f6bvp 




Am 28.03.2016 um 22:21 schrieb David Ranch :

Hey Ralf, Thomas, Bernard,

I've been helping a user here who is running the LinuxRMS gateway on his Ubuntu 
14.04 machine and when the remote station terminates the session, it leaves an 
AX.25 session on his computer *forever*.. never times out:

Active AX.25 sockets
Dest   Source Device  StateVr/VsSend-Q  Recv-Q
WA7FPV-0   WA7FPV-10  ax0 LISTENING001/003  0   0

He built up an Ubuntu 12.04 machine with the same LinuxRMS/ax25d service and 
this does NOT happen.  He then sent me the below strace.  Any thoughts on where 
this issue is coming from?


Hello David,

just for a quick answer (I'm on journey): it's coming from a kernel bug in the 
ax25 part.
You already have Cc'ed Ralf .
If I remember correctly, he spoke some weeks ago also about this issue.
I also know of those problems, which are very rare.

My question is: does it happen on SMP (multiprocessor-machine)?

vy 73,
- Thomas  dl9sau



--David



 Forwarded Message 
Subject:Re: AX.25 Help...
Date:   Mon, 28 Mar 2016 12:52:25 -0700
From:   Josh Gibbs 
To: David Ranch 

Confirmed that starting Direwolf on the Ubuntu 14 box with your script made no 
difference. Socket still hangs up. I connected to the rmsgw process with 
strace, and then sent the bye command:

select(5, [0 4], NULL, NULL, NULL)  = 1 (in [0])
read(0, "b\r", 8192)= 2
write(4, "b\r", 2)  = 2
read(0, 0x8058180, 8192)= -1 EAGAIN (Resource temporarily 
unavailable)
select(5, [0 4], NULL, NULL, NULL)  = 1 (in [4])
recv(4, "D", 1, MSG_PEEK|MSG_DONTWAIT)  = 1
recv(4, "Disconnecting...\r", 8192, 0)  = 17
write(1, "Disconnecting...\r", 17)  = 17
recv(4, 0x8058180, 8192, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
select(5, [0 4], NULL, NULL, NULL)  = 1 (in [4])
recv(4, "", 1, MSG_PEEK|MSG_DONTWAIT)   = 0
time(NULL)  = 1459193715
send(3, "<134>Mar 28 12:35:15 rmsgw[1417]"..., 85, MSG_NOSIGNAL) = 85
write(1, "; INFO: Connection closed by CMS"..., 51) = 51
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [], 0}, 8) = 0
nanosleep({1, 0}, 0xbfad3bac)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(4)= 0
time(NULL)  = 1459193716
write(1, "; Sent: 81 Bytes / Received: 2 B"..., 61) = 61
write(1, "; W7AUX de WA7FPV-10 SK\n", 24) = 24
time(NULL)  = 1459193716
time(NULL)  = 1459193716
send(3, "<133>Mar 28 12:35:16 rmsgw[1417]"..., 84, MSG_NOSIGNAL) = 84
close(4)= -1 EBADF (Bad file descriptor)
exit_group(0)   = ?
+++ exited with 0 +++

I'm thinking that close(4) near the end is supposed to close the socket, but is 
resulting in -1 EBADF (Bad file descriptor).

I'm going to have a look in the code when I have more time to poke at this, but 
for now I at least have a working RMS Gateway on the Ubuntu 12 box! Appreciate 
all your help with this. I will let you know when I get to the root of it all, 
if you are interested!

-Josh




--
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

Re: [Linux-ham] netrom

[David Ranch]

Hey Folkert,



My script is as below. If I remove the modprobe/nrattach and then do
that manually afterwards, then it does not work.


That's strange but to be honest, I would recommend you to do all your 
base infrastructure commands first (kissattach, netrom, ax25d, mheard, 
etc) FIRST.  Then start some of your AX.25 applications (axdigi, 
aprsdigi, etc) next and then your beacons last.




/usr/sbin/kissattach /dev/ttyAMA0 axportr 192.168.45.8


Btw, after you run this command, check out the output of "ifconfig -a" 
and check the subnet mask.  I bet it's wrong.  You'll need to manually 
correct this with ifconfig after the fact.  This is what my packetrig.sh 
script does.





/usr/sbin/aprsdigi --verbose \
 --kill_dupes \
 --kill_loops \
 --int ax25:FH1GOU-1:RELAY,WIDE,FOO,TRACE \
 --interface udp:172.29.0.40/9978/5 \
 --interface udp:cbaprs.de/27235/5 \
 | tee -a /var/aprsigi.log



Please do not use the legacy RELAY syntax.  Only use WIDE and maybe 
TRACE.  I'm not very familiar with aprsdigi but have you seen Aprx?




Maybe it has to do with the axlisten running in the bg. If Im right it
opens the interfaces in promisquous mode, maybe that blocks nrattach.


That's possible but that would be a bug in my book.



4.1.12+ raspberry pi, raspbian
ii  ax25-apps 0.0.8-rc2+cvs20120204-2 armhf
AX.25 ham radio applications
ii  ax25-node 0.3.2-7.4 armhfAmateur Packet 
Radio Node program
ii  ax25-tools0.0.10-rc2+cvs20120204-3 armhf
tools for AX.25 interface configuration
ii  ax25-xtools   0.0.10-rc2+cvs20120204-3 armhf
tools for AX.25 interface configuration -- X11-based
ii  libax25   0.0.12-rc2+cvs20120204-2 armhf
ax25 library for hamradio applications
ii  libax25-dev   0.0.12-rc2+cvs20120204-2 armhf
ax25 library development files


Yeah.. that's OLD code (2012).  If you want to run the Official AX.25 
tools (not always the most current btw), I recommend you use the most 
current code in Git - http://www.linux-ax25.org/wiki/GIT


More recommended, try building VE7FET's version of the tools: 
https://github.com/ve7fet/linuxax25




The one included in debian.


Not recommended (see above) as you are missing some key fixes 
(especially if you're going to be doing AMPR / IPIP net stuff)


--David
--
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

Re: [Linux-ham] netrom

[David Ranch]

Hello Folkert,


Something odd happened: now it suddenly works!
What I did different is axportl instead of axport0.
But on the other system axport0 runs fine? Puzzling.


There are only two things I can think of that might cause this... an 
issue with the kernel or an issue with the ax25 apps/tools you installed.


What distro version and kernel version are you running?
Are you using the Official AX.25 tools or VE7FET's version?


Btw, I've been thinking about your LoRa project and that seems really 
pretty cool to me.  I think I'll have to give it a try!  Thanks for 
posting all that Arudino KISS code, etc.  I wonder how hard it would

be to add some additional RF power to those units.

--David
KI6ZHD
--
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

Re: Soundmodem patch for AFSK operation a low bit-rates (1/2)

[David Ranch]

Hey Guido,


Yes, I've posted my patch there too, but it seems they don't want to fix the 
broken source code!...


That doesn't surprise me as the soundmodem program has been essentially 
on life-support for years now.  I personally recommend people use use 
Direwolf these days (works on Mac and Windows too).  It supports 
superior decodes, does 300/1200/9600 packet as well.


--David
KI6ZHD
--
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

Re: Soundmodem patch for AFSK operation a low bit-rates (1/2)

[David Ranch]

Hello Guido,

Thanks for working on those fixes.  I think the best place for this 
would be the soundmodem repository at:


http://gna.org/projects/soundmodem

Interestingly enough, Thomas Sailer has been updating the soundmodem 
code in recent times for new automake related fixes.


Ps.  What version of soundmodem should these patches be applied against?

--David
KI6ZHD


On 04/03/2016 09:03 AM, Guido Trentalancia wrote:

Hello.

Here is the latest version of a set of two patches for the soundmodem
application that I have created to fix AFSK operation at bit-rates
lower than 1200 baud (e.g. 300 baud for HF packet radio or APRS).

Patch 1/2 follows:


--
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

Re: [Linux-ham] netrom

[David Ranch]

Hello Misko,

David, in the past I used 'non-ifconfig'-like names (as you suggest) 
in axports and elsewhere. But for the simplicity, some few years ago I 
switched to using the names Folkert uses. And I did not notice any 
functional difference ... Both approaches work for me. Is there any 
requirement or constraint in the kernel, related to that?


Names like "ax0", nr0", "rose0, etc. are all reserved names in Linux 
ax.25 land and they have very specific meanings and connotation. 
Overloading those names with the user facing interface will confuse you 
to what should be used for various applications, etc.   I'm not exactly 
sure WHY the LInux AX.25 stack was built this way but it IS and I don't 
recommend anyone do this though, to your very point, it does work.


--David
KI6ZHD
--
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

Re: icmp

[David Ranch]

Considering I have no experience with some of these LoRa data modules, 
what is this resulting in terms of modulation type, data rate and over 
what kind of distance?


--David
KI6ZHD


On 04/01/2016 01:14 PM, folkert wrote:

Ah darn, of course!
Thanks.

Regarding the lora configuration: a friend of mine gave me the
configuration-parameters for best reliability for a long distance:

const RH_RF95::ModemConfig cfg = {
 // Register 0x1D:
 // BW CR  0=explicit
 (8 << 4) | (4 << 1) | (0 << 0),
 // Register 0x1E:
 // SF   CRC enable
 (10 << 4) | (1 << 2),
 // Register 0x26:
 // bit3 = LowDataRateOptimization
 (0 << 3)
 };
 rf95.setModemRegisters(&cfg);
 rf95.setFrequency(869.850);
 rf95.setPreambleLength(8);

Packet loss is 12-15%.


On Fri, Apr 01, 2016 at 12:41:59PM -0700, David Ranch wrote:


This is because you have your window setting per the /etc/ax25/axports file
set to 1.   Change it to say 4 and things should work better.

Btw.. what speed are you running your LoRa network at?  A round trip time of
1.6 seconds is quite slow but maybe that's due to the serialization delays
of running your network at say 300bps!

--David


On 04/01/2016 12:07 PM, folkert wrote:

An other strange thing: I can't have 2 packets in that 2 second
interval. E.g. a traceroute only works if I add -N 1 -w 2.

On Fri, Apr 01, 2016 at 08:42:26PM +0200, folkert wrote:

Hi,

This evening I succeeded in doing ICMP over AX.25 over LoRa(!)!

root@savannah:~/data/mkiss_moteino# ping -i 5 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=4 ttl=64 time=4524 ms
64 bytes from 192.168.5.1: icmp_seq=7 ttl=64 time=1601 ms
64 bytes from 192.168.5.1: icmp_seq=8 ttl=64 time=1601 ms
64 bytes from 192.168.5.1: icmp_seq=9 ttl=64 time=1601 ms
^C
--- 192.168.5.1 ping statistics ---
9 packets transmitted, 4 received, 55% packet loss, time 40005ms
rtt min/avg/max/mdev = 1601.358/2332.248/4524.246/1265.550 ms



Folkert van Heusden


--
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

Re: [Linux-ham] netrom

[David Ranch]

Hello Folkert,




Ah I thought it was actually the network-devicename that you needed to
put in there!


Yeah... I agree this is NOT obvious nor intuitive



netrom  FH2LOR-2svnnah   235 netrom


/etc/ax25/nrports Looks ok.



axport0 5   192 100 0


/etc/ax25/nrbroadcast looks ok but maybe try renaming this to say 
"axport".  Maybe the trailing 0 is messing things up. Be sure to update 
the /etc/ax25/axports file with the same name too




axport0 FH2LOR-1115200  254 8   AX.25 over LoRa


Looks ok though what is the RF link speed you're using?  I've seen some 
funny buffering problems in the past so I actually use 9600 baud to the 
TNC for a 1200baud RF link




Unfortunately it still fails:

root@savannah:~# modprobe netrom
root@savannah:~# nrattach netrom
nrattach: cannot find free NET/ROM device


What do you have in /etc/ax25/nrbroadcast



Are you sure the netrom module is loaded? Check:

$ lsmod | grep netrom
netrom 47709  2
ax25   65384  16 netrom,mkiss


The way I load my system via my packetrig.sh startup script, I use:

$NRATTACH -i $AMPRIP -m 236 $VHFD710NRPORT


I would also recommend you to show each of the commands you're using to 
load up your stack:


   - Are you using the mkiss approach with PTYs or using kissattach 
directly?


   - Are you seeing any errors when you run each command?


See

http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh

for the script but it is a pretty complex script for new Linux users.

--David
KI6ZHD
--
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

Re: icmp

[David Ranch]

This is because you have your window setting per the /etc/ax25/axports 
file set to 1.   Change it to say 4 and things should work better.


Btw.. what speed are you running your LoRa network at?  A round trip 
time of 1.6 seconds is quite slow but maybe that's due to the 
serialization delays of running your network at say 300bps!


--David


On 04/01/2016 12:07 PM, folkert wrote:

An other strange thing: I can't have 2 packets in that 2 second
interval. E.g. a traceroute only works if I add -N 1 -w 2.

On Fri, Apr 01, 2016 at 08:42:26PM +0200, folkert wrote:

Hi,

This evening I succeeded in doing ICMP over AX.25 over LoRa(!)!

root@savannah:~/data/mkiss_moteino# ping -i 5 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=4 ttl=64 time=4524 ms
64 bytes from 192.168.5.1: icmp_seq=7 ttl=64 time=1601 ms
64 bytes from 192.168.5.1: icmp_seq=8 ttl=64 time=1601 ms
64 bytes from 192.168.5.1: icmp_seq=9 ttl=64 time=1601 ms
^C
--- 192.168.5.1 ping statistics ---
9 packets transmitted, 4 received, 55% packet loss, time 40005ms
rtt min/avg/max/mdev = 1601.358/2332.248/4524.246/1265.550 ms


--
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

Re: [Linux-ham] netrom

[David Ranch]

Hello Folkert,


/etc/ax25/nrports contains:
nr0  FH2LOR-2svnnah   235 netrom


Don't use a name like "nr0" as this device name will be used and shown 
in the output of "ifconfig -a".  In the nrports file, I recommend to 
name it say "netrom" or "netrom0".  Anything will do really.





/etc/ax25/nrbroadcast contains:
ax0 5   192 100 1


This is your problem.. this needs to point to the AX25 interface name 
and NOT the device name.  This will be something like "vhfdrop" or 
whatever as defined in your /etc/ax25/axports file.  Btw, unless your 
machine is going to be a high level netrom node, I don't recommend you 
send out Netrom beacons to have stations route traffic THROUGH you.  As 
such, change the last parameter (called verbose) to 0.




and /etc/ax25/axports contains:
ax0 FH2LOR-1115200  254 1   AX.25 over LoRa


Don't use a name like "ax0" as this device name will be used and shown 
in the output of "ifconfig -a".  In the axports file, I recommend to 
name it say "vhfdrop" or "d710".  Anything will do really.


--David
KI6ZHD
--
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

Re: kernel ax25: lost and out-of-order data

[David Ranch]

Hello Thomas,


1. New findings:
   if the kernel runs on a single CPU machine, everything is ok. I transferred 
the 2MB testfile three times and it has been always received ok.
   => I suppose it's an SMP issue.


Wow.. that's a key find!  Nice work!  Now that you narrowed this down to 
a threading issue with a easy way to reproduce it, I hope you'll get 
some traction here from the local kernel experts.  If you don't see much 
movement, I imagine taking this up to the main kernel list would be 
warranted.


--David
KI6ZHD

--
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