Project

General

Profile

Actions

Bug #8611

open

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

Added by Anthony Roberts over 6 years ago. Updated almost 4 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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
Actions #1

Updated by Jim Pingle over 6 years 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.

Actions #2

Updated by Anthony Roberts over 6 years 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.

Actions #3

Updated by Jim Pingle over 6 years ago

  • Status changed from Feedback to New
Actions #4

Updated by Anonymous over 6 years ago

  • Assignee set to Luiz Souza
Actions #5

Updated by Luiz Souza over 6 years 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
Actions #6

Updated by Anonymous about 6 years ago

  • Target version changed from 2.4.4 to 48
Actions #7

Updated by Jim Pingle over 5 years ago

  • Target version changed from 48 to 2.5.0
Actions #8

Updated by Viktor Gurov almost 5 years ago

no such issue on pfSense 2.5.0.a.20200205.1753

pfSense 2.4.4-p3 on SG-3100 as DHCP6/RA server
SG-1000 cpsw0 interface can get IPv6 address via DHCP6/SLAAC without 'promisc' option

Actions #9

Updated by Pete Wright over 4 years ago

Viktor Gurov wrote:

no such issue on pfSense 2.5.0.a.20200205.1753

pfSense 2.4.4-p3 on SG-3100 as DHCP6/RA server
SG-1000 cpsw0 interface can get IPv6 address via DHCP6/SLAAC without 'promisc' option

I am seeing the same issue on my sg-1000. I have upgraded to 2.5 and it does not look like this has solved my issue. It seems like setting my WAN interface to PROMISC is still a required workaround to be able to view RA's from my ISP (Spectrum cable in US).

Is it possible this is a hardware or driver issue? I'd be happy to help debug this or provide any additional information from my end.

Actions #10

Updated by Viktor Gurov about 4 years ago

looks like bxe(4) driver bug, see #8324

Actions #11

Updated by Luiz Souza almost 4 years ago

  • Status changed from New to Feedback

Fixed. Multicast address are enabled by default now.

Please test with the next snapshot.

Actions #12

Updated by Luiz Souza almost 4 years ago

  • % Done changed from 0 to 100
Actions #13

Updated by Jim Pingle almost 4 years ago

  • Status changed from Feedback to New

On the 20201208.0803 snapshot I still have to put the interface in promiscuous mode or it doesn't receive an IPv6 default route.

Actions #14

Updated by Luiz Souza almost 4 years ago

  • Status changed from New to In Progress

Jim Pingle wrote:

On the 20201208.0803 snapshot I still have to put the interface in promiscuous mode or it doesn't receive an IPv6 default route.

I can't reproduce this, it seems to work okay for me.

Can you send me output of a tcpdump with and without the promiscuous mode ?

Something like: tcpdump -[p]nei cpsw0 icmp6 (you can filter it down to the RA advertisement).

Actions #15

Updated by Jim Pingle almost 4 years ago

Luiz Souza wrote:

Jim Pingle wrote:

On the 20201208.0803 snapshot I still have to put the interface in promiscuous mode or it doesn't receive an IPv6 default route.

I can't reproduce this, it seems to work okay for me.

Looks like it works OK on a bare interface but fails on a VLAN. I just happened to try it first on a device which used a VLAN for a WAN.

With promisc mode, it gets a default route:

: tcpdump -nei cpsw0.40 'ether host 68:9e:19:7f:f6:d7 and icmp6 and (ip6[40] = 133 or ip6[40] = 134)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cpsw0.40, link-type EN10MB (Ethernet), capture size 262144 bytes
10:45:07.825310 68:9e:19:7f:f6:d7 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::6a9e:19ff:fe7f:f6d7 > ff02::2: ICMP6, router solicitation, length 16
10:45:07.841564 00:08:a2:09:95:b5 > 68:9e:19:7f:f6:d7, ethertype IPv6 (0x86dd), length 190: fe80::208:a2ff:fe09:95b5 > fe80::6a9e:19ff:fe7f:f6d7: ICMP6, router advertisement, length 136

Without promisc mode, it doesn't get the default route (and it tries twice instead of once):

: tcpdump -pnei cpsw0.40 'ether host 68:9e:19:7f:f6:d7 and icmp6 and (ip6[40] = 133 or ip6[40] = 134)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cpsw0.40, link-type EN10MB (Ethernet), capture size 262144 bytes
10:46:30.301221 68:9e:19:7f:f6:d7 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::6a9e:19ff:fe7f:f6d7 > ff02::2: ICMP6, router solicitation, length 16
10:46:30.317627 00:08:a2:09:95:b5 > 68:9e:19:7f:f6:d7, ethertype IPv6 (0x86dd), length 190: fe80::208:a2ff:fe09:95b5 > fe80::6a9e:19ff:fe7f:f6d7: ICMP6, router advertisement, length 136
10:46:31.668277 68:9e:19:7f:f6:d7 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::6a9e:19ff:fe7f:f6d7 > ff02::2: ICMP6, router solicitation, length 16
10:46:31.683684 00:08:a2:09:95:b5 > 68:9e:19:7f:f6:d7, ethertype IPv6 (0x86dd), length 190: fe80::208:a2ff:fe09:95b5 > fe80::6a9e:19ff:fe7f:f6d7: ICMP6, router advertisement, length 136

On another SG-1000 that doesn't use a VLAN for WAN, it works without any extra intervention.

Actions #16

Updated by Anonymous almost 4 years ago

  • Target version changed from 2.5.0 to CE-Next
Actions

Also available in: Atom PDF