Netifd: IPv6CP reset by peer sets the interface as down

Installing and Using OpenWrt
1 
Mon Jun  6 09:18:43 2022 daemon.info pppd[14804]: IPV6CP terminated by peer
Mon Jun  6 09:18:43 2022 daemon.notice netifd: Interface 'MYINTERFACE' has lost the connection

MYINTERFACE has not lost the connection, it still has functioning IPv4 stack, which can be used just fine.

How do I patch this on 22.03-rc1?

2
  • You would fix the peer per the error
  • I would have to read the RFC to recall what they are; but I would ensure you allow the Control Mesages

?

3
  • You would fix the peer per the error

I don't think that's a possibility.

4

It usually isn't, did you ask your ISP?

(You do see the error says the peer terminated the connection, correct?)

I assume your peer is the ISP.

But I would ensure you allow CP.

5

Yes, Yes.

Peer terminated the IPv6 connection but IPv4 connection is just fine.

1 Like
6

You noted this in Post No. 1 already:

:+1:

(It has no bearing on this IPv6 issue - as I understand, if thats the reason you mentioned it again.)

7

Well, the problem is netifd is marking "interface has lost connection" incorrectly. Not exactly an IPv6 issue, peer could terminate IPCP instead of IPv6CP.

8

Are you saying IPv6 works?

:+1:

I hope the best for your troubleshooting with the ISP.

Perhaps someone else will read and see an issue locally?

9

IPv4 works. Peer terminates IPv6 connection.

1 Like
10

OK, the error is correct (unless there's something you haven't mentioned). Cool.

The "incorrectly" comment confused me. Well, I hope the best.

11

You have been very unhelpful and very annoying. Interface has an IPv4 address and route and netifd marks it as "lost connection". That's not correct.

12

???

I apologize, maybe I'm misreading or we're having a language issue. I'll leave and let someone else respond.

EDIT: Now that I reread, maybe it seems you don't care about IPv6 so you're disregarding it because the IPv4 stack is up...so you want a patch to ignore the IPv6 stack going down.

That's not clear, so my apologies again.

13

@Zap - the issue seems here:

Right now ip-down-script and ipv6-down-script will both point to the same /lib/netifd/ppp-down script which simply terminates the link once invoked, regardless of by which address control protocol.

I think for a proper solution, both IPCP (through ip-up-script) and IPV6CP (through ipv6-up-script) need to be tracked separately and the link down (proto_init_update / proto_send_update) in ppp-down should only be done if both control protocols are down.

2 Likes
14

Thank you very much for the explanation @jow . I'll go with changing ipv6-down-script path to something else that confirms the no connection on IPv4 either and then call /lib/netifd/ppp-down for now.

15

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.