The following reply was made to PR kern/172683; it has been noted by GNATS.
From: Doug Hardie
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/172683: [ip6] Duplicate IPv6 Link Local Addresses
Date: Sun, 14 Oct 2012 16:42:50 -0700
Here is some more interesting information on the issue
I have a number of production servers that only have bge and I don't see that
listed in either category. None of them are running FreeBSD 12 yet as it has
not been released. Also there are some with rl. Those are add-on boards so
they could be changed, but would require extensive effort as th
I am trying to get sctp_sendmsgx to work and not having a lot of success. I
have not been able to find any examples on the web of using it. I have a
client using sctp_sendmsg working fine. I need to make use of the multihoming
feature which requires sctp_sendmsgx.I changed the call to sct
> I am trying to get sctp_sendmsgx to work and not having a lot of success. I
> have not been able to find any examples on the web of using it. I have a
> client using sctp_sendmsg working fine. I need to make use of the
> multihoming feature which requires sctp_sendmsgx.I changed the cal
>
>> On 9. Mar 2020, at 11:01, Doug Hardie wrote:
>>
>>> I am trying to get sctp_sendmsgx to work and not having a lot of success.
>>> I have not been able to find any examples on the web of using it. I have a
>>> client using sctp_sendms
> On 9 March 2020, at 04:11, Michael Tuexen
> wrote:
>
>> On 9. Mar 2020, at 11:55, Doug Hardie wrote:
>>
>>>
>>>> On 9. Mar 2020, at 11:01, Doug Hardie wrote:
>>>>
>>>>> I am trying to get sctp_sendmsgx to work and
> On 9 July 2020, at 08:13, Mark Johnston wrote:
>
> Hi,
>
> I spent some time working on making it possible to load the SCTP stack
> as a kernel module, the same as we do today with IPSec. There is one
> patch remaining to be committed before that can be done in head. One
> caveat is that the
> On 9 July 2020, at 13:10, Mark Johnston wrote:
>
> On Thu, Jul 09, 2020 at 12:44:25PM -0700, Doug Hardie wrote:
>>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>>
>>> Hi,
>>>
>>> I spent some time working on making it possible to l
> On 9 July 2020, at 14:45, Michael Tuexen wrote:
>
>> On 9. Jul 2020, at 23:15, Doug Hardie wrote:
>>
>> Actually, the users of these systems would have no clue about that message.
>> All they would figure out is that the system is down and they can't do
> On 9 July 2020, at 16:24, Mark Johnston wrote:
>
> On Thu, Jul 09, 2020 at 02:15:40PM -0700, Doug Hardie wrote:
>>> On 9 July 2020, at 13:10, Mark Johnston wrote:
>>> Hopefully "protocol not supported" is a sufficiently descriptive error
>>>
> On 10 July 2020, at 02:39, Michael Tuexen wrote:
>
> Hi Eugene,
>
> you are completely right. However, it requires that the program needs to run
> with root privileges just to be able to communicate.
> In the context of userland stack, this is one of the most important issues.
> In case of SCT
I was quite surprised to discover that the sockaddr structure returned from
recv_fd and recvfrom handle IPv4 addresses differently when using an INET6
socket. I don't know if this was intended, or a side effect. I started using
SCTP because of the need for accessing multi-homed servers. Some
> On 7 September 2020, at 13:57, Michael Tuexen
> wrote:
>
>> On 7. Sep 2020, at 22:48, Doug Hardie wrote:
>>
>> I was quite surprised to discover that the sockaddr structure returned from
>> recv_fd and recvfrom handle IPv4 addresses differently when using a
> On 7 September 2020, at 13:57, Michael Tuexen
> wrote:
>
> For UDP and TCP you always get IPv6 addresses on AF_INET6 sockets. If you are
> actually using IPv4, IPv4-mapped IPv6 addresses are used. For SCTP you an
> choose if you want IPv4-mapped IPv6 addresses or IPv4 address. It is
> con
> On 20 September 2020, at 16:20, Grzegorz Junka wrote:
>
> I have two WANs and a server with two interfaces, each interface reaching
> different WAN. The server is configured with two routing tables, fib0 and
> fib1, one per the corresponding interface.
>
> I would like sshd to listen on both
Are there any changes in the IPv6 configuration? I have multiple machines.
Some are still on 12.2 and one on 13.0. I have configured both as described in
the handbook for IPv6. The 13.0 machine can ping the router just fine and the
router shows in ndp:
Neighbor L
> On 14 February 2021, at 00:18, Doug Hardie wrote:
>
> Are there any changes in the IPv6 configuration? I have multiple machines.
> Some are still on 12.2 and one on 13.0. I have configured both as described
> in the handbook for IPv6. The 13.0 machine can ping the route
I don't know if this is a feature or a bug. On FreeBSD 9, the following ping
worked:
ping6 -s 5000 -b 6000 fe80::213:72ff:fec3:180f%dc0
It had to be stopped, but it returned the number of ping responses received
along with statistics.
With FreeBSD 12.2 and 13.0-BETA2, it returns 100% packet l
The last time I played with IPv6 (FreeBSD 9), DAD was activated when the
network was first configured. Once the interface came up, a neighbor
solicitation was sent with the link-local address to see if it duplicated
anywhere else. Trying that with FreeBSD 13.0-BETA2 it is quite different.
Bri
> On 19 February 2021, at 01:48, Michael Tuexen
> wrote:
>
>> On 19. Feb 2021, at 03:29, Doug Hardie wrote:
>>
>> I don't know if this is a feature or a bug. On FreeBSD 9, the following
>> ping worked:
>>
>> ping6 -s 5000 -b 6000 fe80::213
> On 19 February 2021, at 01:48, Michael Tuexen
> wrote:
>
>> On 19. Feb 2021, at 03:29, Doug Hardie wrote:
>>
>> I don't know if this is a feature or a bug. On FreeBSD 9, the following
>> ping worked:
>>
>> ping6 -s 5000 -b 6000 fe80::213
> On 20 February 2021, at 04:13, Kristof Provost wrote:
>
> If you don’t have scrub fragment reassemble set then you have to include
> something like pass log inet6 proto ipv6-frag all to pass fragmented packets
> (assuming you block by default).
>
> You really, really want scrub fragment re
>From the Handbook:
32.9.2. Configuring IPv6
To configure a FreeBSD system as an IPv6 client, add these two lines to rc.conf:
ifconfig_rl0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"
This does not work. I have in rc.conf:
ifconfig_bge0_ipv6="inet6 accept_rtadv"
ifconfig_ue0_ipv6="inet6 accep
> On 27 February 2021, at 04:37, Michael Gmelin wrote:
>
>
>
>> On 27. Feb 2021, at 08:21, Doug Hardie wrote:
>>
>> From the Handbook:
>>
>> 32.9.2. Configuring IPv6
>> To configure a FreeBSD system as an IPv6 client, add these two lines
> On Feb 27, 2021, at 11:06, Michael Gmelin wrote:
>
>
>
>> On 27. Feb 2021, at 19:40, Doug Hardie wrote:
>>
>>> On 27 February 2021, at 10:34, Michael Gmelin wrote:
>>>
>>>
>>>
>>>> On 27. Feb 2021, at 19:2
I have two systems on the same ethernet. One is configured as a router, the
other as a host. rtadvd is running on the router, rtsold on the host, and
route6d on both. The router was up and running and I initiated tcpdump of ip6
packets on the interface. Then I booted the host. The results a
> On 13 March 2021, at 17:03, Doug Hardie wrote:
>
> I have two systems on the same ethernet. One is configured as a router, the
> other as a host. rtadvd is running on the router, rtsold on the host, and
> route6d on both. The router was up and running and I initiated tc
>
> On 13 March 2021, at 17:03, Doug Hardie wrote:
>
> I have two systems on the same ethernet. One is configured as a router, the
> other as a host. rtadvd is running on the router, rtsold on the host, and
> route6d on both. The router was up and running and I initiated
-- Doug
> On 16 March 2021, at 03:54, Lutz Donnerhacke wrote:
>
> On Mon, Mar 15, 2021 at 05:29:55PM -0700, Doug Hardie wrote:
>> I reduced the configuration to the host settings:
>> ifconfig_bge0_ipv6="inet6 accept_rtadv"
>>
>> The router to:
>
I am trying to setup a FreeBSD 13.0 router for IPv6 and IPv4. The IPv4
addresses are all statically assigned. IPv6 should come from a prefix
delegation from "ISP" and then sub-deligated to local LANs and hosts. I have
tried numerous approaches from various postings but still have two issues:
I suspect this is an issue with the resolver, but it could also be in host. I
have the following in /etc/resolv.conf:
# Generated by resolvconf
nameserver fe80::213:72ff:fec3:180f%bge0
nameserver fe80::120c:6bff:fee9:cdf7%bge0
There is a DNS server running at the first address that supplies IPv
> On 20 April 2021, at 14:12, Doug Hardie wrote:
>
> I suspect this is an issue with the resolver, but it could also be in host.
> I have the following in /etc/resolv.conf:
>
> # Generated by resolvconf
> nameserver fe80::213:72ff:fec3:180f%bge0
> nameserver fe80::
Is there an effort under way to implement HomeNet: RFCs 7368 and 7788?
-- Doug
33 matches
Mail list logo
