All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cathryn Mataga <cathryn@junglevision.com>
To: Thomas Osterried <thomas@x-berg.in-berlin.de>
Cc: linux-hams@vger.kernel.org
Subject: Re: ax25ipd.c routing
Date: Mon, 07 Dec 2009 12:02:18 -0800	[thread overview]
Message-ID: <4B1D5F4A.7050002@junglevision.com> (raw)
In-Reply-To: <20091207162523.GC6537@x-berg.in-berlin.de>


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

  reply	other threads:[~2009-12-07 20:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <S1752195AbZK3HxQ/20091130075316Z+372@vger.kernel.org>
2009-11-30 20:38 ` nr0 doesn't show up (netrom) Cathryn Mataga
2009-11-30 21:13   ` Cathryn Mataga
2009-11-30 21:48     ` Cathryn Mataga
2009-12-01  6:05       ` Cathryn Mataga
2009-12-07 10:30         ` ax25ipd.c routing Cathryn Mataga
2009-12-07 16:25           ` Thomas Osterried
2009-12-07 20:02             ` Cathryn Mataga [this message]
2009-12-07 20:26               ` Thomas Osterried
2009-12-07 23:30                 ` Ray Wells
     [not found]                 ` <4B1D84C4.8000206@exemail.com.au>
     [not found]                   ` <20091207235111.GS19524@x-berg.in-berlin.de>
2009-12-08  1:45                     ` Cathryn Mataga
2009-12-08  5:11                     ` Cathryn Mataga
2009-12-08 22:15                     ` Cathryn Mataga
2009-12-15 23:14                       ` [PATCH] ax25ipd Cathryn Mataga
2009-12-25 11:35                         ` [PATCH] call.c Cathryn Mataga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B1D5F4A.7050002@junglevision.com \
    --to=cathryn@junglevision.com \
    --cc=linux-hams@vger.kernel.org \
    --cc=thomas@x-berg.in-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.