From: Ben Gelb <ben@gelbnet.com>
To: tpm@prkele.tky.hut.fi
Cc: linux-hams@vger.kernel.org
Subject: Re: ax25d and STDIN
Date: 27 Sep 2002 07:34:11 -0400 [thread overview]
Message-ID: <1033126451.1593.6.camel@ben> (raw)
In-Reply-To: <Pine.HPX.4.10.10209271038280.10119-100000@saturn.trs.ntc.nokia.com>
When I say 'hangs up' I mean that the user is disconnected from the ax25
link. I should have been more specific. For some reason, the link dies.
I was using fgets to read data. I tried using fread with length of 1024,
2048, and 10000. It was no different.
I doubt the problem is in my program. It basically asks the user for a
line of input, which it them spits back out again. It is simply a test
program. It works fine on the console (yes, I remembered to change the
return character to '\r' when I run it with ax25d).
I am starting to sense there may not be an easy solution to this
problem.
Thanks for answering so quickly!
73 Ben
On Fri, 2002-09-27 at 03:52, Tomi Manninen OH2BNS wrote:
> On 27 Sep 2002, Ben Gelb wrote:
>
> > To output data I am using fopen("php://stdout", "w"); and to read data I
> > am using fopen("php://stdin", "r"); The writing data part works fine,
> > but whenever I attempt to read in data from stdin, ax25d hangs up.
>
> What do you mean by ax25d hanging up?
>
> After spawning a program ax25d doesn't actively participate in the
> communication between the program and the connectee. To spawn a program it
> simply does a fork() followed by an exec(). The programs stdin/out/err are
> redirected to point at the incoming connection socket (dup2()) before the
> exec call.
>
> What you may be seeing is the side effect of AX.25 sockets being
> SOCK_SEQPACKET sockets. This means you always have to read a full packet
> when reading. If you read less than a full packet worth of data, the rest
> of the packet is thrown away. In practise you have no way of knowing how
> big packet there might be waiting in the kernel buffers so you will have
> to do a read() with a buffer "big enough"...
>
> The standard IO libraries do various amounts of buffering if you use stdio
> functions to read so that might explain why something works and something
> else does not.
>
> Then again you might be having some completely another problem with your
> program... :)
>
> --
> Tomi Manninen Internet: oh2bns@sral.fi
> OH2BNS AX.25: oh2bns@oh2rbi.fin.eu
> KP20ME04 Amprnet: oh2bns@oh2rbi.ampr.org
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2002-09-27 11:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-27 5:08 ax25d and STDIN Ben Gelb
2002-09-27 7:52 ` Tomi Manninen OH2BNS
2002-09-27 11:34 ` Ben Gelb [this message]
2002-09-27 23:09 ` Tomi Manninen
2002-09-28 5:19 ` Ben Gelb
2002-09-29 18:26 ` Tomi Manninen
2002-09-29 22:14 ` Ben Gelb
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=1033126451.1593.6.camel@ben \
--to=ben@gelbnet.com \
--cc=linux-hams@vger.kernel.org \
--cc=tpm@prkele.tky.hut.fi \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox