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 troc...@freebsd.org
To: bug-follo...@freebsd.org
Cc: Michael Gmelin free...@grem.de
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 troc...@freebsd.org
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
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.
___
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
pproca...@datapipe.comwrote:
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 eu...@grosbein.net 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=28943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC metric 0 mtu 1500 options=6c00bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6 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=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet 10Gbase-Twinax full-duplex 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: 1NIC 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
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 eu...@grosbein.net 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 zbee...@gmail.com wrote in CACpH0McSM7HDeJcQ1pLcXuEZ96n=15ymcap4yhezghbbyeg...@mail.gmail.com: 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 zbee...@gmail.com 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
