| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
Glibc as old as 2.2 provides working headers under the right name and
if not libax25 would install headers under the right name so this has
become redundant and ugly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is recommended by autoreconf by the following warning:
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
For some reason I don't have the time to track down right now it results
in a configure script with a syntax error being generated.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keeping generated files in CVS doesn't only tend to produce large and
cluttered files it also may result in build problems due to timestamps
in the wrong order. So dump everything, update .cvsignore to ignore
these files and resolve all warnings generated by autoreconf.
From now on users of a CVS checkout should run the command
autoreconf --install --force
after having done a CVS checkout. For this to succeed automake, autoconf
and libtool will have to be installed.
|
| |
|
|
|
|
|
|
| |
Various socket syscalls receive a length argument that should be a
socklen_t rsp. a ptr to a socklen_t but instead int rsp. ptr to int were
being passed. While in theory this was a bug it's harmless as dangerously
large values would not be used but the issue manifested itself in a
significant number of compilation warnings.
|
| |
|
|
|
| |
Any modern C compiler will just ignore register so it's just cluttering
the screen.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We had a Makefile.in everywhere but not here.
|
| |
|
|
|
|
|
|
|
| |
wnoutrefresh() [ncurses functions], called from winclose() in menu.c.
Debunging with gdb showed that wtab->fline was a large negative number.
Now doing better checking that wtab->fline and wtab->lline is > 0.
Seems that this fix is sufficient. If it will come out that it is not,
we'll write a wtouchln() wrapper which checks if the arguments are
positive and reasonable small.
|
| |
|
|
| |
and warnings.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
from the ax25 connection using write(0). everything was fine
as long as call wrote to stdout.
If instead we use output redirection to a file or stdout
(> foo, | bar), then the messages like "Connected to.." appeared
at the end of the connection.
I guess it's a glibc issue that printf (whih is buffered) behaves
different when stdout is redirected.
Fixed using fflush() after each printf().
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Revised the getopt_long() part.
Assured strcpy cases.
Thanks to Christoph <dk2crn> for contribution.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
issue whenever a packet ended with "\r ".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. if a line was split over two ax25 packets, we read i.e.
1. "foobar told me" 2. " go7+. ". The second packet was
interpreted like starting with " go7+. ".
thus in a pure bbs listing it was misinterpreted as start
of a 7plus file.
Since the data was not like a 7plus header starts, the
7plus download parser caused a segfault (after copying
i.E. 1555 bytes to char s[20]. [seen in gdb ;-]
-> enforced a "linemode".
2. protocol and array size assurances in the #BIN and 7plus
part, as well as in dupdstatw().
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
currently we've seen other bugs in call which lead to malfunctions
and segfaults.
|
| | |
|
| |
|
|
| |
fixed dos to unix time conversion.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- fileupload (in raw and gui "slave" mode) goes only
step by step the 128 bytes further if user enters a character.
Thanks to Daniel DO8CD for the report.
- write() returns -1 at EAGAIN (packet links are usually slower
then linux file IO, and EAGAIN occurs because the txbuffer
in the kernel is full). This lead to a bad substraction in
sent bytes and thus to file corruption at the receiving site.
- added more help: now explaining all the ~-Escapes in raw mode
in the ~? command.
|
| | |
|
| |
|
|
|
|
|
| |
/bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -o ax25rtd ax25rtd.o cache_ctl.o cache_dump.o config.o listener.o -lax25
../libtool: line 810: X--tag=CC: command not found
../libtool: line 843: libtool: ignoring unknown tag : command not found
../libtool: line 810: X--mode=link: command not found
|
| |
|
|
| |
now we need to include limits.h
|
| |
|
|
| |
return value EOF was not honored.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- call was not usable as a pipe in scripts because it read 511
bytes, tried to write these 511 bytes (but 256 is max for ax25
I-frames), got -1 EMSGSIZE (Message too long) and terminated.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. if stdin closes (i.e. if call is right end of a pipe),
then call should close. this also fixes the case when
call reads from a unix fifo, and the other end of the
fifo terminates. This produced highest cpu-load,
with select(), read() = 0, select(), read() = 0, ..
2. if stdin is not a tty, i.e. call is called from ax25d,
then it's not a good idea to honor the ~ commands.
In that special case, you could imagine what ~! means,
while ax25d is running as uid 0...
3. while not operating on pty, the FILE buffers are not
flushed in all cases. Thus, the messages like "Connected .."
were be printed in the termination phase of the program..
|
| |
|
|
|
| |
if ttyqueue is full. The behaviour
to give up here was wrong.
|
| |
|
|
| |
pointless comments.
|
| | |
|
