Re: ax25ipd.c routing

[Cathryn Mataga <cathryn@xxxxxxxxxxxxxxxx>]

> ax25ipd in it's current version does not learn routes.
> In fact, route_add() is only being called from the config file.
> .../ax25-apps/ax25ipd$ grep route_add *.c
> config.c:               route_add(tip, tcall, uport, flags);
> routing.c:void route_add(unsigned char *ip, unsigned char *call, int udpport,
> .../ax25-apps/ax25ipd$ 
>
> That's why your packet goes out via the default connection (route K2PAR
> 2.0.0.0 d).


Thank you.  This confirms my understanding of the current issue.


> Btw, the dyndns feature which Bernard Pidoux f6bvp reminded to a few weeks ago
> is still the my queue.
> I've -mostly theoretical- problems with it because it resolves on a
> periodical basis, which means that if the dns currently is broken,
> it even affects LAN connections served by ax25ipd by introducing periodical
> delays.
> Bernard changed route_add(), as also my test-version does, but in a slightly
> different way.
> The test-code also implements periodical dyndns resolving, but iirc, it does
> not work correctly (can't remember).

Hmm.

What about this for both my and Bernard's issue.

1.  If a callsign is received from the ip of a known route
but is not the callsign of a known route, or the callsign
of the local station, then add this callsign
and the route pointer to a binary tree.  If the callsign
was previously in the tree, then the new route replaces
the old one, if different.
2.  in call_to_ip, before it checks the default route,
it checks this binary tree for this callsign, and returns the
route it came from.  If the callsign is not found, the default
route is used.
3.  Callsigns never expire.  The tree just grows.
4.  SSID's are matched as unique callsigns.
5.  If the callsign is that of a ddns route,
Fork, check dns, and if the ip matches the dns,
update the route_table_entry->ip_addr
6.  If a process is already forked for updating the ip of
a particular route, do not fork another one.  Add
a variable to route_table_entry to verify this.

Does this make sense?  Or are there other issues I'm unaware
of?


> For informational purpose, I did a diff between the current cvs head
> and the test version. The test-version startet on an older ax25ipd
> version and only fixes but no cosmetic changes have been manually applied
> (also i.e. still not the unix98 pty support). Here it is:
>   http://db0fhn.efi.fh-nuernberg.de/~dl9sau/ax25ipd-current-to-test--2009-12-07.diff

Alright, thanks.  I'll take a look.
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html