Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly
The following reply was made to PR kern/179901; it has been noted by GNATS.
From: Mikolaj Golub
To: bug-follo...@freebsd.org
Cc: Michael Gmelin
Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled
incorrectly
Date: Sun, 30 Jun 2013 10:17:05 +0300
--EeQfGwPcQSOJBaQU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Jun 27, 2013 at 11:00:16PM +0300, Mikolaj Golub wrote:
> I don't insist on maintaining the old behaviour. But as actually we
> have 2 issues here (regression introduced by me in FreeBSD9 and
> historical behavior that looks wrong), with different priority, I
> would like to fix the issues separately. This way it will be easier to
> track the changes, e.g. when after a year it turns out that the second
> change has broken some other case.
Here is a patch for the second issue.
--
Mikolaj Golub
--EeQfGwPcQSOJBaQU
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="pr179901.2.1.patch"
commit 7cf3a6a95d74ae91c80350fc1ae8e96fe59c3c65
Author: Mikolaj Golub
Date: Sun Jun 30 00:09:20 2013 +0300
A complete duplication of binding should be allowed if on both new and
duplicated sockets a multicast address is bound and either
SO_REUSEPORT or SO_REUSEADDR is set.
But actually it works for the following combinations:
* SO_REUSEPORT is set for the fist socket and SO_REUSEPORT for the new;
* SO_REUSEADDR is set for the fist socket and SO_REUSEADDR for the new;
* SO_REUSEPORT is set for the fist socket and SO_REUSEADDR for the new;
and fails for this:
* SO_REUSEADDR is set for the fist socket and SO_REUSEPORT for the new.
Fix the last case.
PR:179901
diff --git a/sys/netinet/in_pcb.c b/sys/netinet/in_pcb.c
index 3506b74..eb15a38 100644
--- a/sys/netinet/in_pcb.c
+++ b/sys/netinet/in_pcb.c
@@ -554,7 +554,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam,
in_addr_t *laddrp,
* and a multicast address is bound on both
* new and duplicated sockets.
*/
- if (so->so_options & SO_REUSEADDR)
+ if ((so->so_options & (SO_REUSEADDR|SO_REUSEPORT)) != 0)
reuseport = SO_REUSEADDR|SO_REUSEPORT;
} else if (sin->sin_addr.s_addr != INADDR_ANY) {
sin->sin_port = 0; /* yech... */
diff --git a/sys/netinet6/in6_pcb.c b/sys/netinet6/in6_pcb.c
index a0a6874..fb84279 100644
--- a/sys/netinet6/in6_pcb.c
+++ b/sys/netinet6/in6_pcb.c
@@ -156,7 +156,7 @@ in6_pcbbind(register struct inpcb *inp, struct sockaddr
*nam,
* and a multicast address is bound on both
* new and duplicated sockets.
*/
- if (so->so_options & SO_REUSEADDR)
+ if ((so->so_options & (SO_REUSEADDR|SO_REUSEPORT)) != 0)
reuseport = SO_REUSEADDR|SO_REUSEPORT;
} else if (!IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr)) {
struct ifaddr *ifa;
--EeQfGwPcQSOJBaQU--
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DNAT in freebsd
On Sat, Jun 29, 2013 at 09:50:15AM +0300, Sami Halabi wrote:
> I think I was misunderstood...
> Here is the situation i want to handle:
> My box is a router that handles several /24 behind.
> One of my links (em0) is connected to a private network 192.168.0.1 is me,
> my neighbour is 192.168.0.2.
> I want to make that any connection comes to 192.168.0.1 to go to ip
> 193.xxx.yyy.2 using specific public ip 84.xx.yy.1
> And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came
> from 192.168.0.1 and sent to 192.168.0.2/or ant other ips
> behind(192.168.1.xx/24).
>
> Hope that makes it clearer, and I appreciate any help.
>
> Sami
> 29 2013 03:30, ?? "Paul A. Procacci"
> :
The answer I provided you does exactly what you want it to do. Not to mention
the man page goes over other things as well if the answer I provided you
wasn't accurate. Here is my config that I use for my home setup.
The config:
- binds a nat instance on the primary interface
- denies all inbound syn's among other things
- Forward packets originating on the internal network interface through nat
- and returns packets (ack's) back to the original sender.
!!
#!/bin/sh
## Start of IPFW Configuration
# Set rules command prefix :: Rule numbering cannot exceed 900
cmd="/sbin/ipfw -q"
pif="de0" # Public NIC
iif="bridge0" # Internal NIC
##
# Flush current rules and do config.
$cmd -f flush
$cmd enable one_pass
##
${cmd} add 1 allow all from any to any via lo0
${cmd} add 2 deny all from any to 127.0.0.0/8
${cmd} add 3 deny ip from 127.0.0.0/8 to any
${cmd} nat 1 config if ${pif} log deny_in reset unreg_only same_ports
${cmd} add 00020 nat 1 all from any to any via ${pif}
${cmd} add 00050 allow all from any to any via ${iif}
${cmd} add 65534 deny log all from any to any
!!
Again, this information is found in `man ipfw(8)` and does what you are
asking.
~Paul
This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DNAT in freebsd
On 29.06.2013 13:50, Sami Halabi wrote: > I think I was misunderstood... > Here is the situation i want to handle: > My box is a router that handles several /24 behind. > One of my links (em0) is connected to a private network 192.168.0.1 is me, > my neighbour is 192.168.0.2. > I want to make that any connection comes to 192.168.0.1 to go to ip > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 > And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips > behind(192.168.1.xx/24). > > Hope that makes it clearer, and I appreciate any help. You need to setup 2 ipfw nat instanses, one to translate source IPs, another to translate destination IPs (this one needs "reverse" mode). ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DNAT in freebsd
Hi,
Thanks for your time.
What this configuration does is normal NAT configuration (SNAT).
what I'm seeking is combination of SNAT & DNAT to act as a transparent
proxy as:
192.168.0.2 connects to me (192.168.0.1) it'll talk actually with
193.xx.yy.1 whithout knowing it using my special public ip 194.xx.yy.1, and
when 193.xx.yy.1 wants to open connection with 192.168.0.2 it will connect
to 194.xx.yy.1 and 192.168.0.2 will think 192.168.0.1 is talking with it...
Any ideas???
Sami
On Sun, Jun 30, 2013 at 12:15 PM, Paul A. Procacci
wrote:
>
> On Sat, Jun 29, 2013 at 09:50:15AM +0300, Sami Halabi wrote:
> > I think I was misunderstood...
> > Here is the situation i want to handle:
> > My box is a router that handles several /24 behind.
> > One of my links (em0) is connected to a private network 192.168.0.1 is
> me,
> > my neighbour is 192.168.0.2.
> > I want to make that any connection comes to 192.168.0.1 to go to ip
> > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1
> > And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came
> > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips
> > behind(192.168.1.xx/24).
> >
> > Hope that makes it clearer, and I appreciate any help.
> >
> > Sami
> > 29 2013 03:30, ?? "Paul A. Procacci" <
> pproca...@datapipe.com>:
>
> The answer I provided you does exactly what you want it to do. Not to
> mention
> the man page goes over other things as well if the answer I provided you
> wasn't accurate. Here is my config that I use for my home setup.
>
> The config:
>
> - binds a nat instance on the primary interface
> - denies all inbound syn's among other things
> - Forward packets originating on the internal network interface through nat
> - and returns packets (ack's) back to the original sender.
>
> !!
> #!/bin/sh
> ## Start of IPFW Configuration
> # Set rules command prefix :: Rule numbering cannot exceed 900
>
> cmd="/sbin/ipfw -q"
> pif="de0" # Public NIC
> iif="bridge0" # Internal NIC
>
> ##
> # Flush current rules and do config.
> $cmd -f flush
> $cmd enable one_pass
> ##
>
> ${cmd} add 1 allow all from any to any via lo0
> ${cmd} add 2 deny all from any to 127.0.0.0/8
> ${cmd} add 3 deny ip from 127.0.0.0/8 to any
>
> ${cmd} nat 1 config if ${pif} log deny_in reset unreg_only same_ports
> ${cmd} add 00020 nat 1 all from any to any via ${pif}
>
> ${cmd} add 00050 allow all from any to any via ${iif}
>
> ${cmd} add 65534 deny log all from any to any
> !!
>
> Again, this information is found in `man ipfw(8)` and does what you are
> asking.
>
> ~Paul
>
>
>
> This message may contain confidential or privileged information. If you
> are not the intended recipient, please advise us immediately and delete
> this message. See http://www.datapipe.com/legal/email_disclaimer/ for
> further information on confidentiality and the risks of non-secure
> electronic communication. If you cannot access these links, please notify
> us by reply message and we will send the contents to you.
>
--
Sami Halabi
Information Systems Engineer
NMS Projects Expert
FreeBSD SysAdmin Expert
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DNAT in freebsd
Hi, I don't understand how reverse mode works exactly, and didn't find a good example. can you try and help on the configuration? Thanks in advance, Sami On Sun, Jun 30, 2013 at 1:22 PM, Eugene Grosbein wrote: > On 29.06.2013 13:50, Sami Halabi wrote: > > I think I was misunderstood... > > Here is the situation i want to handle: > > My box is a router that handles several /24 behind. > > One of my links (em0) is connected to a private network 192.168.0.1 is > me, > > my neighbour is 192.168.0.2. > > I want to make that any connection comes to 192.168.0.1 to go to ip > > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 > > And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came > > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips > > behind(192.168.1.xx/24). > > > > Hope that makes it clearer, and I appreciate any help. > > You need to setup 2 ipfw nat instanses, one to translate source IPs, > another to translate destination IPs (this one needs "reverse" mode). > > > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
cxgbetool & hw filtering issues
Hello list! While experimenting with Chelsio T440-CR (cxgbe) internal firewall, I'm getting some kind of unexpected results: filtering 'type ipv4 action drop' permits IPv4 TCP traffic with bad checksum. filtering 'type IPv6 action drop' permits IPv6 traffic to multicast addresses (MLDv2, etc..) filtering 'ethtype 34525 action drop' (drop all IPv6) results in 'CHELSIO_T4_SET_FILTER: Argument list too long' despite to what is said in budget table from cxgbetool.8 filtering 'matchtype 4 action drop' or similar (4,5,4:0,4:4, 5:0, 5:5) does not match anything despite some traffic definitely falls into that conditions. filtering 'action drop' and 'iport X action drop' filters IPv4 traffic only. filter 'type ipv6 ...' can be set on (0,4,8,12,...) filter numbers yelling 'CHELSIO_T4_SET_FILTER: Invalid argument' on other numbers. What can I do to debug further/fix this behavior? Some more questions: Does anybody known how I can get/set total number of HW firewall records? There is such tunable in Linux version. Is there any way to retrieve _host_ interface statistic (e.g. how much traffic in packets/bytes are thrown to NIC driver)? Setup description: [packet generator replaying small PCAP with 280kpps rate] -> cxgbe3 [[FreeBSD 10-CURRENT r248721]]. PCAP is captured on my host machine so 1) Outgoing TCP checksums are almost all wrong 2) DST macs are not modified (so they are all unknown to NIC). cxgbe3: flags=28943 metric 0 mtu 1500 options=6c00bb ether 00:07:43:11:88:d8 inet6 fe80::207:43ff:fe11:88d8%cxgbe3 prefixlen 64 scopeid 0x9 inet6 2a02:6b8:0:401:207:43ff:fe11:88d8 prefixlen 64 detached deprecated autoconf nd6 options=23 media: Ethernet 10Gbase-Twinax status: active dev.t4nex.0.%desc: Chelsio T440-CR NIC (rev 2), S/N:PT42110574, E/C:01234567890123 dev.t4nex.0.%driver: t4nex dev.t4nex.0.%location: slot=0 function=4 dev.t4nex.0.%pnpinfo: vendor=0x1425 device=0x4403 subvendor=0x1425 subdevice=0x class=0x02 dev.t4nex.0.%parent: pci8 dev.t4nex.0.nports: 4 dev.t4nex.0.hw_revision: 2 dev.t4nex.0.firmware_version: 1.8.4.0 dev.t4nex.0.cf: default dev.t4nex.0.cfcsum: 4260083439 dev.t4nex.0.linkcaps: 0 dev.t4nex.0.niccaps: 1 dev.t4nex.0.toecaps: 0 dev.t4nex.0.rdmacaps: 0 dev.t4nex.0.iscsicaps: 0 dev.t4nex.0.fcoecaps: 0 dev.t4nex.0.core_clock: 228125 dev.t4nex.0.holdoff_timers: 1 5 10 50 100 200 dev.t4nex.0.holdoff_pkt_counts: 1 8 16 32 dev.t4nex.0.fwq.abs_id: 0 dev.t4nex.0.fwq.cntxt_id: 0 dev.t4nex.0.fwq.cidx: 121 dev.t4nex.0.mgmtq.cntxt_id: 0 dev.t4nex.0.mgmtq.cidx: 95 dev.t4nex.0.mgmtq.pidx: 111 dev.t4nex.0.mgmtq.tx_wrs: 119 dev.t4nex.0.mgmtq.no_desc: 0 dev.t4nex.0.mgmtq.unstalled: 0 # kenv | grep cxgbe hw.cxgbe.fcoecaps_allowed="0" hw.cxgbe.iscsicaps_allowed="0" hw.cxgbe.nrxq10g="4" hw.cxgbe.ntxq10g="4" hw.cxgbe.qsize_rxq="4096" hw.cxgbe.qsize_txq="4096" hw.cxgbe.rdmacaps_allowed="0" hw.cxgbe.toecaps_allowed="0" TRAFFIC PART: input (cxgbe3) output packets errs idrops bytespackets errs bytes colls 284368 0 0 85436494 0 0 0 0 284340 0 0 85442168 0 0 0 0 284205 0 0 85464055 0 0 0 0 ... (not changing, nearly constant rate, is not affected by filters) # ipfw show 200 00200 16860 2685762 deny ip from any to any via cxgbe3 # Running counter to see how much is actually dropped/passed # while true; do sleep 1; ipfw show 200 ; ipfw -q zero 200 ;done [[ empty filters ]] 00200 281769 80351685 deny ip from any to any via cxgbe3 .. [[ ### (1) IPv4 EXPERIMENT ]] [[ # ./cxgbetool t4nex0 filter 0 type ipv4 action drop ]] 00200 115263 15431259 deny ip from any to any via cxgbe3 00200 116523 15584332 deny ip from any to any via cxgbe3 [[# time tcpdump -i cxgbe3 -lnps0 -c 100 ip 18:18:42.621728 IP 95.108.170.36.39215 > 93.158.158.93.80: Flags [.], ack 4252241156, win 995, options [nop,nop,TS val 538195932 ecr 1194270183], length 0 .. tcpdump -i cxgbe3 -lnps0 -c 100 ip 0,00s user 0,01s system 15% cpu 0,059 total #]] [[ ### (2) IPv6 EXPERIMENT ]] [[ # ./cxgbetool t4nex0 filter 4 type ipv6 action drop ]] 00200 64962 10332022 deny ip from any to any via cxgbe3 00200 64878 10327694 deny ip from any to any via cxgbe3 ... [[# time tcpdump -i cxgbe3 -lnps0 -c 100 ip6 18:21:34.553596 IP6 fe80::884:a1e8:86ae:57f7 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 .. tcpdump -i cxgbe3 -lnps0 -c 100 ip6 0,00s user 0,00s system 0% cpu 0,483 total #]] Address in (1) is my host machine address, viewing resulting .pcap file in wireshark shows incorrect TCP checksums for IPv4 packets. Other pcaps not containing "bad" traffic are properly filtered by rules above. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/fr
Re: DNAT in freebsd
On 30.06.2013 18:48, Sami Halabi wrote: > Hi, > I don't understand how reverse mode works exactly, and didn't find a good > example. > > > can you try and help on the configuration? Well, that's pretty simple. Generally, NAT translates source IP address of the packet keeping destination IP intact. You need both of source and destination addresses get translated. Reverse NAT translates does, well, reverse thing: it translates destination IP keeping source IP intact. So, you just need setup two ipfw nat instances, one "general" and one "reverse" and pass your packets through both instances. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Inconsistent NIC behavior
One particular annoyance with Freebsd is that different NICs have different dormant behavior. For example em and igb both will show the link being active or not on boot whether the interface has been UPed or not, while ixgbe and bce do not. I think it's a worthy goal to have NICs work the same in this manner. It's very valuable to know that a nic is connected without having to UP it. And an annoyance when you fire up a new box with a new nic that shows No Carrier when the link light is on. It's really too much of a project for one person to have enough knowledge of multiple drivers to make the changes, so it would be best if the maintainers would do it. BC ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxgbetool & hw filtering issues
On 06/30/13 07:25, Alexander V. Chernikov wrote: > Hello list! > > While experimenting with Chelsio T440-CR (cxgbe) internal firewall, I'm > getting some kind of unexpected results: One bit of general advice to begin with: add "hitcnts 1" to all your filter rules and then you can see how many incoming packets hit that filter in the output of "cxgbetool t4nex0 filter list". I really should make hitcnts=1 the default in the driver. > filtering 'type ipv4 action drop' permits IPv4 TCP traffic with bad > checksum. It may be that a bad checksum makes it an invalid IPv4 packet to the chip and so it doesn't hit the "type ipv4" rule. There is an entirely separate knob available to have the chip drop bad packets if you don't want to see them. The default is to let them through so that users can examine them with tcpdump etc. > filtering 'type IPv6 action drop' permits IPv6 traffic to multicast > addresses (MLDv2, etc..) The DMAC is an L2 multicast address? Try "proto 58 hitcnts 1 action drop" to get these ICMP6 packets. > filtering 'ethtype 34525 action drop' (drop all IPv6) results in > 'CHELSIO_T4_SET_FILTER: Argument list too long' despite to what is said > in budget table from cxgbetool.8 This _would_ have gotten everything with ethertype ipv6 but the default filter mode doesn't have ethtype enabled, which is why it's complaining: # cxgbetool t4nex0 filter mode ipv4 ipv6 sip dip sport dport matchtype proto ivlan iport fcoe > filtering 'matchtype 4 action drop' or similar (4,5,4:0,4:4, 5:0, 5:5) > does not match anything despite some traffic definitely falls into that > conditions. > filtering 'action drop' and 'iport X action drop' filters IPv4 traffic > only. Strange. I use "iport X action drop hitcnts 1" as a packet black hole all the time. Were these the only filters when you tried them? Are you sure your packets didn't hit some other rule and were delivered as a result of that? Check the order in "cxgbetool t4nex0 filter list" Also, are you going by the ifnet rx stats as displayed by netstat etc.? Right now the driver fills the ifnet stats directly from hardware registers rather than counting the packets that it actually received from the chip. The hardware registers include packets that would have been delivered to the driver if no filters were present but are dropped due to a filter. > filter 'type ipv6 ...' can be set on (0,4,8,12,...) filter numbers > yelling 'CHELSIO_T4_SET_FILTER: Invalid argument' on other numbers. Yes, IPv6 filters take 4 tid's (non-IPv6 take 1) and these tid's have to start at a naturally aligned boundary. No way around this. > What can I do to debug further/fix this behavior? > > Some more questions: > Does anybody known how I can get/set total number of HW firewall > records? There is such tunable in Linux version. I will add a simple sysctl for this. For now you can indirectly figure this out from the output of "sysctl -n dev.t4nex.0.misc.tids" -- the FTIDs are the filter tids. For example I see 1456 filters on this card: trantor:~# sysctl -n dev.t4nex.0.misc.tids ATID range: 0-8191, in use: 0 TID range: 2048-18431, in use: 0 STID range: 0-511, in use: 0 FTID range: 512-1967 HW TID usage: 0 IP users, 0 IPv6 users trantor:~# echo $((1967 - 512 + 1)) 1456 > Is there any way to retrieve _host_ interface statistic (e.g. how much > traffic in packets/bytes are thrown to NIC driver)? cxgbe(4) doesn't count this stuff itself. Currently it just reads the hardware registers once per second and it's done. Software stats would have to be per queue (and then aggregated from time to time). I'll wait to see where the PCPU counter work in the kernel goes before reworking this part of the driver. Regards, Navdeep ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DNAT in freebsd
Hi Eugene, It simply doesn't work for me, the reverse option doesn't work properly for me it keeps translating the source instead of the destination... On Sun, Jun 30, 2013 at 6:32 PM, Eugene Grosbein wrote: > On 30.06.2013 18:48, Sami Halabi wrote: > > Hi, > > I don't understand how reverse mode works exactly, and didn't find a > good example. > > > > > > can you try and help on the configuration? > > Well, that's pretty simple. Generally, NAT translates source IP address of > the packet > keeping destination IP intact. You need both of source and > destination addresses get translated. Reverse NAT translates does, > well, reverse thing: it translates destination IP keeping source IP intact. > So, you just need setup two ipfw nat instances, one "general" and one > "reverse" > and pass your packets through both instances. > > Eugene Grosbein > > > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Duplicate Address Detection misfire?
I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the "bridged" type of networking with VMWare. It gets it's IPv4 address from DHCP (successfully) and then fails to initialize IPv6. The relevant rc.conf is: ipv6_activate_all_interfaces="YES" ifconfig_em0_ipv6="inet6 accept_rtadv" ip6addrctl_verbose="YES" The console output says: em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS in/out=2/1, NA in=0 em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found em0: manual intervention required em0: possible hardware address duplication deteted, disable IPv6 And subsequently, em0's nd6 has "IFDISABLED" in it. With wireshark, I see two ICMPv6 neighbor solicitations that are identical --- is this the problem? How do I fix this? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Duplicate Address Detection misfire?
Zaphod Beeblebrox wrote in : zb> I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the zb> "bridged" type of networking with VMWare. It gets it's IPv4 address from zb> DHCP (successfully) and then fails to initialize IPv6. The relevant zb> rc.conf is: zb> zb> ipv6_activate_all_interfaces="YES" zb> ifconfig_em0_ipv6="inet6 accept_rtadv" zb> ip6addrctl_verbose="YES" zb> zb> The console output says: zb> zb> em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS zb> in/out=2/1, NA in=0 zb> em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found zb> em0: manual intervention required zb> em0: possible hardware address duplication deteted, disable IPv6 zb> zb> And subsequently, em0's nd6 has "IFDISABLED" in it. zb> zb> With wireshark, I see two ICMPv6 neighbor solicitations that are identical zb> --- is this the problem? zb> zb> How do I fix this? Does your host environment have the same address on the bridged interface? -- Hiroki pgpZ6CRgYpGOd.pgp Description: PGP signature
Re: Duplicate Address Detection misfire?
On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox wrote: > I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the > "bridged" type of networking with VMWare. It gets it's IPv4 address from > DHCP (successfully) and then fails to initialize IPv6. The relevant > rc.conf is: > > ipv6_activate_all_interfaces="YES" > ifconfig_em0_ipv6="inet6 accept_rtadv" > ip6addrctl_verbose="YES" > > The console output says: > > em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS > in/out=2/1, NA in=0 > em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found > em0: manual intervention required > em0: possible hardware address duplication deteted, disable IPv6 > > And subsequently, em0's nd6 has "IFDISABLED" in it. > > With wireshark, I see two ICMPv6 neighbor solicitations that are identical > --- is this the problem? > > How do I fix this? Did you copy this VM and have both copies running at once? If so, it assigned the same MAC address to each VM. VMware is suppose to detect this and ask if you "copied" or "moved" the VM, and if you say "copied" it will randomly assign a new MAC to the VM. If this didn't happen or if you said "moved" when you actually copied it, just go in and delete/re-create the network interface in the VM's settings to create a new MAC for it. If that's not the issue, we'd probably need more details about your configuration. smime.p7s Description: S/MIME cryptographic signature
