From: Kelvin Lawson <klawson@ad-holdings.co.uk>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] Re: Problems with ppp and Windows
Date: Wed, 16 Jun 2004 09:55:00 -0000 [thread overview]
Message-ID: <cap5f8$b59$1@sea.gmane.org> (raw)
In-Reply-To: <1087335408.28465.10.camel@famine>
Hi Ãyvind,
>>I've just had what appears to be the same problem as this. accept()
>>wasn't returning until the client killed the telnet process.
>>However in my case it was the same with Windows or Linux clients.
>
> When you say "client", are you referring to the machine on which the
> telnet session is launched?
>
> I find that the problem is with a Windows PPP *server*.
>
> It doesn't matter whether or not I start the telnet session from Windows
> or Linux.
By client I mean the machine from which the Telnet session is launched.
I get the same problem using a Windows or Linux Telnet client (or FTP or
anything that contacts an eCos server sitting in accept()). I also had
the same problem whether the PPP session itself was between eCos and
Win2k or between eCos and Linux. I can't imagine it makes any difference
whether eCos "dials up" the other end, or visa versa.
I'm surprised that this is only a problem connecting with Windows via
PPP. Was there anything different about your setup when you connected to
Linux ? Maybe on your Windows configuration the eCos target had an
Ethernet interface up as well ? (that will use up a few network
buffers). Or is your Linux PPPD perhaps running with the "novj" option ?
>>I'm not sure if this will be your problem, but it's worth a go. Try
>>adding some more memory to CYGPKG_NET_MEM_USAGE. The VJC structure needs
>>a little over 4KB on my target. You can confirm whether this is your
>>problem by checking the result of the MALLOC in pppalloc().
>
> I've been toying with PPP on an EB40a card board, which only has
> 256kbytes of memory.
>
> I've set CYGPKG_NET_MEM_USAGE = ~90k.
If you need to save some RAM, perhaps an alternative would be to disable
VJ compression. On a brief look in ipcp.c it looks like it's possible to
refuse by setting neg_vj = 0. Presumably there will be a few other
tweaks around the PPP code to handle this properly.
It would be nice to handle the failed slcompress MALLOC by refusing to
negotiate VJ compression. Either that or a big printf/assert on the
failed MALLOC would have saved me a few hours debugging.
Cheers,
Kelvin.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2004-06-16 9:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1087322512.28254.ezmlm@ecos.sourceware.org>
2004-06-15 21:36 ` [ECOS] " Øyvind Harboe
2004-06-16 9:55 ` Kelvin Lawson [this message]
2004-06-16 12:24 ` Øyvind Harboe
2004-06-17 9:08 ` [ECOS] " Kelvin Lawson
2004-06-17 11:05 ` Øyvind Harboe
2004-06-17 14:04 ` Kelvin Lawson
2004-04-22 15:14 [ECOS] " Øyvind Harboe
2004-06-15 10:30 ` [ECOS] " Kelvin Lawson
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='cap5f8$b59$1@sea.gmane.org' \
--to=klawson@ad-holdings.co.uk \
--cc=ecos-discuss@sources.redhat.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).