Netrom on kernel version 3.9.6-200

Netrom on kernel version 3.9.6-200

[Cathryn Mataga]

Hmm,  is netrom known to work?  I'm on 3.9.6-200, and I'm getting weird 
results with netrom.

nrattach -i 192.168.0.10 netrom just keeps just keeps responding to 
'NET/ROM port bound to device nr0' and then
if I call again
nrattach -i 192.168.0.11 netrom2

this again binds to device nr0

Then netromd returns 'no NET/ROM ports defined'

I'm running fedora 18.

So far, the rest of ax25 on fedora 18 seems okay.

Re: Netrom on kernel version 3.9.6-200

[Cathryn Mataga]

On 7/5/2013 9:19 PM, Cathryn Mataga wrote:
> Hmm, is netrom known to work?  I'm on 3.9.6-200, and I'm getting weird 
> results with netrom.
>

  Jul  6 00:37:31 hamradio kernel: [   50.626653] NET: Registered 
protocol family 6
Jul  6 00:37:31 hamradio NetworkManager[599]: <warn> 
/sys/devices/virtual/net/nr0: couldn't determine device driver; ignoring...
Jul  6 00:37:31 hamradio NetworkManager[599]: <warn> 
/sys/devices/virtual/net/nr1: couldn't determine device driver; ignoring...
Jul  6 00:37:31 hamradio NetworkManager[599]: <warn> 
/sys/devices/virtual/net/nr3: couldn't determine device driver; ignoring...
Jul  6 00:37:31 hamradio rc.local[987]: Logging in as gateways ... 
NET/ROM port netrom bound to device nr0
Jul  6 00:37:31 hamradio NetworkManager[599]: <warn> 
/sys/devices/virtual/net/nr2: couldn't determine device driver; ignoring...
Jul  6 00:37:31 hamradio rc.local[987]: NET/ROM port netrom2 bound to 
device nr0
Jul  6 00:37:31 hamradio rc.local[987]: netromd: no NET/ROM ports defined

Re: Netrom on kernel version 3.9.6-200

[Cathryn Mataga]

On 7/5/2013 9:43 PM, Cathryn Mataga wrote:
> On 7/5/2013 9:19 PM, Cathryn Mataga wrote:
>> Hmm, is netrom known to work?  I'm on 3.9.6-200, and I'm getting 
>> weird results with netrom.
>>

Wait, wait, this is definitely a Fedora issue and not a kernel issue.  
Because I copied in nrattach that I compiled myself and it started 
correctly.   (I don't think it's a 'old versions of libax25 lying around 
issue'  but I haven't completely ruled that out yet.)

>
>  Jul  6 00:37:31 hamradio kernel: [   50.626653] NET: Registered 
> protocol family 6
> Jul  6 00:37:31 hamradio NetworkManager[599]: <warn> 
> /sys/devices/virtual/net/nr0: couldn't determine device driver; 
> ignoring...
> Jul  6 00:37:31 hamradio NetworkManager[599]: <warn> 
> /sys/devices/virtual/net/nr1: couldn't determine device driver; 
> ignoring...
> Jul  6 00:37:31 hamradio NetworkManager[599]: <warn> 
> /sys/devices/virtual/net/nr3: couldn't determine device driver; 
> ignoring...
> Jul  6 00:37:31 hamradio rc.local[987]: Logging in as gateways ... 
> NET/ROM port netrom bound to device nr0
> Jul  6 00:37:31 hamradio NetworkManager[599]: <warn> 
> /sys/devices/virtual/net/nr2: couldn't determine device driver; 
> ignoring...
> Jul  6 00:37:31 hamradio rc.local[987]: NET/ROM port netrom2 bound to 
> device nr0
> Jul  6 00:37:31 hamradio rc.local[987]: netromd: no NET/ROM ports defined
>
> -- 
> 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: Netrom on kernel version 3.9.6-200

[Cathryn Mataga]

On 7/5/2013 10:33 PM, Cathryn Mataga wrote:
> On 7/5/2013 9:43 PM, Cathryn Mataga wrote:
>> On 7/5/2013 9:19 PM, Cathryn Mataga wrote:
>>> Hmm, is netrom known to work?  I'm on 3.9.6-200, and I'm getting 
>>> weird results with netrom.
>>>
>
> Wait, wait, this is definitely a Fedora issue and not a kernel issue.  
> Because I copied in nrattach that I compiled myself and it started 
> correctly.   (I don't think it's a 'old versions of libax25 lying 
> around issue'  but I haven't completely ruled that out yet.)

Wait a minute.  Someone has been mucking about with nrattach.c . They 
removed the the code that actually connects the netrom port.     Bahh..

#ifdef  notdef
         if (!startiface(dev, hp))
                 return 1;
#endif

Re: Netrom on kernel version 3.9.6-200

[David Ranch]

Hello Cathryn,

Which AX.25 libs/apps/tools are you using?  If you're using the 
"official AX.25" ones, you're going to find this and other bugs.  I 
recommend you use VE7FET / F6BVP's version at 
http://code.google.com/p/linuxax25/ as it has all of the required fixes 
that I've come across.   You can find .spec files for this code here: 
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ 
(don't use the ones that have "f6bvp" in the name as they reflect an 
older version of the libs).

--David
KI6ZHD

Re: Netrom on kernel version 3.9.6-200

[Cathryn Mataga]

On 7/6/2013 10:24 AM, David Ranch wrote:
>
> Hello Cathryn,
>
> Which AX.25 libs/apps/tools are you using?  If you're using the 
> "official AX.25" ones, you're going to find this and other bugs. I 
> recommend you use VE7FET / F6BVP's version at 
> http://code.google.com/p/linuxax25/ as it has all of the required 
> fixes that I've come across.   You can find .spec files for this code 
> here: 
> http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ 
> (don't use the ones that have "f6bvp" in the name as they reflect an 
> older version of the libs).

I was using the libraries that are the default in Fedora.  I thought 
maybe I could just install Fedora 18 and be good, but it looks like 
there are a few kinks in the code that comes with this distribution, 
including an odd change that's not from ftp.linux-ax25.org.

Anyway, now that I'm mucking with this stuff, I can give this version a 
shot too.  See how it goes.

Re: Netrom on kernel version 3.9.6-200

[Thomas Osterried]

the bug you mentioned was fixed in 2009-11-02
  http://www.linux-ax25.org/cvsweb/ax25-tools/netrom/nrattach.c

Needless to say, that we recommend to use the official tree and deeply
appreciate, that we get bug reports and patches.

I get not tired to mention, that it's not wise to have thousands of
copies of code, with incompatibilities or that have fixed one bug but
introduced others. Our ham community is not that large (it even becomes
smaller) that we need so many different sub probjects (for the same thing).

Apart from this:
if you're in a netrom (I am not): I might need help.
A few weeks ago we got a bug report for netromd. nodes are learned,
even if they're under the configured minimum threshold.
The netrom code is very old and didn't change. Perhaps it's an issue with
newer kernels. Or it never had worked as expected.
A test setup is quite time consuming (3 test-computers/VMs) and I did not have
the time to set them up.


The OM reported:

	# /etc/ax25/nrbroadcast
	#
	# The format of this file is:
	#
	# ax25_name min_obs def_qual worst_qual verbose
	#
	1	5	120	120	0

	--

	So I would assume that any new neighbor gets a quality of 120 and minimum quality to show up in my table is also 120. I would expect to have nothing but direct neighbors in my routing table.

	However I have this:
	
	# cat /proc/net/nr_nodes 
	callsign  mnemonic w n qual obs neigh qual obs neigh qual obs neigh
	ND6C-4    LPRC3    1 1   56   6 00001
	KF6FPU-5  LIVER    1 1   56   6 00001
	WA6TOW-1  PAC      1 1   56   6 00001
	KI6UDZ-7  FCITY    1 1   56   6 00001
	W6TUK-7   FOSN3    1 1  120   6 00001

	--

	Why do I have all of those < 120 routes showing up as nodes? I am missing something? I just upgraded ax25-tools to the latest and greatest and this is still happening.


vy 73,
	- Thomas  dl9sau

On 2013-07-06 10:24:06 -0700, David Ranch <linux-hams@trinnet.net>
wrote in <51D852B6.3060401@trinnet.net>:
> 
> Hello Cathryn,
> 
> Which AX.25 libs/apps/tools are you using?  If you're using the
> "official AX.25" ones, you're going to find this and other bugs.  I
> recommend you use VE7FET / F6BVP's version at
> http://code.google.com/p/linuxax25/ as it has all of the required
> fixes that I've come across.   You can find .spec files for this
> code here:
> http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/
> (don't use the ones that have "f6bvp" in the name as they reflect an
> older version of the libs).
> 
> --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

Re: Netrom on kernel version 3.9.6-200

[Cathryn Mataga]

On 7/6/2013 1:28 PM, Thomas Osterried wrote:
> the bug you mentioned was fixed in 2009-11-02
>    http://www.linux-ax25.org/cvsweb/ax25-tools/netrom/nrattach.c
>
> Needless to say, that we recommend to use the official tree and deeply
> appreciate, that we get bug reports and patches.

Okay, I filed a bug with Fedora to see if they can update what they ship.

> if you're in a netrom (I am not): I might need help.
> A few weeks ago we got a bug report for netromd. nodes are learned,
> even if they're under the configured minimum threshold.
> The netrom code is very old and didn't change. Perhaps it's an issue with
> newer kernels. Or it never had worked as expected.
> A test setup is quite time consuming (3 test-computers/VMs) and I did not have
> the time to set them up.

Well, I do have a bit list of nodes on my system right now.  It looks 
like what he says happens does happen.  I have worst_qual set to 100 and 
I do see a handful of nodes with quality just below 100, some as low as 
94, but none too far below 100.   I'll uninstall the Fedora libax25 and 
put in the latest, see if it's any different.




> The OM reported:
>
> 	# /etc/ax25/nrbroadcast
> 	#
> 	# The format of this file is:
> 	#
> 	# ax25_name min_obs def_qual worst_qual verbose
> 	#
> 	1	5	120	120	0
>
> 	--
>
> 	So I would assume that any new neighbor gets a quality of 120 and minimum quality to show up in my table is also 120. I would expect to have nothing but direct neighbors in my routing table.
>
> 	However I have this:
> 	
> 	# cat /proc/net/nr_nodes
> 	callsign  mnemonic w n qual obs neigh qual obs neigh qual obs neigh
> 	ND6C-4    LPRC3    1 1   56   6 00001
> 	KF6FPU-5  LIVER    1 1   56   6 00001
> 	WA6TOW-1  PAC      1 1   56   6 00001
> 	KI6UDZ-7  FCITY    1 1   56   6 00001
> 	W6TUK-7   FOSN3    1 1  120   6 00001
>
> 	--
>
> 	Why do I have all of those < 120 routes showing up as nodes? I am missing something? I just upgraded ax25-tools to the latest and greatest and this is still happening.
>
>
> vy 73,
> 	- Thomas  dl9sau
>
> On 2013-07-06 10:24:06 -0700, David Ranch <linux-hams@trinnet.net>
> wrote in <51D852B6.3060401@trinnet.net>:
>> Hello Cathryn,
>>
>> Which AX.25 libs/apps/tools are you using?  If you're using the
>> "official AX.25" ones, you're going to find this and other bugs.  I
>> recommend you use VE7FET / F6BVP's version at
>> http://code.google.com/p/linuxax25/ as it has all of the required
>> fixes that I've come across.   You can find .spec files for this
>> code here:
>> http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/
>> (don't use the ones that have "f6bvp" in the name as they reflect an
>> older version of the libs).
>>
>> --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
> --
> 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

Netrom: Quality issue

[Cathryn Mataga]

This code is in both your 0.0.8 and 0.0.10

It compares the quality and then afterwards it decreases the value

         if (best_quality < port_list[index].worst_qual) {
                 if (debug && logging)
                         syslog(LOG_DEBUG, "netromr: add_node: quality 
less than worst_qual");
                 return FALSE;
         }

         nr_node->quality = ((quality * best_quality) + 128) / 256;


Err, I don't think it's really a bug.  He's probably got a node coming 
in at quality 120 and then it does (120 * 120 +128)/256 Maybe update the 
man page to explain what's going on.

               worstqual     this is the worst quality node received 
from a routing broadcast that will be added
                             to our routing table.

Re: Netrom: Quality issue

[David Ranch]

I agree with Cathryn that this is a "as designed" issue though I'd argue 
we should CHANGE it.  Specifically, the Linux netromd man page says 
"RECEIVED from a routing broadcast" where as

Kantronics KPC3+ - 
http://www.kantronics.com/documents/kpc-3plus_manual_RevD.pdf
"
Page 137
. . .
When K-Net hears neighbor node (A) transmit a node broadcast, it
computes the quality to distant nodes (B, C, D, etc.) contained in that 
broadcast
by using the quality that is assigned to neighbor node (A). If the 
***resultant
computation*** is less than MINQUAL, the distant nodes (B, C, D, etc.) 
are not
added to the nodes table (see QUALITY command).
--


I also looked around for finding the default for the X1J TNC but 
couldn't find a clear citable URL but I believe the default there is 140.

--David




> Err, I don't think it's really a bug.  He's probably got a node coming 
> in at quality 120 and then it does (120 * 120 +128)/256 Maybe update 
> the man page to explain what's going on.
>
>               worstqual     this is the worst quality node received 
> from a routing broadcast that will be added
>                             to our routing table.
>
> -- 
> 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: Netrom: Quality issue

[Cathryn Mataga]

On 7/7/2013 9:59 AM, David Ranch wrote:
>
> I agree with Cathryn that this is a "as designed" issue though I'd 
> argue we should CHANGE it.  Specifically, the Linux netromd man page 
> says "RECEIVED from a routing broadcast" where as
>

My concern about changing this is that for a configuration like the one 
here, basically nodes will only get added if they come in as quality 
255.  That is the (254*120 + 128)/256 = 119.

	# ax25_name min_obs def_qual worst_qual verbose
	#

	1	5	120	120	0


> Kantronics KPC3+ - 
> http://www.kantronics.com/documents/kpc-3plus_manual_RevD.pdf
> "
> Page 137
> . . .
> When K-Net hears neighbor node (A) transmit a node broadcast, it
> computes the quality to distant nodes (B, C, D, etc.) contained in 
> that broadcast
> by using the quality that is assigned to neighbor node (A). If the 
> ***resultant
> computation*** is less than MINQUAL, the distant nodes (B, C, D, etc.) 
> are not
> added to the nodes table (see QUALITY command).
> -- 
>
>
> I also looked around for finding the default for the X1J TNC but 
> couldn't find a clear citable URL but I believe the default there is 140.
>
> --David
>
>
>
>
>> Err, I don't think it's really a bug. He's probably got a node coming 
>> in at quality 120 and then it does (120 * 120 +128)/256 Maybe update 
>> the man page to explain what's going on.
>>
>>               worstqual     this is the worst quality node received 
>> from a routing broadcast that will be added
>>                             to our routing table.
>>
>> -- 
>> 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: Netrom: Quality issue

[David Ranch]

Maybe a way to fix this is with a new parameter, say:

# ax25_name min_obs def_qual worst_heard_qual verbose worst_calced_qual
1    		5    120    	120    		0	120

--David


On 07/07/2013 11:45 AM, Cathryn Mataga wrote:
> On 7/7/2013 9:59 AM, David Ranch wrote:
>>
>> I agree with Cathryn that this is a "as designed" issue though I'd
>> argue we should CHANGE it.  Specifically, the Linux netromd man page
>> says "RECEIVED from a routing broadcast" where as
>>
>
> My concern about changing this is that for a configuration like the one
> here, basically nodes will only get added if they come in as quality
> 255.  That is the (254*120 + 128)/256 = 119.
>
>      # ax25_name min_obs def_qual worst_qual verbose
>      #
>
>      1    5    120    120    0
>
>
>> Kantronics KPC3+ -
>> http://www.kantronics.com/documents/kpc-3plus_manual_RevD.pdf
>> "
>> Page 137
>> . . .
>> When K-Net hears neighbor node (A) transmit a node broadcast, it
>> computes the quality to distant nodes (B, C, D, etc.) contained in
>> that broadcast
>> by using the quality that is assigned to neighbor node (A). If the
>> ***resultant
>> computation*** is less than MINQUAL, the distant nodes (B, C, D, etc.)
>> are not
>> added to the nodes table (see QUALITY command).
>> --
>>
>>
>> I also looked around for finding the default for the X1J TNC but
>> couldn't find a clear citable URL but I believe the default there is 140.
>>
>> --David
>>
>>
>>
>>
>>> Err, I don't think it's really a bug. He's probably got a node coming
>>> in at quality 120 and then it does (120 * 120 +128)/256 Maybe update
>>> the man page to explain what's going on.
>>>
>>>               worstqual     this is the worst quality node received
>>> from a routing broadcast that will be added
>>>                             to our routing table.
>>>
>>> --
>>> 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: Netrom: Quality issue

[Cathryn Mataga]

On 7/7/2013 8:40 PM, David Ranch wrote:
>
> Maybe a way to fix this is with a new parameter, say:
>
> # ax25_name min_obs def_qual worst_heard_qual verbose worst_calced_qual
> 1            5    120        120            0    120
>
> --David

If we're up for new parameters.  I suggest a worst_quality_to_send. This 
is the issue as I see it.  We're getting big lists from the internet, 
and the internet partners can handle them, but if you have any RF links, 
they'll be bombarded by a giant list of nodes in the broadcast.  The 
user connects to a 1200 baud TNC, types "NODES" and the table is filled 
up with junk from far away.   He falls asleep before the list finishes 
printing.

We add a 'worst_quality_to_send' and then you can set a worst quality to 
send to each specific connection.  Set your RF links to 255 and your IP 
connections to 1.   That way the RF connections can get a tiny list of 
only the absolute most important stuff, but internet partners can get 
all the distant nodes.  This is a pretty easy change to make.  It's all 
in netromd and doesn't require any mucking with the kernel.

Re: Netrom: Quality issue

[Thomas Osterried]

Am 08.07.2013 um 05:49 schrieb Cathryn Mataga <cathryn@junglevision.com>:

> On 7/7/2013 8:40 PM, David Ranch wrote:
>> 
>> Maybe a way to fix this is with a new parameter, say:
>> 
>> # ax25_name min_obs def_qual worst_heard_qual verbose worst_calced_qual
>> 1            5    120        120            0    120
>> 
>> --David
> 
> If we're up for new parameters.  I suggest a worst_quality_to_send. This is the issue as I see it.  We're getting big lists from the internet, and the internet partners can handle them, but if you have any RF links, they'll be bombarded by a giant list of nodes in the broadcast.  The user connects to a 1200 baud TNC, types "NODES" and the table is filled up with junk from far away.   He falls asleep before the list finishes printing.
> 
> We add a 'worst_quality_to_send' and then you can set a worst quality to send to each specific connection.  Set your RF links to 255 and your IP connections to 1.   That way the RF connections can get a tiny list of only the absolute most important stuff, but internet partners can get all the distant nodes.  This is a pretty easy change to make.  It's all in netromd and doesn't require any mucking with the kernel.

Nice idea, this outgoing filter.

But I see problems with worst_qual filters being different for each interface. Even more, if we'll have two (in and outbound).

Example:


A <-> B <-> INET-Host <-> C-in-inet

                          ^ learned: INET-HOST, A, B
 ^    ^
learned:
only INET-Host


User on C-inet tries to connect A.
But A has not learned C-inet by B's broadcast and thus has no route to answer.

=> In the inet cloud there would be many nodes which are not reachable.
   Where's the benefit?


Even worse, if you like to make IP:
you cannot manually connect from node to node; you depend on a working bi-directional l3 route.

vy 73,
	- Thomas  dl9sau

Re: Netrom: Quality issue

[Cathryn Mataga]

On 7/8/2013 12:48 AM, Thomas Osterried wrote:
>
> Nice idea, this outgoing filter.
>
> But I see problems with worst_qual filters being different for each interface. Even more, if we'll have two (in and outbound).
>
> Example:
>
>
> A <-> B <-> INET-Host <-> C-in-inet
>
>                            ^ learned: INET-HOST, A, B
>   ^    ^
> learned:
> only INET-Host
>
>
> User on C-inet tries to connect A.
> But A has not learned C-inet by B's broadcast and thus has no route to answer.


Yeah, I see what you're saying.  Really we do have this problem anyway, 
though.  I suppose.  If a TNC sets its worst_quality to be high and 
someone from that node connects in, there's no way to reply.    When 
worst_quality on a TNC is set high, the internet machine sends a giant 
list of nodes over 1200 baud, and then the TNC would throw them all 
away.  If we could match these then the IP connected machine could avoid 
putting all this extra stuff on the 1200 baud RF channel.

Maybe could be fixed with some kind of scheme that could set quality 
based on traffic going through -- but the node broadcast would be too 
late for a connect, so at least the first connect wouldn't get through.


> => In the inet cloud there would be many nodes which are not reachable.
>     Where's the benefit?
>

Just that the massive node list on 1200 baud TNC is a poor user experience.


> Even worse, if you like to make IP:
> you cannot manually connect from node to node; you depend on a working bi-directional l3 route.
>

Re: Netrom: Quality issue

[Brian Rogers]

Greetings;

The definitive answer in how NetRom should behave is defined by it's
designer, Software 2000. The linux code has always violated it's specs.

********************** 73 de Brian N1URO **********************

Spam {n}: an entity using smtp via internet to force
          humans to revert back to paper, pencil, and postage 
          for mail communications.