Xref: utzoo comp.dcom.modems:7767 comp.protocols.tcp-ip:14235 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.dcom.modems,comp.protocols.tcp-ip Subject: Re: PPP spoofing Message-ID: Date: 27 Dec 90 20:25:56 GMT References: <6547.277047AD@zswamp.fidonet.org> <1211@shakti.ncst.ernet.in> Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Followup-To: comp.dcom.modems Organization: Morning Star Technologies Lines: 52 In-Reply-To: shri@ncst.ernet.in's message of 27 Dec 90 05:37:26 GMT In article <1211@shakti.ncst.ernet.in> shri@ncst.ernet.in (H.Shrikumar) writes: However, some spoofing is still possible... by spoofing these packets, the two modems can tune their PEP packets to the IP packet size, the TCP window to the PEP window, which inturn will depend on line conditions and retransmission rates, and this can be dynamic. It might be useful to allocate a few DAMQAM carriers or the HST "reverse channel" for use by ACKs and the like, or to fit the MTU to the characteristics of the line (or vice versa); but I wouldn't call it spoofing, only accomodation and tuning. The modem wouldn't know anything about TCP, only that it's allocating bandwidth to packets of certain sizes and characteristics. Of course, this will make the line look error free to TCP, but my uneducated guess is that would not affect TCP too much. If it would, then some errors need to be spoofed as well to keep the algorithms in TCP happy. While TCP can handle line problems admirably, there's certainly no need to introduce them except perhaps for performance tuning. No need to spoof a flat tire by shooting it, just to keep me on my toes while I'm driving :-) The modem can also spoof VJ Header Compression, so plain vanilla slip can give good performance over the line. Hmmm... I'll have to think about that one a while longer before I'm convinced. Something doesn't feel right. Thus, while the modem *should* *not* ACK any TCP packets, it can do other things to increase thruput. Right, but that's not spoofing in the same sense that Telebit modems use the term in their handling of other protocols. It's just tuning. How much of this does the Netblazer do ? None, except VJ header compression (computed on the PC, not in the modem) across serial links it manages. It's a conventional enough IP router, with no intermediate-system protocol spoofing at all. ... the modem can also generate IP packets ... tell the computer about the health of the modem, and the local host can reply back and perhaps change modem settings etc... Link quality monitoring is among the purposes of the proposed PPP MIB for SNMP. Rather than have the modem generate IP packets, I suppose the contents of the Trailblazer's S7[02] (for PEP) or S78 (for V.32) or various other status registers could be acquired via the secondary DTE channel, and digested for broadcast as a pppLinkQualityEntry. But that secondary DTE was turned off in the standalone T2500 v7.00 ROMs, so slightly more cleverness would be required.