pppd: unsupported protocols (only ping works)
Olaf Stetzer
I am trying hard to get a ppp-connection via
pppd/ttyi0/hisax on Linux 2.2.19 but something
goes wrong. I use kppp to start the connection
and now am able to ping to hosts outside
(always < 100 ms, no lost packets) but everything
else (http, ftp) does not work. The only thing
happens is that a series of messages appear in
/var/log/messages which look like this:
pppd: unsupported protocol 0x... received
When I click on details in the kppp-log-window
I see some incoming packets but none of them is a
vj-packet. I am using debian/testing, pppd-version
is 2.4.1. I already tried to use the following
options without success: noccp nobsdcomp noaccomp
Please help!
Greetings,
Olaf
--
Olaf Stetzer
Forschungszentrum Karlsruhe
Institut für Meterologie und Klimaforschung
Atmosphärische Aerosole (IMK III) - http://imk-aida.fzk.de
Tel.: +49(0)7247-82-3249 (FAX: -4332)
Rene Berber
> Hello all,
>
> I am trying hard to get a ppp-connection via
> pppd/ttyi0/hisax on Linux 2.2.19 but something
> goes wrong. I use kppp to start the connection
> and now am able to ping to hosts outside
> (always < 100 ms, no lost packets) but everything
> else (http, ftp) does not work.
Are you using numeric addresses for ping and names for ftp, http?
If so, then the problem is with resolving names, not ppp, and you should
revise your configuration either setting fixed DNS servers, or checking that
dynamic DNS servers are really being set (by pppd), or using your own DNS
(bind).
> The only thing
> happens is that a series of messages appear in
> /var/log/messages which look like this:
>
> pppd: unsupported protocol 0x... received
If you see only a few of those messages that happen when pppd is started,
then it's normal.
> When I click on details in the kppp-log-window
> I see some incoming packets but none of them is a
> vj-packet. I am using debian/testing, pppd-version
> is 2.4.1. I already tried to use the following
> options without success: noccp nobsdcomp noaccomp
That's unrelated to your problem. For VJ compression to be used you need
that the server supports it and that your side (pppd) asks for it in the
initial negotiation; it's used by default by pppd, so you don't need any
parameters.
The options you list are not for VJ header compression. Better read man
pppd.
Hope this helps.
--
René Berber
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|.|B|e|r|b|e|r|@|c|o|m|p|u|t|e|r|.|o|r|g|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Olaf Stetzer
>
> In <3BCBE3C6...@imk.fzk.de> Olaf Stetzer wrote:
> > Hello all,
> >
> > I am trying hard to get a ppp-connection via
> > pppd/ttyi0/hisax on Linux 2.2.19 but something
> > goes wrong. I use kppp to start the connection
> > and now am able to ping to hosts outside
> > (always < 100 ms, no lost packets) but everything
> > else (http, ftp) does not work.
>
> Are you using numeric addresses for ping and names for ftp, http?
>
No, I used even the same server in both cases: www.uni-mainz.de
Ping works fine but konqueror is waiting until timeout for a web page.
> > The only thing
> > happens is that a series of messages appear in
> > /var/log/messages which look like this:
> >
> > pppd: unsupported protocol 0x... received
>
> If you see only a few of those messages that happen when pppd is started,
> then it's normal.
>
They are changing but most protocol numbers are something like:
0x67 0x6f 0x13 ... but also others with 2-byte numbers 0xNNNN
> > When I click on details in the kppp-log-window
> > I see some incoming packets but none of them is a
> > vj-packet. I am using debian/testing, pppd-version
> > is 2.4.1. I already tried to use the following
> > options without success: noccp nobsdcomp noaccomp
>
> That's unrelated to your problem. For VJ compression to be used you need
I only mentioned it because somewhere (maybe in the archives of this
newsgroup) I read that problems with unsupported protocols can be solved
by using this options.
> that the server supports it and that your side (pppd) asks for it in the
> initial negotiation; it's used by default by pppd, so you don't need any
> parameters.
>
The reason I mentioned vj is that the log window of kppp has sepeerate
fields
for received vj-packages so I thought they are important for some
reason...
(really don'T know much about that).
Olaf
--
Dr. Olaf Stetzer
James Carlson
> I am trying hard to get a ppp-connection via
> pppd/ttyi0/hisax on Linux 2.2.19 but something
> goes wrong. I use kppp to start the connection
> and now am able to ping to hosts outside
> (always < 100 ms, no lost packets) but everything
> else (http, ftp) does not work. The only thing
> happens is that a series of messages appear in
> /var/log/messages which look like this:
>
> pppd: unsupported protocol 0x... received
If it's a persistent problem, that generally occurs in only one case:
you're using CCP, and the implementation on one side or the other has
bugs. Use "noccp" to work around this.
If it just happens once or twice during connection establishment;
ignore it. It's normal PPP negotiation. Please post debug logs for a
more thorough analysis.
> When I click on details in the kppp-log-window
> I see some incoming packets but none of them is a
> vj-packet.
I wouldn't expect that to be the case. First of all, VJ compression
can't cause the error you see, because it works at a level above the
PPP protocol demultiplexing. Second, VJ compression affects only TCP
packets, not ping.
> I am using debian/testing, pppd-version
> is 2.4.1. I already tried to use the following
> options without success: noccp nobsdcomp noaccomp
That's very odd. Can you post debug logs?
--
James Carlson, Solaris Networking <james.d...@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Olaf Stetzer
>
> Olaf Stetzer <olaf.s...@imk.fzk.de> writes:
> > I am trying hard to get a ppp-connection via
> > pppd/ttyi0/hisax on Linux 2.2.19 but something
> > goes wrong. I use kppp to start the connection
> > and now am able to ping to hosts outside
> > (always < 100 ms, no lost packets) but everything
> > else (http, ftp) does not work. The only thing
> > happens is that a series of messages appear in
> > /var/log/messages which look like this:
> >
> > pppd: unsupported protocol 0x... received
>
> If it's a persistent problem, that generally occurs in only one case:
> you're using CCP, and the implementation on one side or the other has
> bugs. Use "noccp" to work around this.
>
> If it just happens once or twice during connection establishment;
> ignore it. It's normal PPP negotiation. Please post debug logs for a
> more thorough analysis.
I will send them tomorrow, the computer in question is at home!
>
> > I am using debian/testing, pppd-version
> > is 2.4.1. I already tried to use the following
> > options without success: noccp nobsdcomp noaccomp
>
> That's very odd. Can you post debug logs?
>
I seem to remember that there were less messages when I used
noccp but still, there was no traffic possible over ppp anyway!
More info tomorrow when I did some further examinations at home!
Olaf
--
Dr. Olaf Stetzer
Bill Unruh
]I am trying hard to get a ppp-connection via
]pppd/ttyi0/hisax on Linux 2.2.19 but something
]goes wrong. I use kppp to start the connection
]and now am able to ping to hosts outside
](always < 100 ms, no lost packets) but everything
]else (http, ftp) does not work. The only thing
]happens is that a series of messages appear in
]/var/log/messages which look like this:
Try using
novj
(also use noccp)
kppp is not very useful in debugging problems.
Clifford Kite
> James Carlson schrieb:
>>
>> Olaf Stetzer <olaf.s...@imk.fzk.de> writes:
>> > I am trying hard to get a ppp-connection via
>> > pppd/ttyi0/hisax on Linux 2.2.19 but something
>> > goes wrong. I use kppp to start the connection
I think this is an ISDN connection using a card (hisax). I'd suspect
the hisax driver, in view of all that has been said so far. Purely a
guess though.
-- Clifford Kite <Email: X@Y.Z with X=kite, Y=inetport, Z=com>
/* Recipe for a unified PPP debug log file: Add the line
" local2.*;*.=debug;*.=notice /var/log/ppp-debug.log "
(may need Tab separators) to the /etc/syslog.conf file, and then do
" kill -HUP `pidof syslogd` " to make syslogd reread it. */
Rene Berber
[snip]
> No, I used even the same server in both cases: www.uni-mainz.de
> Ping works fine but konqueror is waiting until timeout for a web page.
OK, let's forget about DNS problems.
> They are changing but most protocol numbers are something like:
> 0x67 0x6f 0x13 ... but also others with 2-byte numbers 0xNNNN
A look at the log file is necessary. More than a few of those messages
indicates that there is a problem with the pppd implementation either on the
server or the client.
> I only mentioned it because somewhere (maybe in the archives of this
> newsgroup) I read that problems with unsupported protocols can be solved
> by using this options.
Correct, some problems are caused by badly implemented compression, so you
have to disable it but right now we don't know if that is the cause of your
problem.
Other than looking at the log, and out of curiosity, why are you using a non
standard serial port? Is ttyi0/hisax an internal ISDN modem or high speed
port?
Regards.
Rene Berber
[snip]
> Other than looking at the log, and out of curiosity, why are you using a
non
> standard serial port? Is ttyi0/hisax an internal ISDN modem or high speed
> port?
OK I found that it's ISDN and you are using isdn4linux with the hisax driver.
From the isdn4linux FAQ
(http://www.fokus.gmd.de/linux/FAQ/I4L-FAQ/i4lfaq-18.html):
"18.8 2channel_mpppcompile: I tried MPPP but it doesn't work. The ipppd
writes in the debug log something like: " ... rcvd (0)(proto=0x3d) c0 00 00
00 80 fd 01 01 00 0a ... sent (0)(LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd
01 ..."
You forgot to compile MPPP/RFC1717 support into the ISDN Subsystem. Recompile
with this option enabled. "
Are you seeing those kind of messages?
James Carlson
> "18.8 2channel_mpppcompile: I tried MPPP but it doesn't work. The ipppd
> writes in the debug log something like: " ... rcvd (0)(proto=0x3d) c0 00 00
> 00 80 fd 01 01 00 0a ... sent (0)(LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd
> 01 ..."
>
> You forgot to compile MPPP/RFC1717 support into the ISDN Subsystem. Recompile
> with this option enabled. "
What kind of broken code negotiates the MRRU option and then LCP
Protocol-Rejects 003d? That's pretty awful behavior even for a
compilation option ...
Olaf Stetzer
> Olaf Stetzer <olaf.s...@imk.fzk.de> wrote:
>> James Carlson schrieb:
>>>
>>> Olaf Stetzer <olaf.s...@imk.fzk.de> writes:
>>> > I am trying hard to get a ppp-connection via
>>> > pppd/ttyi0/hisax on Linux 2.2.19 but something
>>> > goes wrong. I use kppp to start the connection
>
> I think this is an ISDN connection using a card (hisax). I'd suspect
> the hisax driver, in view of all that has been said so far. Purely a
> guess though.
>
Yes you are right! Hisax is providing a virtual tty-modem to enable
the use of standard pppd-connections over this "modem".
Yesterday evening I tried some more options including novj & novjccomp.
This was interesting because the amount of data received from the remote
server increased significantly (from about 10k to 18k) for the same
request (I always tried to open the same web-page). So it seems that the
server is sending vj-packets although kppp shows 0 received vj-packets.
Maybe there is a problem with vj-decompression, I am not sure if this
is implemented in pppd or do I need to compile a kernel module for that
(though I haven't found one yet to configure)?
Here is a log for one of the trials yesterday (connection terminated by me):
------------------------------------
Oct 16 23:14:45 Merlin pppd[1341]: Unsupported protocol 'Stampede Bridging'
(0x6f) received
Oct 16 23:14:45 Merlin pppd[1341]: sent [LCP ProtRej id=0xb 00 6f 6f 73 65
2e 64 74 64 22 3e 0d 0a 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64
3e 0d ...]
Oct 16 23:14:45 Merlin pppd[1341]: rcvd [proto=0x67] 68 6c 69 67 68 74 32
20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29 3b 0d 0a 20 20 48 69 67 68 6c 69
...
Oct 16 23:14:45 Merlin pppd[1341]: Unsupported protocol 0x67 received
Oct 16 23:14:45 Merlin pppd[1341]: sent [LCP ProtRej id=0xc 00 67 68 6c 69
67 68 74 32 20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29 3b 0d 0a 20 20 48 69
67 68 ...]
Oct 16 23:14:45 Merlin pppd[1341]: sent [LCP EchoReq id=0x2 magic=0x0]
Oct 16 23:14:45 Merlin pppd[1341]: rcvd [LCP EchoRep id=0x2 magic=0x0]
Oct 16 23:14:50 Merlin pppd[1341]: rcvd [proto=0x6f] 6f 73 65 2e 64 74 64
22 3e 0d 0a 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64 3e 0d 0a 0d
...
Oct 16 23:14:50 Merlin pppd[1341]: Unsupported protocol 'Stampede Bridging'
(0x6f) received
Oct 16 23:14:50 Merlin pppd[1341]: sent [LCP ProtRej id=0xd 00 6f 6f 73 65
2e 64 74 64 22 3e 0d 0a 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64
3e 0d ...]
Oct 16 23:14:50 Merlin pppd[1341]: rcvd [proto=0x67] 68 6c 69 67 68 74 32
20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29 3b 0d 0a 20 20 48 69 67 68 6c 69
...
Oct 16 23:14:50 Merlin pppd[1341]: Unsupported protocol 0x67 received
Oct 16 23:14:50 Merlin pppd[1341]: sent [LCP ProtRej id=0xe 00 67 68 6c 69
67 68 74 32 20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29 3b 0d 0a 20 20 48 69
67 68 ...]
Oct 16 23:14:59 Merlin pppd[1341]: rcvd [proto=0x6f] 6f 73 65 2e 64 74 64
22 3e 0d 0a 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64 3e 0d 0a 0d
...
Oct 16 23:14:59 Merlin pppd[1341]: Unsupported protocol 'Stampede Bridging'
(0x6f) received
Oct 16 23:14:59 Merlin pppd[1341]: sent [LCP ProtRej id=0xf 00 6f 6f 73 65
2e 64 74 64 22 3e 0d 0a 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64
3e 0d ...]
Oct 16 23:14:59 Merlin pppd[1341]: rcvd [proto=0x67] 68 6c 69 67 68 74 32
20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29 3b 0d 0a 20 20 48 69 67 68 6c 69
...
Oct 16 23:14:59 Merlin pppd[1341]: Unsupported protocol 0x67 received
Oct 16 23:14:59 Merlin pppd[1341]: sent [LCP ProtRej id=0x10 00 67 68 6c 69
67 68 74 32 20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29
3b 0d 0a 20 20 48 69 67 68 ...]
Oct 16 23:15:06 Merlin pppd[1341]: Terminating on signal 15.
Oct 16 23:15:06 Merlin pppd[1341]: Script /etc/ppp/ip-down started (pid
1354)
Oct 16 23:15:06 Merlin pppd[1341]: sent [LCP TermReq id=0x11 "User request"]
Oct 16 23:15:06 Merlin pppd[1341]: rcvd [LCP TermAck id=0x11]
Oct 16 23:15:06 Merlin pppd[1341]: Connection terminated.
Oct 16 23:15:06 Merlin pppd[1341]: Connect time 1.4 minutes.
Oct 16 23:15:06 Merlin pppd[1341]: Sent 8296 bytes, received 11255 bytes.
Oct 16 23:15:06 Merlin pppd[1341]: Waiting for 1 child processes...
Oct 16 23:15:06 Merlin pppd[1341]: script /etc/ppp/ip-down, pid 1354
Oct 16 23:15:06 Merlin pppd[1341]: Script /etc/ppp/ip-down finished (pid
1354), status = 0x0
Oct 16 23:15:06 Merlin pppd[1341]: Exit.
----------------------------------------
Another interesting point:
I tried to ftp via command-line to a known ftp-server. I always could
enter anonymous as login an was reqested to enter my email for password.
After entering this the connection hangs after the following message:
230-
This happened for different pppd-options so the error may be caused by
something completely different? Maybe hardware? BTW: My card is an old
Sedlbauer speed win but it correctly identified by the hisax-module.
Thanks for your help,
Olaf
James Carlson
> Maybe there is a problem with vj-decompression, I am not sure if this
> is implemented in pppd or do I need to compile a kernel module for that
> (though I haven't found one yet to configure)?
I really think you're barking up the wrong tree with that. I
mentioned before in this thread that VJ can't ever send or receive
things without a proper PPP header. It's still true. VJ doesn't
touch the PPP header, and thus cannot cause the header to go bad, and
thus cannot cause LCP Protocol-Rejects.
> Oct 16 23:14:45 Merlin pppd[1341]: Unsupported protocol 'Stampede Bridging'
> (0x6f) received
> Oct 16 23:14:45 Merlin pppd[1341]: sent [LCP ProtRej id=0xb 00 6f 6f 73 65
> 2e 64 74 64 22 3e 0d 0a 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64
> 3e 0d ...]
> Oct 16 23:14:45 Merlin pppd[1341]: rcvd [proto=0x67] 68 6c 69 67 68 74 32
> 20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29 3b 0d 0a 20 20 48 69 67 68 6c 69
> ...
Decoding that hex data as ASCII gives:
oose.dtd">
<html>
ghlight2 = new Image();
Highli
It looks very much to me like the peer is somehow sending you raw
application data without the necessary TCP, IP, and PPP headers. This
is horribly broken.
One thing that could cause this is a peer MP (RFC 1990 Multilink PPP)
implementation that (somehow) sends the wrong bits in the MP header --
mismarking the MP fragments as "beginning" when they're really in the
middle of an IP datagram -- or a local implementation that manages to
mishandle the MP header in an analogous way. This would result in
intermediate fragments (which have no TCP/IP or inner PPP headers)
being dispatched by PPP as mangled PPP packets, and would have exactly
the symptoms you cite.
In fact, the fact that small packets make it through OK but larger
ones do not means that it's packet-size related, and MP fragmentation
is certainly triggered by packet size on most implementations.
Does this occur when MP is off (nomp)? What happens if you do
nompshortseq?
Can you modify the peer's MP kernel bits to stop fragmenting? MP
doesn't require fragmentation at all; it's merely an implementation
option. If the peer sent each packet with MP headers, but with both B
and E bits set (unfragmented), then you might avoid this problem.
Olaf Stetzer
>
> Olaf Stetzer <oste...@mail.uni-mainz.de> writes:
> > Maybe there is a problem with vj-decompression, I am not sure if this
> > is implemented in pppd or do I need to compile a kernel module for that
> > (though I haven't found one yet to configure)?
>
> I really think you're barking up the wrong tree with that. I
> mentioned before in this thread that VJ can't ever send or receive
> things without a proper PPP header. It's still true. VJ doesn't
> touch the PPP header, and thus cannot cause the header to go bad, and
> thus cannot cause LCP Protocol-Rejects.
OK, sorry. I am really not an expert in these things, I only tried to
interpret the observations I did.
> > Oct 16 23:14:45 Merlin pppd[1341]: Unsupported protocol 'Stampede Bridging'
> > (0x6f) received
> > Oct 16 23:14:45 Merlin pppd[1341]: sent [LCP ProtRej id=0xb 00 6f 6f 73 65
> > 2e 64 74 64 22 3e 0d 0a 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64
> > 3e 0d ...]
> > Oct 16 23:14:45 Merlin pppd[1341]: rcvd [proto=0x67] 68 6c 69 67 68 74 32
> > 20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29 3b 0d 0a 20 20 48 69 67 68 6c 69
> > ...
>
> It looks very much to me like the peer is somehow sending you raw
> application data without the necessary TCP, IP, and PPP headers. This
> is horribly broken.
>
> One thing that could cause this is a peer MP (RFC 1990 Multilink PPP)
> implementation that (somehow) sends the wrong bits in the MP header --
> mismarking the MP fragments as "beginning" when they're really in the
> middle of an IP datagram -- or a local implementation that manages to
> mishandle the MP header in an analogous way. This would result in
> intermediate fragments (which have no TCP/IP or inner PPP headers)
> being dispatched by PPP as mangled PPP packets, and would have exactly
> the symptoms you cite.
>
> In fact, the fact that small packets make it through OK but larger
> ones do not means that it's packet-size related, and MP fragmentation
> is certainly triggered by packet size on most implementations.
>
> Does this occur when MP is off (nomp)? What happens if you do
> nompshortseq?
nomp does no effect, I forogt to try nompshortseq yesterday, I will
try it this evening.
> Can you modify the peer's MP kernel bits to stop fragmenting? MP
> doesn't require fragmentation at all; it's merely an implementation
> option. If the peer sent each packet with MP headers, but with both B
> and E bits set (unfragmented), then you might avoid this problem.
>
Ummmm, how do I do this? The peer is just an internet-by-call-provider,
and intersetingly this happens with another provider I tried too.
Maybe some important fact I forgot to mention: The modem-emulation
of isdn4linux provides a way to set the protocol to HDLC. I had to
set this option to get a connection to the provider at all. I also
had to set the sync option (which is also HDLC) for pppd. Was this a
correct setting/ combination of settings?
Thanks,
Olaf
--
trubl...@gmail.com
I meet the same problem.
Jul 27 21:30:32 SUSE-mao pppd[83992]: Unsupported protocol 0x7374 received
Jul 27 21:30:32 SUSE-mao pppd[83992]: sent [LCP ProtRej id=0x2a 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 ...]
Jul 27 21:30:32 SUSE-mao pppd[83992]: rcvd [proto=0x7475] 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 ...
Jul 27 21:30:32 SUSE-mao pppd[83992]: Unsupported protocol 0x7475 received
Jul 27 21:30:32 SUSE-mao pppd[83992]: sent [LCP ProtRej id=0x2b 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 ...]
在 2001年10月18日星期四 UTC+8下午3:32:24，Olaf Stetzer写道：