search

joukewitteveen / netctl

Profile based systemd network management
https://gitlab.archlinux.org/archlinux/netctl
GNU General Public License v3.0
176 stars 65 forks source link

Fix: IPCP: timeout sending Config-Requests #162

Closed choopm closed 6 years ago

choopm commented 6 years ago

According to the docs, pppd will try to determine the local IP address and include it in the IPCP ConfReq. This leads to any local IP being sent in the request as seen in journalctl (added debug dump logfd 2 too):

Okt 17 10:21:59 arch-x230 pppd[13514]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Okt 17 10:21:59 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:21:59 arch-x230 pppd[13514]: rcvd [LCP EchoRep id=0x0 magic=0x5e049130]
Okt 17 10:21:59 arch-x230 pppd[13514]: rcvd [LCP ProtRej id=0x1 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Okt 17 10:21:59 arch-x230 pppd[13514]: Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
Okt 17 10:22:02 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:05 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:08 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:12 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:15 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:18 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:21 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:24 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:27 arch-x230 pppd[13514]: sent [IPCP ConfReq id=0x1 <addr 192.168.10.13> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:22:29 arch-x230 pppd[13514]: sent [LCP EchoReq id=0x1 magic=0xe4aa7389]
Okt 17 10:22:29 arch-x230 pppd[13514]: rcvd [LCP EchoRep id=0x1 magic=0x5e049130]
Okt 17 10:22:30 arch-x230 pppd[13514]: IPCP: timeout sending Config-Requests

As you can see, some providers won't reply with a IPCP ConfNak, so this times out and no IP is assigned. I'm on Vodafone.de.

This PR disables the default behaviour and will include 0.0.0.0 in the IPCP ConfReq:

Okt 17 10:33:58 arch-x230 pppd[13893]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Okt 17 10:33:58 arch-x230 pppd[13893]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Okt 17 10:33:58 arch-x230 pppd[13893]: rcvd [LCP EchoRep id=0x0 magic=0x5546a71e]
Okt 17 10:33:58 arch-x230 pppd[13893]: rcvd [LCP ProtRej id=0x1 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Okt 17 10:33:58 arch-x230 pppd[13893]: Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
Okt 17 10:34:00 arch-x230 pppd[13893]: rcvd [IPCP ConfReq id=0x1]
Okt 17 10:34:00 arch-x230 pppd[13893]: sent [IPCP ConfNak id=0x1 <addr 0.0.0.0>]
Okt 17 10:34:00 arch-x230 pppd[13893]: rcvd [IPCP ConfNak id=0x1 <addr 10.165.250.24> <ms-dns1 62.109.121.17> <ms-dns2 62.109.121.18>]
Okt 17 10:34:00 arch-x230 pppd[13893]: sent [IPCP ConfReq id=0x2 <addr 10.165.250.24> <ms-dns1 62.109.121.17> <ms-dns2 62.109.121.18>]
Okt 17 10:34:00 arch-x230 pppd[13893]: rcvd [IPCP ConfReq id=0x2]
Okt 17 10:34:00 arch-x230 pppd[13893]: sent [IPCP ConfAck id=0x2]
Okt 17 10:34:00 arch-x230 pppd[13893]: rcvd [IPCP ConfAck id=0x2 <addr 10.165.250.24> <ms-dns1 62.109.121.17> <ms-dns2 62.109.121.18>]
Okt 17 10:34:00 arch-x230 pppd[13893]: Could not determine remote IP address: defaulting to 10.64.64.64
Okt 17 10:34:00 arch-x230 pppd[13893]: not replacing existing default route via 192.168.10.1
Okt 17 10:34:00 arch-x230 pppd[13893]: Cannot determine ethernet address for proxy ARP
Okt 17 10:34:00 arch-x230 pppd[13893]: local  IP address 10.165.250.24
Okt 17 10:34:00 arch-x230 pppd[13893]: remote IP address 10.64.64.64
Okt 17 10:34:00 arch-x230 pppd[13893]: primary   DNS address 62.109.121.17
Okt 17 10:34:00 arch-x230 pppd[13893]: secondary DNS address 62.109.121.18

Signed-off-by: Christoph Hoopmann christophhoopmann@gmail.com

joukewitteveen commented 6 years ago

Thanks for taking the time to contribute to netctl!

The addition looks okay. Any chance this will break someones setup?

choopm commented 6 years ago

The addition looks okay. Any chance this will break someones setup?

I don't see any reason to leak private addresses to mobile providers and someone depending on that, I think it's safe to merge. If this breaks someones setup though, they would search for the message IPCP: timeout sending Config-Requests and find this PR / commit message.

joukewitteveen commented 6 years ago

That is not good enough. We don't want someone to end up without a connection just because the defaults of netctl changed. If there is a reasonable scenario where you would not want noipdefault in your configuration, then the current PR should be changed into an extra flag. However, if there is no such scenario, I would rather not add such a flag.

choopm commented 6 years ago

This is now a profile option, defaulting to 'no' and shipped with the examples as 'yes'. Should be good now, won't break existing profiles/behaviour.

joukewitteveen commented 6 years ago

@zoqaeski This PR suggests to add noipdefault to the pppd options of the mobile_ppp connection type. I looked into the manual and believe that not having this option is really only meaningful if your options include a local IP address. Is this correct? If so, the addition can be done unconditionally. Otherwise, it has to be added as a configuration flag.

choopm commented 6 years ago

I can imagine someone using pppd to establish a connection using fixed known endpoints. In this case you'd have to configure the addresses or depend on the default behaviour. In our case (mobile_ppp), we're establishing the link without knowing any IP configurations. In my opinion there's no reason to request any specific address when establishing a mobile_ppp connection and we should have it fixed to request 0.0.0.0, since some providers don't reply with a ConfNak when requesting private addresses.

@joukewitteveen Did you try it yourself? What does your IPCP negotiation look like? Are you receiving ConfNak for your private addresses too?

edit: @zoqaeski uses it too: netcfg-ppp-mobile

choopm commented 6 years ago

Any updates on this?

joukewitteveen commented 6 years ago

Yes, I pulled one of your commits locally (and changed it slightly). The next version of netctl will set noipdefault by default. As far as I understand, not setting this option only makes sense in situations where you can be explicit about the local IP. If this new default causes trouble, we should implement more elaborate support for setting the local IP through e.g. IP=. The noipdefault option would then only be included when IP= is unset.

In the future, try to squash typo commits.

Anyways, thank you for making netctl better!

joukewitteveen commented 6 years ago

f13c69f1136a9b03138744b53b368807029cbb2c