LCP 协商期间 GPRS PPP 连接失败
我做了一些将 TCP/IP 堆栈移植到 MCU 的工作。通过GPRS，MCU可以连接互联网。 但是，我在LCP协商过程中遇到了一些麻烦。以下是我参考网络材料的解决方案
为了使MCU PPP更简单。LCP选项请求将被拒绝响应。
<预>服务器:7e ff 03 c0 21 01 01 00 14 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 54 06 7e 单片机：7e ff 03 c0 21 04 01 00 04 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 69 78 7e第二步中预计会出现身份验证请求。但我收到一个无 LCP 选项的请求。
服务器：7e ff 03 c0 21 01 02 00 04 b5 5a 7e
这意味着服务器强制 MCU 启动 LCP 协商。我失踪了。
我向服务器发送一个身份验证选项请求，以便强制服务器开始身份验证选项协商。服务器回复我两个数据包。一个是身份验证请求的 ACK 数据包。另一个仍然是无 LCP 选项。
MCU:7e ff 03 c0 21 01 05 00 08 03 04 C0 23 ac 56 7e Server:7e ff 03 c0 21 02 05 00 08 03 04 C0 23 bd 34 7e Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
经过多次“无选项”请求后，谈判结束。我应该怎么办？我是l
（我的英语不好。我希望你能理解我的意思。）
I did some work to transplant TCP/IP stack to MCU. Through GPRS, MCU can connect internet.
However, I met with some trouble during LCP negotiation.The following is my solution referring networking material
In order to make MCU PPP simpler.The LCP option request will be respond with rejection.
Server:7e ff 03 c0 21 01 01 00 14 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 54 06 7e MCU:7e ff 03 c0 21 04 01 00 04 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 69 78 7e
A authentication request is expected in the second step. But i get a none LCP option request.
Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
This means server forces MCU to start LCP negotiation.I am missing.
I send a authentication option request to server so that forcing server to start authentication option negotiation.Server respond me two packets.One is a ACK packet for authentication request.The another still is the none LCP option.
MCU:7e ff 03 c0 21 01 05 00 08 03 04 C0 23 ac 56 7e Server:7e ff 03 c0 21 02 05 00 08 03 04 C0 23 bd 34 7e Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
After several "none option" request, The negotiation over. What should I do? I am l
(My english is not good .I hope you can understand my means.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当调制解调器发送配置请求时，您以配置拒绝响应。然后调制解调器将发送一个新的修改后的配置请求。请参阅 RFC1661 第 6.4 章。
因此，当Configure-Request 包含适合您的值时，您应该使用Configure-Ack 进行响应。因此，您应该在第二个配置请求之后发送配置确认。
When you respond with Configure-Reject when modem sends Configure-Request. Then modem will send a new modified Configure-Request. See RFC1661 chapter 6.4.
So you should respond with Configure-Ack when Configure-Request contains suitable values for you. So you should send Configure-Ack after the second Configure-Request.