pppd changes
Bjoern Labitzke
Hello...
Some time ago (May, 2nd according to the file checkin date)
src/usr.sbin/pppd/pppd/lcp.c got changed. Since then I have been unable to
connect to my provider correctly. The connection was established, sending
of data seemed to work, as the modem seemed to report answers (e.g. for
pings). The problem was, that no data came through the pppd back to th
system. So I didn't get ping-answers or anything else to see. I used an
old version of pppd to circumvent the problem. A few minutes ago I
stumbled across that problem again as I did another build. So I looked for
the problem and found the offending changes. Since May 2nd quite some time
has gone by and no other persons seem to experience that problem, so I
describe it here first, but will send-pr it, if needed.
I have to point out, that I didn't try to understand the problem really, I
just backed out the most probable part and I found it to work again. Here
is the diff:
--------- snip ---------
--- lcp.c.old Mon May 25 17:17:55 1998
+++ lcp.c Mon May 25 17:20:44 1998
@@ -273,7 +273,7 @@
*/
ppp_set_xaccm(unit, xmit_accm[unit]);
ppp_send_config(unit, PPP_MRU, 0xffffffff, 0, 0);
- ppp_recv_config(unit, PPP_MRU, 0xffffffff,
+ ppp_recv_config(unit, PPP_MRU, 0x00000000,
wo->neg_pcompression, wo->neg_accompression);
peer_mru[unit] = PPP_MRU;
lcp_allowoptions[unit].asyncmap = xmit_accm[unit][0];
@@ -1491,8 +1491,13 @@
ppp_send_config(f->unit, MIN(ao->mru, (ho->neg_mru? ho->mru: PPP_MRU)),
(ho->neg_asyncmap? ho->asyncmap: 0xffffffff),
ho->neg_pcompression, ho->neg_accompression);
+ /*
+ * If the asyncmap hasn't been negotiated, we really should
+ * set the receive asyncmap to ffffffff, but we set it to 0
+ * for backwards contemptibility.
+ */
ppp_recv_config(f->unit, (go->neg_mru? MAX(wo->mru, go->mru): PPP_MRU),
- (go->neg_asyncmap? go->asyncmap: 0xffffffff),
+ (go->neg_asyncmap? go->asyncmap: 0x00000000),
go->neg_pcompression, go->neg_accompression);
if (ho->neg_mru)
@@ -1521,7 +1526,7 @@
ppp_send_config(f->unit, PPP_MRU, 0xffffffff, 0, 0);
ppp_recv_config(f->unit, PPP_MRU,
- (go->neg_asyncmap? go->asyncmap: 0xffffffff),
+ (go->neg_asyncmap? go->asyncmap: 0x00000000),
go->neg_pcompression, go->neg_accompression);
peer_mru[f->unit] = PPP_MRU;
}
-------- snip -----------
Thanks in advance...
--
Bjoern Labitzke | E-Mail: her...@cs.tu-berlin.de
PGP-Key available | Use PGP! Or don't you use envelopes for your letters?
John Darrow
In article <Pine.NEB.3.96.980525172244.521B-100000@localhost>,
Bjoern Labitzke <her...@labitzke.isdn.cs.tu-berlin.de> wrote:
>Hello...
>Some time ago (May, 2nd according to the file checkin date)
>src/usr.sbin/pppd/pppd/lcp.c got changed. Since then I have been unable to
>connect to my provider correctly. The connection was established, sending
>of data seemed to work, as the modem seemed to report answers (e.g. for
>pings). The problem was, that no data came through the pppd back to th
>system. So I didn't get ping-answers or anything else to see. I used an
>old version of pppd to circumvent the problem. A few minutes ago I
>stumbled across that problem again as I did another build. So I looked for
>the problem and found the offending changes. Since May 2nd quite some time
>has gone by and no other persons seem to experience that problem, so I
>describe it here first, but will send-pr it, if needed.
Actually, I've had a similar problem recently. In my case it was pppd
running on the receiving end (I dial into my office NetBSD machine), but
the symptoms were the same - the modem connects fine, pppd runs, but I'm
unable to make any useful connections through the link. I ended up
using the 1.3 pppd to bypass the problem, as I didn't have time to try
to track down exactly which changes in pppd caused the trouble. So go
ahead and send-pr it, it's not just your setup.
>I have to point out, that I didn't try to understand the problem really, I
>just backed out the most probable part and I found it to work again. Here
>is the diff:
[ diff snipped ]
Unfortunately, I'm leaving this afternoon for the Black Hills, so I won't
have a chance to test out your diff.
>Thanks in advance...
>--
>Bjoern Labitzke | E-Mail: her...@cs.tu-berlin.de
>PGP-Key available | Use PGP! Or don't you use envelopes for your letters?
--
John Darrow (ISCA: Jdarrow) (ICQ: 1725164) <*>
Lab Associate for Academic Computing, Science Division
Wheaton College (IL)
John.P...@wheaton.edu
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M>AT d+ s:- a22 C++(++++) UBUH++++$/AS+++/L+ P+>+++ L- E--- W++
N+++(*) o K++ w(+)(---) O? M(+)(--) V-- PS@ PE(+) Y+ PGP>++ t* 5+++
X+ R tv+ b+>+++ DI++++ D+ G+ e++(*) h--(*) r y-
------END GEEK CODE BLOCK------
Frederick Bruckman
On Wed, 27 May 1998, der Mouse wrote:
> >> In a side note, if you don't already have it set, doing "asyncmap 0"
> >> should speed up your PPP connection (assuming your link can handle
> >> those characters). I'm not sure by how much, though.
>
> > On average, it would cut down the number of characters actually
> > transmitted by 32/(256+32)=1/9 for binary transfers, nothing at all
> > for text files (which have no control characters).
>
> You're making two assumptions that I think are invalid.
>
> (1) You're assuming a flat frequency distribution of octets during
> binary transfers - this is likely to be approximately true if the data
> are compressed, but lots of binary transfers aren't.
>
> (2) You're completely ignoring the non-payload portions of the packets.
> IP and TCP headers have distinctly non-flat statistics when looked at
> as octet streams.
Granted. I don't know for certain, but I suspect that headers have fewer
control characters, if any. What with all the variables, all you can say
with certainty is that escaping no control characters will save you _less_
_than_ a calculated value, on average. With plaintext files, much less.
In practice, using ppp vs. zmodem over the same phone line never impacts
you by more than about 5%. Wether or not you save 10% or so on that 5%
only changes the final figure by %0.5, in the extreme case, so it's
probably safe to ignore that for now.
Upon reflection, I've made a mistake in my calculation. Consider a section
of a gzipped file well within the MTU--say, exactly 256+32=288 bytes long.
The payload with all characters escaped is only 256 bytes, on average.
With none, it's 288. The throughput gained by "asyncmap 0" is then "up to"
(288-256)/256 = 12.5%, not 11%, for a typical gzipped file.
Of course, a file that's all control characters would go to "up to" 100%.
Exec files, for example, often have a lot of nulls. I think this would be
quite rare, however, that you would be transfering any large file that
contained more than the expected proportion of control characters (12.5%).
I propose it's safe to say, that you gain, on average, nearly 12.5% for
compressed files, but practically nothing for plaintext.