| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
read() = 0, wht consumed 100% CPU power.
New options:
-W: waits after EOF on stdin. Useful for scripting, for waiting
for data coming via fd 3 (ax25 connection)
-T secs: idle timout after secs seconds.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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().
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
| |
- 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..
|
| | |
|
| |
|
|
| |
- usage: new function usage()
|
| |
|
|
| |
Makefile bug
|
| | |
|
| | |
|
| | |
|
| |
|
