SLIRP's statistics file claims that all IP packets transmitted from ijppp are 'unaligned'. win95 into slirp works just fine, so I suspect it's ijppp's fault. Fix: none known at present. Disabling vj didn't help any. How-To-Repeat: I don't know how much this helps, as I have not spent much time trying to track this down, but this is the only code that conceivably could increment the unaligned frame count on slirp. It is in ppp.c: if (proto != PROTO_VJCOMP && ((long)m->m_data & 3)) { ipstat.ips_unaligned++; memmove((u_char *)(m->m_data - ((long)m->m_data & 3)), m->m_data, m->m_len); m->m_data -= ((long)m->m_data) & 3; }
As nsayer@kfu.com wrote: > SLIRP's statistics file claims that all IP packets transmitted from > ijppp are 'unaligned'. win95 into slirp works just fine, so I suspect > it's ijppp's fault. > >Fix: > > none known at present. Disabling vj didn't help any. Have you tried disabling the predictor-1 compression? IIJPPP has a _very_ broken CCP implementation, in that it continues to use CCP with pred1 even if the CCP negotiation yielded no common compression protocol (but CCP itself has been negotiated successfully, thus has been kept `up'). I've worked around this problem in pppd by shutting down the CCP layer if no matching compression method has been negotiated; it serves no useful purpose then anyway. We sorely need an ``IIJPPP meister''. :-( -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Sure enough, disabling pred1 did it. Thanks! -- Nick Sayer <nsayer@quack.kfu.com> | N6QQQ @ N0ARY.#NORCAL.CA.USA.NOAM | "Like I said to my drug dealer, +1 408 249 9630, log in as 'guest' | I don't 'cut' my money." URL: http://www.kfu.com/~nsayer/ | -- Kip Adotta
State Changed From-To: open->closed This can be fixed by disabling pred1 compression.