Patch improving ROSE routing

Hi All,

As you know FPAC AX25 packet application is using Linux kernel ROSE routing skills in order to connect or send packets to remote stations knowing their ROSE address via a network of interconnected nodes.

Each FPAC node sets a ROSE routing table that Linux ROSE module is looking at each time a ROSE frame is relayed by the node or for connecting a node neighbor.

A previous patch improved the system time response by looking at already established routes each time the system was looking for a route to relay a frame. If a neighbor node routing the destination address was already connected, then the frame would be sent through him. If not, a connection request would be issued.

The present patch extends the same routing capability to a connect request asked by a user locally connected to an FPAC node. Without this patch, a connect request was not well handled unless it was directed to an immediate connected neighbor of the local node.

The present patch improves dramatically FPAC ROSE routing capability.

Here is an illustration.

This is F6BVP-10/11FPAC routing table :

DNIC Address Primary Route | 1st Alt Route | 2nd Alt Route |

7100,...... YN1BBS-9 Opened | TI2HAS-9 Opened | P43L-4 Opened |

7120,...... TI2HAS-9 Opened | YN1BBS-9 Opened | P43L-4 Opened |

5050,...... VK7HDM-5 Opened | VK2XB-2 Opened | VK2TV-2 Closed |

3630,...... P43L-4 Opened | YN1BBS-9 Opened | TI2HAS-9 Opened |

3620,...... P43L-4 Opened | YN1BBS-9 Opened | TI2HAS-9 Opened |

3100,...... K4GBB-9 Opened | KD4YAL-9 Closed | KP4DJT-9 Closed |

3020,...... K4GBB-9 Opened |

2080,...... F5KBW-9 Closed | F3KT-11 Opened | F4BWT-11 Closed |

2080,9..... F5KBW-9 Closed |

2080,8..... F8COJ-11 Closed | F5KBW-9 Closed |

2080,7..... F5KBW-9 Closed |

2080,1..... F6BVP-9 Closed | F6BVP-7 Closed |

2080,428... F4BWT-11 Closed |

2080,847... F6GGY-9 Closed | F4BWT-11 Closed |

2080,444... F3KT-11 Opened | F6GGY-9 Closed | F1MVP-5 Closed |

2080,8335.. F5KBW-9 Closed |

7120,282700 TI2HAS-9 Opened |

7100,505522 YN1BBS-9 Opened |

5050,626300 VK7HDM-5 Opened |

5050,656200 VK2TV-2 Closed |

5050,699300 VK2XB-2 Opened |

3630,297585 P43L-4 Opened |

3100,813626 KP4DJT-9 Closed |

3100,727489 KD4YAL-9 Closed |

3100,352726 K4GBB-9 Opened |

2080,886801 F1MVP-5 Closed |

2080,428501 F4BWT-11 Closed |

2080,847501 F6GGY-9 Closed |

2080,833501 F5KBW-9 Closed |

2080,444501 F3KT-11 Opened |

Linux is performing a table lookup from the bottom to the top. In case a user would ask for a connection to KP4DJT-8 we see that the direct route is closed.
Without the patch, the request would time out after a direct connection to KP4DJT-8 would have failed.
With the present patch, Linux kernel will first look in the table for a connected node routing starting at a 10 digits address 3100,813626, down to a less specific 4 digit address 3100 where it founds that route to K4GBB-9 is opened.
Then, the connect request to KP4DJT-8 is relayed through K4GBB that is the first ROSE node available.
If no route are already opened toward KP4DJT then a second table lookup is performed and only at this time a connect request is sent directly to KP4DJT.
Another example can illustrate the new behavior.
Suppose a user wants to connect F4BWT-10 from this node (F6BVP). Linux will step over the following closed routes : 2080,428501 and 2080, 428.
It will finally reach DNIC 2080 (France) and see that first node F5KBW-9 is not connected. However, second node, F3KT-11 routing all 2080 address is connected. Thus, the connect request to F4BWT-10 will be send through F3KT.

The present algorithm gives more chances a user to succeed in connecting a destination through ROSE network.

Before officially submitting this patch, I would appreciate any report from OMs having used it.

73 de Bernard, f6bvp

@@ -672,34 +672,41 @@
  *	Find a neighbour or a route given a ROSE address.
  */
 struct rose_neigh *rose_get_neigh(rose_address *addr, unsigned char *cause,
-	unsigned char *diagnostic, int new)
+	unsigned char *diagnostic, int route_frame)
 {
 	struct rose_neigh *res = NULL;
 	struct rose_node *node;
 	int failed = 0;
 	int i;
 
-	if (!new) spin_lock_bh(&rose_node_list_lock);
 	for (node = rose_node_list; node != NULL; node = node->next) {
 		if (rosecmpm(addr, &node->address, node->mask) == 0) {
 			for (i = 0; i < node->count; i++) {
-				if (new) {
-					if (node->neighbour[i]->restarted) {
-						res = node->neighbour[i];
-						goto out;
-					}
+				if (node->neighbour[i]->restarted) {
+					res = node->neighbour[i];
+					goto out;
 				}
-				else {
+			}
+		}
+	}
+	if (!route_frame) { /* connect request */
+		spin_lock_bh(&rose_node_list_lock);
+		for (node = rose_node_list; node != NULL; node = node->next) {
+			if (rosecmpm(addr, &node->address, node->mask) == 0) {
+				for (i = 0; i < node->count; i++) {
 					if (!rose_ftimer_running(node->neighbour[i])) {
 						res = node->neighbour[i];
+						failed = 0;
+						spin_unlock_bh(&rose_node_list_lock);
 						goto out;
-					} else
-						failed = 1;
+					}
+					failed = 1;
 				}
 			}
 		}
+		spin_unlock_bh(&rose_node_list_lock);
 	}
-
+	
 	if (failed) {
 		*cause      = ROSE_OUT_OF_ORDER;
 		*diagnostic = 0;

@@ -709,8 +716,6 @@
 	}
 
 out:
-	if (!new) spin_unlock_bh(&rose_node_list_lock);
-
 	return res;
 }
 

Bernard
Either the AxUDP ports are working better or the ROSE patch has made a *HUGE* improvement. I installed the patch on approx half of our Servers.
In Every case connectivity has improved and connections go thru at warp speed.

<<Charley>>
k4gbb

Hi Charley,

I made a few connect request through the ROSE FPAC network you modified and agree that it works faster and much more efficiently.

The good and completely unexpected surprise is that F6BVP node is now connected directly to KP4DJT ! Although I have no explanation, I am very glad.

I encourage you to add, as I did in KP4DJT routing table, default generic routes with four digits DNICs in all your nodes routing tables.
These DNIC routes should be populated with three best nodes toward the final goal.

Considering the results I am encouraged to commit the patch right now for it to be included as soon as possible in next kernel release and appear in due time in Linux distros.

Thanks for your help.

73 de Bernard, f6bvp

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

I am presently hunting a bug in fpacwpd that makes this server crash regularly. I think I am not far from the goal as I found a SIGPIPE signal that is occuring when fpacwpd cannot reach a destination node. This signal was not handled by the server and this could explain why WP data base is not available from time to time inside fpacnode showing -1 instead of the number of nodes and fpacnode not being able to connect a remote node.
Continuous testing are being performed locally.
If the results are positive, I will soon release fpac327.14-pre30 that could become fpac327.14 after validation by you all.

On my list are a few other bugs in Linux rose module, ax25ipd, FPAC and BBS softwares. This number is decreasing regularly, with some valuable help from Cathryn.

I recently corrected a bug in "nestat", a usefull tool from net-tools. When I patched it to include ROSE handling, I made a small error that made it crash from time to time. You can download netstat from CVS and apply the new patch as explained here :

http://rose.fpac.free.fr/MINI-HOWTO/#s103

73 de Bernard, f6bvp

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html