[AX.25] Make ax2asc thread-proof

2005-09-06 Thread Ralf Baechle
Ax2asc was still using a static buffer for all invocations which isn't
exactly SMP-safe.  Change ax2asc to take an additional result buffer as
the argument.  Change all callers to provide such a buffer.

Signed-off-by: Ralf Baechle DL5RB [EMAIL PROTECTED]

 include/net/ax25.h |2 +-
 net/ax25/af_ax25.c |7 ---
 net/ax25/ax25_addr.c   |3 +--
 net/ax25/ax25_route.c  |7 +--
 net/ax25/ax25_uid.c|4 +++-
 net/netrom/af_netrom.c |7 ---
 net/netrom/nr_route.c  |8 +---
 net/rose/af_rose.c |6 --
 net/rose/rose_route.c  |   14 +-
 net/rose/rose_subr.c   |5 +++--
 10 files changed, 39 insertions(+), 24 deletions(-)

Index: linux-cvs/include/net/ax25.h
===
--- linux-cvs.orig/include/net/ax25.h
+++ linux-cvs/include/net/ax25.h
@@ -278,7 +278,7 @@ extern struct sock *ax25_make_new(struct
 
 /* ax25_addr.c */
 extern ax25_address null_ax25_address;
-extern char *ax2asc(ax25_address *);
+extern char *ax2asc(char *buf, ax25_address *);
 extern ax25_address *asc2ax(char *);
 extern int  ax25cmp(ax25_address *, ax25_address *);
 extern int  ax25digicmp(ax25_digi *, ax25_digi *);
Index: linux-cvs/net/ax25/af_ax25.c
===
--- linux-cvs.orig/net/ax25/af_ax25.c
+++ linux-cvs/net/ax25/af_ax25.c
@@ -1863,6 +1863,7 @@ static void ax25_info_stop(struct seq_fi
 static int ax25_info_show(struct seq_file *seq, void *v)
 {
ax25_cb *ax25 = v;
+   char buf[11];
int k;
 
 
@@ -1874,13 +1875,13 @@ static int ax25_info_show(struct seq_fil
seq_printf(seq, %8.8lx %s %s%s ,
   (long) ax25,
   ax25-ax25_dev == NULL? ??? : ax25-ax25_dev-dev-name,
-  ax2asc(ax25-source_addr),
+  ax2asc(buf, ax25-source_addr),
   ax25-iamdigi? *:);
-   seq_printf(seq, %s, ax2asc(ax25-dest_addr));
+   seq_printf(seq, %s, ax2asc(buf, ax25-dest_addr));
 
for (k=0; (ax25-digipeat != NULL)  (k  ax25-digipeat-ndigi); k++) 
{
seq_printf(seq, ,%s%s,
-  ax2asc(ax25-digipeat-calls[k]),
+  ax2asc(buf, ax25-digipeat-calls[k]),
   ax25-digipeat-repeated[k]? *:);
}
 
Index: linux-cvs/net/ax25/ax25_addr.c
===
--- linux-cvs.orig/net/ax25/ax25_addr.c
+++ linux-cvs/net/ax25/ax25_addr.c
@@ -36,9 +36,8 @@ ax25_address null_ax25_address = {{0x40,
 /*
  * ax25 - ascii conversion
  */
-char *ax2asc(ax25_address *a)
+char *ax2asc(char *buf, ax25_address *a)
 {
-   static char buf[11];
char c, *s;
int n;
 
Index: linux-cvs/net/ax25/ax25_route.c
===
--- linux-cvs.orig/net/ax25/ax25_route.c
+++ linux-cvs/net/ax25/ax25_route.c
@@ -284,6 +284,8 @@ static void ax25_rt_seq_stop(struct seq_
 
 static int ax25_rt_seq_show(struct seq_file *seq, void *v)
 {
+   char buf[11];
+
if (v == SEQ_START_TOKEN)
seq_puts(seq, callsign  dev  mode digipeaters\n);
else {
@@ -294,7 +296,7 @@ static int ax25_rt_seq_show(struct seq_f
if (ax25cmp(ax25_rt-callsign, null_ax25_address) == 0)
callsign = default;
else
-   callsign = ax2asc(ax25_rt-callsign);
+   callsign = ax2asc(buf, ax25_rt-callsign);
 
seq_printf(seq, %-9s %-4s,
callsign,
@@ -314,7 +316,8 @@ static int ax25_rt_seq_show(struct seq_f
 
if (ax25_rt-digipeat != NULL)
for (i = 0; i  ax25_rt-digipeat-ndigi; i++)
-   seq_printf(seq,  %s, 
ax2asc(ax25_rt-digipeat-calls[i]));
+   seq_printf(seq,  %s,
+ax2asc(buf, ax25_rt-digipeat-calls[i]));
 
seq_puts(seq, \n);
}
Index: linux-cvs/net/ax25/ax25_uid.c
===
--- linux-cvs.orig/net/ax25/ax25_uid.c
+++ linux-cvs/net/ax25/ax25_uid.c
@@ -168,12 +168,14 @@ static void ax25_uid_seq_stop(struct seq
 
 static int ax25_uid_seq_show(struct seq_file *seq, void *v)
 {
+   char buf[11];
+
if (v == SEQ_START_TOKEN)
seq_printf(seq, Policy: %d\n, ax25_uid_policy);
else {
struct ax25_uid_assoc *pt = v;
 
-   seq_printf(seq, %6d %s\n, pt-uid, ax2asc(pt-call));
+   seq_printf(seq, %6d %s\n, pt-uid, ax2asc(buf, pt-call));
}
return 0;
 }
Index: linux-cvs/net/netrom/af_netrom.c
===
--- linux-cvs.orig/net/netrom/af_netrom.c
+++ linux-cvs/net/netrom/af_netrom.c
@@ -1265,6 +1265,7 @@ static int nr_info_show(struct seq_file 

Re: ax25-howto

2005-09-06 Thread Ralf Baechle DL5RB
On Sun, Sep 04, 2005 at 08:15:22AM -0400, Harold Hartley wrote:

 I must agree as I have found it talks in some places about files that 
 are not relevent to most distro's now and in fact are very out of date.
 Now with the newer files such as the ax25-config, ax25-tools and 
 ax25-apps, most of the how-to don't apply to the newer files and mainly 
 applies the the old ax25-utils and such...
 
 I'm wondering if someone will evenually update the How-to in places that 
 does need some update to, but not all the How-to needs updating.

THe AX.25 and Ham Howtos are all horribly outdated - probably beyond
recovery.  I'm working on converting them into a wiki so everybody
can start contributing.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21
-
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


Re: [AX.25] Make ax2asc thread-proof

2005-09-06 Thread David S. Miller
From: Ralf Baechle [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 19:12:22 +0100

 Ax2asc was still using a static buffer for all invocations which isn't
 exactly SMP-safe.  Change ax2asc to take an additional result buffer as
 the argument.  Change all callers to provide such a buffer.
 
 Signed-off-by: Ralf Baechle DL5RB [EMAIL PROTECTED]

Applied, thanks a lot Ralf.
-
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


ax25ipd UDP mode documentation

2005-09-06 Thread Bob Morgan

Well, for several years, I have had a nagging problem getting the udp mode
of ax25ipd to work at all.  Yesterday I finally hacked my way through
it with use of strace and reference to various parts of the source,
and lots of trial and error.  It turns out to be a documentation problem,
I didn't have to change any code, just the .conf file.

Just now, Ralf posted a request for improvements to ax25-howto, and this
may fit in with that also.  Ralf, I can take the ax25ipd portion of ax25-howto
and edit it with this newer material if you like, but I guess I need to
know where the recent official copy of it lives.  (I might even redo
the ax25ipd manpage, but I would have to figure out how to do the
manpage editing.  I haven't done anything with manpages before except READ 
them.)

Continuing with the matter of running udp transport with ax25ipd:
For various reasons, here centered around a simplistic DSL masquerading
modem/router, I have a need to actually make the udp mode work.  The dsl box
allows me to masquerade a few tcp and/or udp ports through it to various
hosts on its lan, but it doesn't allow me to masquerade any other protocols,
such as axip # 93 for instance.  The only other option is to demasquerade
the whole thing and expose the lan to the internet, which I am not
in a position to do with this particular lan.  And I have a few other reasons
as well that amount to experimentation with other gadgets that I would like
to interconnect with ax25 and they also only have tcp and udp hooks, not ip.

So, with the existing documentation I have been able to find, namely
the ax25-howto, and the .conf file and some things that come with
the ax25ipd tarball, anytime I configured it for udp, absolutely
nothing happened.  It just swallowed up the packets and never threw
any udp packets out onto the lan.  What isn't mentioned in the docs is
that in addition to setting the udp option in the socket definition near
the top of the .conf file, one must ALSO specify a udp option on the
tail end of EACH routing line in the routing section near the end of
the .conf file.  It didn't tell me that, and the source didn't really
help much, until I did a lot of trial and error with strace
running, and I satisfied myself where routing was getting lost, and then
after more trial and error, I eventually found what the config parsing
wanted to see to set the flags that the routing processing wanted.

When I added a udp option to the end of all of the route definitions,
it started working.  It doesn't say this anyplace that I have found.

The code in the config parsing routines looks at first glance like some
flags (b and d) might not parse in combination with the udp option.
I didn't pursue or test that possibility any farther, although
I think it needs to be looked at.  That's a TODO or FIXME item.

It also happens to be possible to listen on one udp port, and send
udp packets to the far end under some other port number, although that
would be a weird asymetrical routing situation that not very many
situations would ever need.  It turns out that the default udp port number
of 10093 can be overridden by specifying some other port number just
after the udp option on the end of either the socket or the route definitions.

The socket definition sets the udp listen port, and also the source port
on outgoing packets, so the other end knows what the return address/port is.
The route definition sets the udp destination port for each route.
Leaving off the udp option on a route leaves the packets in no-mans-land
and they disappear entirely if udp socket has been defined.  I think
that is actually a bug, but anyway that is what it does.

Of course, by specifying other ports on both socket and routes, some
other udp port number can be used if necessary, in case some combination
of firewalls and routers only allow some specific ports through.
It is quite flexible it looks like, if one finds out how to set it up.

Previously I also had to use some different param definitions to implement
a higher speed modem on a tnc that I was feeding with one end of ax25ipd,
and I have also documented how to specify the various params in the
.conf file.  They follow straight from the kiss definition itself.
I also have encountered a situation a few times where the tnc gets
reset while ax25ipd is running unaffected, and at that time, the tnc
restarts with some default params of its own which may not be optimum,
particularly if some params are deliberately set up in the .conf file.
I then have to do things like stop and restart ax25ipd, or maybe
disconnect the serial port from the tnc and send it some params
from some other device, or maybe a kill -s SIGHUP pid to ax25ipd
would accomplish the same thing.  I think I vaguely recall that others
have also observed that behavior.  Maybe the workaround is to use
a cronjob to periodically send the SIGHUP, but the real fix is to code
up a periodic broadcast params patch in ax25ipd to refresh a tnc.
(Or has this been