0

I'm working with a VxWorks PPP server running on an embedded system. There seems to be a problem with IPCP DNS negotiation. Each time the PPP server offers a IPCP to a client, the client seems to be rejecting the DNS1 and DNS2 fields and is accepting the IP address.

I tried with a windows dial up connection ( with 'automatically request dns' option) and an Ubuntu pppoed client (with 'usepeerdns' option). In both cases the clients are configured to obtain the DNS from the PPP server.

The packet sequence are as follows:

  1. Client sends IPCP Configure-Request with IP, DNS1 and DNS2 set to 0.
  2. Server sends IPCP Configure-Request with the relevant IP, DNS1 and DNS2 in the options field.
  3. Client sends Configure-Reject (Code 0x04) with DNS1 and DNS2 in the payload.
  4. Server sends IPCP Configure-Request with just the IP. Handshaking completes with a ACK and both agreeing on just the IP address.

I'm not really sure where this is going wrong.

Any help is much appreciated! Thanks!

closed as off-topic by Ron Maupin Feb 5 '17 at 16:14

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta." – Ron Maupin
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Unfortunately, questions about host/server/VM configuration are off-topic here. You could try to ask this question on Server Fault for a business network, or on Super User for a personal network. – Ron Maupin Feb 5 '17 at 16:14
1

In IPCP (like LCP and related protocols) there are two negociations, one for each direction of the link. Your step 1 is the client asking for IP and DNSs, step 2 is not the server answering to this request, but the server asking for its own IP and DNSs (the other negociation). In step 3 the client rejects, as it does not want to provide DNSs to the server.

Are you sure you see all the IPCP packets exchanged? In you sequence, the server never answers to the client request.

You should see something like (just one common scenario, this may differ):

client conf
 C>S req IP=0.0.0.0, DNS1=0.0.0.0, DNS2=0.0.0.0  # client asks
 C<S nak IP=a.b.c.d, DNS1=e.f.g.h, DNS2=i.j.k.l  # server suggests values
 C>S req IP=a.b.c.d, DNS1=e.f.g.h, DNS2=i.j.k.l  # client requests suggested values
 C<S ack IP=a.b.c.d, DNS1=e.f.g.h, DNS2=i.j.k.l  # servers acks

and another negociation (possibly interleaved) maybe something like:

 server conf
 S>C req IP=v.w.x.y.z  # server informs about its IP
 S<C ack IP=v.w.x.y.z  # client acks the server IP address

IPCP is decribed in RFC1332, but it says

IPCP uses the same packet exchange machanism as the Link Control Protocol (LCP).

So one has to read rfc1661 for the description of how the negociations take place.

  • Hi @JeanPierre, I found a couple of sample captures of IPCP Wireshark sample capture for IPCP. Here the server seems to respond to the client's configure-request with a configure-request offering an IP. This behavior is consistent with what I see on my end. What I'm not sure is that the first reply which my server provides, it packs the IP address offer and both the DNS IPs. In the sample capture file, the DNS is being given in the NAK. Thank you! – fastforward Feb 6 '17 at 21:48
  • Again, DCE answer to DTE request (frame 16) is the NAK in frame 21. Frame 18 is the DCE requesting that the DTE acknowledges DCE's IP. The DCE paramters are negociated in 18 and 19, the DTE's in 16, 21, 22 and 23. – JeanPierre Feb 7 '17 at 8:00
  • Thanks a lot @JeanPierre! I rechecked my capture and as you said, I had configured the server wrong to provide DNS in the DCE->DTE inform request (corresponding to frame 18) and nothing in the NAK. Now I've configured the server to provide DNS in the NAK only if the client wants DNS. Thank you! – fastforward Feb 7 '17 at 21:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.