Project

General

Profile

Bug #8611

unable to receive IPv6 RA's on SG-1000, default route lost

Added by Anthony Roberts over 1 year ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Interfaces
Target version:
Start date:
06/30/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.3_1
Affected Architecture:
SG-1000

Description

expected behavior:
  • IPv6 default route is stable indefinitely
actual behavior:
  • IPv6 default route is lost a few minutes after release/renew
  • WAN interface still has IPv6 address
  • LAN interface still has /64
  • pfsense router has no default route, so it is impossible to route IPv6 traffic
configuration:
  • residential comcast connection
  • SG-1000 running 2.4.3-RELEASE-1 (arm)
  • WAN interface (cpsw0) configured for DHCPv4, DHCPv6-PD
  • LAN interface (cpsw1) configured to track WAN for PD
investigation:
  • attempted to run tcpdump on WAN interface
  • tcpdump shows RAs received from ISP
    21:04:22.040097 00:01:5c:7a:d0:46 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 198: fe80::201:5cff:fe7a:d046 > ff02::1: ICMP6, router advertisement, length 144
    
  • RA dest IPv6 multicast address appears to be correct, MAC address appears to be correct for IPv6 multicast
  • when running tcpdump, IPv6 default route is re-added to pfsense routing table
hypothesis:
  • tcpdump places cpsw0 interface is promiscuous mode, and when in promiscuous mode, RA's are received
  • when cpsw0 not in promiscuous mode, RA's are not received
  • works temporarily on release/renew possibly because IPv4 DHCP client places interface in promiscuous mode temporarily when acquiring lease
experiment 1:
  • "ifconfig cpsw0 promisc"
  • result: IPv6 default route is stable over several days
experiment 2:
  • "ifconfig cpsw0 -promisc; tcpdump -pni cpsw0"
  • -p flag prevents tcpdump from placing interface in promiscuous mode
  • result: ISP RAs are not seen
workaround:
  • use shellcmd pkg to run "ifconfig cpsw0 promisc" on startup

History

#1 Updated by Jim Pingle over 1 year ago

  • Status changed from New to Feedback

Can you test this on a 2.4.4 snapshot? The base OS has been upgraded there, and most likely the behavior will be different.

#2 Updated by Anthony Roberts over 1 year ago

Jim Pingle wrote:

Can you test this on a 2.4.4 snapshot? The base OS has been upgraded there, and most likely the behavior will be different.

Yup, I was able to repro on july 3rd 2.4.4 snapshot after removing my workaround.

When I do a "tcpdump -pni cpsw0 icmp6" I get nothing, when I do "tcpdump -ni cpsw0 icmp6" I see comcast's RAs every 4 seconds.

#3 Updated by Jim Pingle over 1 year ago

  • Status changed from Feedback to New

#4 Updated by Steve Beaver about 1 year ago

  • Assignee set to Luiz Souza

#5 Updated by Luiz Souza about 1 year ago

  • Subject changed from unable to recieve IPv6 RA's on SG-1000, default route lost to unable to receive IPv6 RA's on SG-1000, default route lost

#6 Updated by Steve Beaver about 1 year ago

  • Target version changed from 2.4.4 to 48

#7 Updated by Jim Pingle 7 months ago

  • Target version changed from 48 to 2.5.0

Also available in: Atom PDF