Context: An aarch64 PkgBase kernel and world boot under Parallels
on macOS (M4 MAX):
FreeBSD 15.0-CURRENT main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035
. . .
vtnet0: link state changed to UP
Invoking IPv6 network device address event may sleep with the following
non-sleepable locks
n276258-c5773d366ecc GENERIC arm64 aarch64 1500035
> >
> > . . .
> > vtnet0: link state changed to UP
> > Invoking IPv6 network device address event may sleep with the following
> > non-sleepable locks held:
> > exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r
> On Apr 17, 2025, at 5:17 AM, Mark Millard wrote:
>
> Context: An aarch64 PkgBase kernel and world boot under Parallels
> on macOS (M4 MAX):
>
> FreeBSD 15.0-CURRENT main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035
>
> . . .
> vtnet0: link state changed to
On 4/9/25 12:51, Ronald Klop wrote:
Hi,
Next to hostuuid you could add a jailname in the mix.
That is what ether_gen_addr(9) does to make it easier to prevent
collisions while copying jails around or run a jail on a readonly shared
base filesystem.
The RFC is very clear on what should be us
On 4/9/25 13:10, Guido Falsi wrote:
On 4/9/25 12:51, Ronald Klop wrote:
Hi,
Next to hostuuid you could add a jailname in the mix.
That is what ether_gen_addr(9) does to make it easier to prevent
collisions while copying jails around or run a jail on a readonly
shared base filesystem.
The R
: Marek Zarychta , FreeBSD Current
, n...@freebsd.org
Onderwerp: Re: RFC: Implementation of RFC 7217 [A Method for Generating
Semantically Opaque Interface Identifiers, with IPv6 Stateless Address
Autoconfiguration (SLAAC)]
On 4/6/25 23:38, Marek Zarychta wrote:
> W dniu 6.04.2025 o 16:49, Gu
On 4/6/25 23:38, Marek Zarychta wrote:
W dniu 6.04.2025 o 16:49, Guido Falsi pisze:
Hi!
I have recently implemented and tested the patch at [1], which
implements RFC 7217, about generating IPv6 addresses that are constant
through reboots, but do not expose the MAC address of the machine, not
W dniu 6.04.2025 o 16:49, Guido Falsi pisze:
Hi!
I have recently implemented and tested the patch at [1], which
implements RFC 7217, about generating IPv6 addresses that are constant
through reboots, but do not expose the MAC address of the machine, not
being in any way derived by those
Hi!
I have recently implemented and tested the patch at [1], which
implements RFC 7217, about generating IPv6 addresses that are constant
through reboots, but do not expose the MAC address of the machine, not
being in any way derived by those.
I'd like to get comments, testing and r
Hi,
> On 23 Feb 2025, at 13:52, A FreeBSD User wrote:
>
> Am Fri, 21 Feb 2025 10:44:12 +
> Bob Bishop schrieb:
>
>> Hi,
>>
>>> On 21 Feb 2025, at 06:52, A FreeBSD User wrote:
>>>
>>> Hello,
>>>
>>> Linux (esp
Am Fri, 21 Feb 2025 10:44:12 +
Bob Bishop schrieb:
> Hi,
>
> > On 21 Feb 2025, at 06:52, A FreeBSD User wrote:
> >
> > Hello,
> >
> > Linux (especially OpenWRT we use) knows about a concept named "IPv6
> > tokenized interface
> > iden
specially OpenWRT we use) knows about a concept named "IPv6 tokenized
> interface
> identifier". The concept is self explanatory, a interface/router obtains a
> propagated prefix
> and the concept allows the explicit definition of the host portion.
>
> I haven't ma
Hi,
> On 21 Feb 2025, at 06:52, A FreeBSD User wrote:
>
> Hello,
>
> Linux (especially OpenWRT we use) knows about a concept named "IPv6 tokenized
> interface
> identifier". The concept is self explanatory, a interface/router obtains a
> propagated p
; Main Host has IPFW configured and is open for services like OpenLDAP on
> > UDP/TCP and ICMP
> > (ipfw is configured via rc.conf in this case, host is listening on both
> > protocol families
> > IPv4 and IPv6).
> >
> > The host itself has openldap-serv
> On Jan 9, 2024, at 6:24 PM, void wrote:
>
> On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
>>
>> Was the kernel/utility built with IPv6? If not, that’s a general bug which
>> should be filed (which can be easily checked/avoided using the FEATURES(9
> On Jan 9, 2024, at 7:17 AM, void wrote:
>
> On Tue, Jan 09, 2024 at 12:24:40PM +, void wrote:
>> On Tue, Jan 09, 2024 at 10:24:53AM +, void wrote:
>>> On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
>>>>
>>>> Was the
On Tue, Jan 09, 2024 at 12:24:40PM +, void wrote:
On Tue, Jan 09, 2024 at 10:24:53AM +, void wrote:
On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
Was the kernel/utility built with IPv6? If not, that’s a general
bug which should be filed (which can be easily checked
On Tue, Jan 09, 2024 at 10:24:53AM +, void wrote:
On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
Was the kernel/utility built with IPv6? If not, that’s a general bug
which should be filed (which can be easily checked/avoided using the
FEATURES(9) subsystem)…
Cheers!
-Enji
On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
Was the kernel/utility built with IPv6? If not, that’s a general
bug which should be filed (which can be easily checked/avoided
using the FEATURES(9) subsystem)…
Cheers!
-Enji
world/kernel was built with WITHOUT_INET6= in /etc
age: route [-j jail] [-46dnqtv] command [[modifiers] args]
> route: bad keyword: inet6
> route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args]
> route: bad keyword: inet6
> route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args]
> route: bad keyword: inet6
&
en for services like OpenLDAP on
> UDP/TCP and ICMP
> (ipfw is configured via rc.conf in this case, host is listening on both
> protocol families
> IPv4 and IPv6).
>
> The host itself has openldap-server 2.6 as a service. The host's interface is
> igb0 with
> as
host is listening on both
protocol families
IPv4 and IPv6).
The host itself has openldap-server 2.6 as a service. The host's interface is
igb0 with
assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces via
a bridge with
the same physical device as the host (igb0). Aft
l] [-46dnqtv] command [[modifiers] args]
route: bad keyword: inet6
route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args]
route: bad keyword: inet6
route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args]
Updating motd:.
Creating and/or trimming log files.
###
Why is it erroring for ipv6 when theres no ipv6 in rc.conf?
I've not tried an amd64 -current system yet.
--
Patrick M. Hausen:
> > Am 02.01.2024 um 13:56 schrieb Jan Bramkamp :
> > IPv6 enabled interfaces need a link-local address for normal
> > operation. Please set the auto-linklocal flag on the bridge and try
> > again.
>
> And remove the link-local address from alc0.
Hi all,
> Am 02.01.2024 um 13:56 schrieb Jan Bramkamp :
>
> IPv6 enabled interfaces need a link-local address for normal operation.
> Please set the auto-linklocal flag on the bridge and try again.
And remove the link-local address from alc0. A bridge member must not have
any layer
On 02.01.24 00:40, Lexi Winter wrote:
hello,
i'm having an issue with bridge(4) and IPv6, with a configuration which
is essentially identical to a working system running releng/14.0.
ifconfig:
lo0: flags=1008049 metric 0 mtu 16384
options=680003
inet 127.0.0.1 ne
Am 2024-01-02 00:40, schrieb Lexi Winter:
hello,
i'm having an issue with bridge(4) and IPv6, with a configuration which
is essentially identical to a working system running releng/14.0.
ifconfig:
lo0: flags=1008049 metric 0 mtu
16384
options=680003
inet 127.0.0.1 ne
hello,
i'm having an issue with bridge(4) and IPv6, with a configuration which
is essentially identical to a working system running releng/14.0.
ifconfig:
lo0: flags=1008049 metric 0 mtu 16384
options=680003
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixle
e0), the hosts's interface
> igb0 (I350-T2 two
> port Gigabit Network Connection ) is member of that bridge and so a couple of
> epair(4) devices
> belonging to a couple of jails.
>
> On epairs as well as on the main hosts igb0 NIC, both IPv4 and IPv6 are
> configured, IPv6 u
her.arp.log_level: 6
net.link.ether.ipfw: 0
On epairs as well as on the main hosts igb0 NIC, both IPv4 and IPv6 are
configured, IPv6 uses
ULA and setup doesn't has anything fancy.
Pinging and connecting to hosts "outside" the box of the host in question (all
FreeBSD
CURRENT/14-STABLE) is pos
Hello all!
After one year I was in need to use ipv6 on wireless and everything is
working ok.
I'm running 15-CURRENT:
---
wlans_iwlwifi0="wlan0"
create_args_wlan0="wlanmode sta regdomain ETSI country PT"
ifconfig_wlan0_ipv6="inet6 accept_rtadv"
ifconfig_wlan
Am Sun, 19 Feb 2023 13:30:13 +0300
"Andrey V. Elsukov" schrieb:
> 18.02.2023 18:42, FreeBSD User пишет:
> > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN
> > interface. We use NPTv6 to translate ULA addresses for the inner
> > IPv6 networks.
18.02.2023 18:42, FreeBSD User пишет:
On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN
interface. We use NPTv6 to translate ULA addresses for the inner
IPv6 networks. We use IPv6 privacy on the tun0 interface. The
router/firewall is operating after a reboot or restart of mpd5
Hello,
running a small nanoBSD firewall/router appliance, the WAN interface (tun0) is
confugred via
SLAAC when it comes to IPv6. The allpliance is running in-kernel compiled IPFW.
The OS is
FreeBSD 13-STABLE, compiled on a recuurant weekly basis.
On a 24 hour basis, the ISP changes the IPv4
tested your config:
> ---
> wlans_iwlwifi0="wlan0"
> create_args_wlan0="wlanmode sta regdomain ETSI country PT"
> ifconfig_wlan0_ipv6="inet6 accept_rtadv"
> ifconfig_wlan0="WPA DHCP"
> rtsold_enable="YES"
> ---
> and no carrier.
e have to wait a little more and see if people that use ifwwifi
driver do some tests on ipv6.
Thanks,
Shawn Webb escreveu no dia sábado, 13/08/2022
à(s) 21:21:
> On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teixeira wrote:
> > Hello,
> >
> > Due to ISP changes I was
On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teixeira wrote:
> Hello,
>
> Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can
> have a funcional internet.
>
> Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
> ---
> wlans_iwlwifi
Hi,
Without "ifconfig_re0=“DHCP" re0 assumes only an ipv6 address and looses
internal 192.168.1.xxx ipv4 address.
No connection to internet.
I've used ifconfig_wlan0="WPA" instead of ifconfig_wlan0="WPA SYNCDHCP" and
no carrier.
Bob Bishop escreveu no dia s
Hi,
> On 12 Aug 2022, at 13:00, Nuno Teixeira wrote:
>
> Hi Merek,
>
>> If you are connecting to IPv6 only WLAN than you can probably either
>> disable DHCP (if the RDNSS is provided for this network):
>> ifconfig_wlan0="WPA up"
>> or install dhc
Hi Merek,
If you are connecting to IPv6 only WLAN than you can probably either
> disable DHCP (if the RDNSS is provided for this network):
> ifconfig_wlan0="WPA up"
> or install dhcp client capable of acquiring DHCPv6 lease and use it
> instead of standard dhclient(8) from
W dniu 11.08.2022 o 17:53, Nuno Teixeira pisze:
Hello Bjoern!
/etc/rc.conf:
---
wlans_iwlwifi0="wlan0"
create_args_wlan0="wlanmode sta regdomain ETSI country PT"
ifconfig_wlan0_ipv6="inet6 accept_rtadv"
ifconfig_wlan0="WPA SYNCDHCP"
rtsold_enable="
wer 30 bmiss 7 scanvalid 60 protmode CTS wme
roaming MANUAL bintval 0
parent interface: iwlwifi0
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
nd6 options=23
---
(a) this is unlikely related to IPv6? The only thing that wou
On Sun, 7 Aug 2022, Nuno Teixeira wrote:
Hi,
Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can
have a funcional internet.
Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
---
wlans_iwlwifi0="wlan0"
create_args_wlan0="wlanmode sta regdo
Hello,
Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can
have a funcional internet.
Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
---
wlans_iwlwifi0="wlan0"
create_args_wlan0="wlanmode sta regdomain ETSI country PT"
ifconfig_wlan0
On 03.05.22 19:08, Gleb Smirnoff wrote:
On Sun, Apr 24, 2022 at 09:49:48AM +0200, Florian Smeets wrote:
F> On 23.04.22 01:38, Gleb Smirnoff wrote:
F> >Hi Florian,
F> >
F> > here is a patch that should help with the IPv6 problem. I'm not
F> > yet committing
On Sun, Apr 24, 2022 at 09:49:48AM +0200, Florian Smeets wrote:
F> On 23.04.22 01:38, Gleb Smirnoff wrote:
F> >Hi Florian,
F> >
F> > here is a patch that should help with the IPv6 problem. I'm not
F> > yet committing it, it might be not final.
F>
F> ye
On 23.04.22 01:38, Gleb Smirnoff wrote:
Hi Florian,
here is a patch that should help with the IPv6 problem. I'm not
yet committing it, it might be not final.
Hi Gleb,
yes, the patch resolves the issue. There is just one SYN packet, and it
gets a reply immediately.
Thanks,
Fl
> On 23. Apr 2022, at 02:24, Gleb Smirnoff wrote:
>
> Michael,
>
> On Sat, Apr 23, 2022 at 01:54:25AM +0200, Michael Tuexen wrote:
> M> > here is a patch that should help with the IPv6 problem. I'm not
> M> > yet committing it, it might be not final.
>
> On 23. Apr 2022, at 01:38, Gleb Smirnoff wrote:
>
> Hi Florian,
>
> here is a patch that should help with the IPv6 problem. I'm not
> yet committing it, it might be not final.
Hi Gleb,
when I was looking at the code, I was also wondering if it would make
more se
Michael,
On Sat, Apr 23, 2022 at 01:54:25AM +0200, Michael Tuexen wrote:
M> > here is a patch that should help with the IPv6 problem. I'm not
M> > yet committing it, it might be not final.
M>
M> when I was looking at the code, I was also wondering if it would make
M&g
On Sat, Apr 16, 2022 at 09:19:57AM -0400, Michael Butler wrote:
M> > Michael, can you please confirm or decline that you see the packets
M> > that are dropped when you tcpdump on lo0?
M>
M> All the jails are aliased to share a single bridge interface. That
M> results in the route to each jail bei
Hi Florian,
here is a patch that should help with the IPv6 problem. I'm not
yet committing it, it might be not final.
--
Gleb Smirnoff
diff --git a/sys/netinet6/ip6_input.c b/sys/netinet6/ip6_input.c
index 3a13d2a9dc7..625de6d3657 100644
--- a/sys/netinet6/ip6_input.c
+++ b/sys/net
On 4/16/22 01:22, Gleb Smirnoff wrote:
Hi Florian, Hi Michael,
On Fri, Apr 15, 2022 at 06:11:13PM -0400, Michael Butler wrote:
M> >> I can reproduce this locally, will try to figure out what is going on.
M> >> If you can bisect it, it would be great.
M> >
M> > Found the culprit 1817be481b8703
On 16.04.22 07:22, Gleb Smirnoff wrote:
Hi Florian, Hi Michael,
Hi Gleb,
thanks for looking into it.
On Fri, Apr 15, 2022 at 06:11:13PM -0400, Michael Butler wrote:
M> >
M> > Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed
M> > toggling net.inet6.ip6.source_address
Hi Florian, Hi Michael,
On Fri, Apr 15, 2022 at 06:11:13PM -0400, Michael Butler wrote:
M> >> I can reproduce this locally, will try to figure out what is going on.
M> >> If you can bisect it, it would be great.
M> >
M> > Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed
> On 16. Apr 2022, at 00:05, tue...@freebsd.org wrote:
>
>> On 15. Apr 2022, at 23:39, Florian Smeets wrote:
>>
>> On 15.04.22 21:24, tue...@freebsd.org wrote:
>>>> On 15. Apr 2022, at 20:20, Florian Smeets wrote:
>>>>
>>>>
>&g
On 4/15/22 17:39, Florian Smeets wrote:
On 15.04.22 21:24, tue...@freebsd.org wrote:
On 15. Apr 2022, at 20:20, Florian Smeets wrote:
Hi,
there seems to be an issue with local IPv6 TCP connections on main. I
have been seeing this for a couple of months at least. pkg upgr on my
webserver
> On 15. Apr 2022, at 23:39, Florian Smeets wrote:
>
> On 15.04.22 21:24, tue...@freebsd.org wrote:
>>> On 15. Apr 2022, at 20:20, Florian Smeets wrote:
>>>
>>>
>>> Hi,
>>>
>>> there seems to be an issue with local IPv6 TCP co
On 15.04.22 21:24, tue...@freebsd.org wrote:
On 15. Apr 2022, at 20:20, Florian Smeets wrote:
Hi,
there seems to be an issue with local IPv6 TCP connections on main. I have been
seeing this for a couple of months at least. pkg upgr on my webserver hosting
the pkg repo is very slow, all
> On 15. Apr 2022, at 20:20, Florian Smeets wrote:
>
> [bcc to net@ for wider exposure]
>
> Hi,
>
> there seems to be an issue with local IPv6 TCP connections on main. I have
> been seeing this for a couple of months at least. pkg upgr on my webserver
> hosting the
[bcc to net@ for wider exposure]
Hi,
there seems to be an issue with local IPv6 TCP connections on main. I
have been seeing this for a couple of months at least. pkg upgr on my
webserver hosting the pkg repo is very slow, all other hosts can connect
to the pkg repo just fine. So IPv6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
running a small homebrewn FreeBSD 13-STABLE based router/ipfw applance on an
APU2C4. WAN
interface is tun0 (physically attached to igb0, connected with a modem), opened
via ppp
(PPPoE).
Situation:
On IPv6 subnets (ULAs, fc50:baff::, fc50
cket sizes if you disable it with "ifconfig vtnet0
> > -tso6"? Does it actually fix your IPv6 issue?
--
Lars Schotte
Mudroňova 13
92101 Piešťany
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinf
, 2021-03-08 at 17:22 -0500, Ryan Stone wrote:
> Hi Lars,
>
> Do you see the TSO6 option enabled on your vtnet interface? Do you
> see normal packet sizes if you disable it with "ifconfig vtnet0
> -tso6"? Does it actually fix your IPv6 issue?
--
Lars Schotte
Mu
Hi Lars,
Do you see the TSO6 option enabled on your vtnet interface? Do you
see normal packet sizes if you disable it with "ifconfig vtnet0
-tso6"? Does it actually fix your IPv6 issue?
___
freebsd-current@freebsd.org mailing
It looks like vtnet driver ignored MTU setting on 13.0-RC1.
I see this on both, IPv4 and IPv6 ... however IPv4 works maybe because
DigitalOcean and Vultr do split those frames on KVM virt host, but
don't do this for IPv6 (I suppose).
Everything about this is strange but so far I have been
Hey friends,
I am running this FreeBSD 13.0-RC1 and I am experiencing strange
Ethernet frame sizes, TCP sizes well above 2500 on an MTU of 1500.
Somehow it seems that this problem only applies on IPv6,
IPv4 works fine.
I have seen some strange network behaviour with TCP connections
randomly
Hi,
On 25/11/20 1:12 pm, Alexander V. Chernikov wrote:
21.11.2020, 22:48, "Guy Yur" :
Hi,
When adding a route with a netmask, add_route() in route_ctl.c
adds the route with destination address masked.
If the add failed (for example, the route exists) it calls
lookup_prefix() with the original
21.11.2020, 22:48, "Guy Yur" :
> Hi,
>
> When adding a route with a netmask, add_route() in route_ctl.c
> adds the route with destination address masked.
> If the add failed (for example, the route exists) it calls
> lookup_prefix() with the original unmasked destination.
Thank you for the report!
Hi,
When adding a route with a netmask, add_route() in route_ctl.c
adds the route with destination address masked.
If the add failed (for example, the route exists) it calls
lookup_prefix() with the original unmasked destination.
In a scenario where a loopback route was added followed
by the net
Hi,
> On Thu, 31 Jan 2019 08:24:38 +0100
> "O. Hartmann" said:
ohartmann> validate: dgram from IP ffdff:dead:beef::, port 514, name \
ohartmann> fdff:dead:beef::;
ohartmann> rejected in rule 1 due to IP mismatch.
The -a option was broken. It should be fixed now.
Please, try
Hi,
> On Thu, 31 Jan 2019 08:24:38 +0100
> "O. Hartmann" said:
ohartmann> validate: dgram from IP ffdff:dead:beef::, port 514, name \
ohartmann> fdff:dead:beef::;
ohartmann> rejected in rule 1 due to IP mismatch.
The -a option was broken. It should be fixed now.
Please try i
Hi,
> On Thu, 31 Jan 2019 08:24:38 +0100
> "O. Hartmann" said:
ohartmann> validate: dgram from IP ffdff:dead:beef::, port 514, name \
ohartmann> fdff:dead:beef::;
ohartmann> rejected in rule 1 due to IP mismatch.
The -a option was broken. It should be fixed now.
Please try i
On 12/02/19 11:03, Shawn Webb wrote:
> Hey all,
>
> I have net.inet6.ip6.use_tempaddr and net.inet6.ip6.prefer_tempaddr
> both set to 1. Yet, I'm not seeing temporary addresses created upon
> receipt of a router advertisement. I'm only seeing the HostID-based
> SLAAC IP be generated. Has something
On Tue, Feb 12, 2019 at 11:44:42AM -0200, Renato Botelho wrote:
> On 12/02/19 11:03, Shawn Webb wrote:
> > Hey all,
> >
> > I have net.inet6.ip6.use_tempaddr and net.inet6.ip6.prefer_tempaddr
> > both set to 1. Yet, I'm not seeing temporary addresses created upon
> > receipt of a router advertisem
Hey all,
I have net.inet6.ip6.use_tempaddr and net.inet6.ip6.prefer_tempaddr
both set to 1. Yet, I'm not seeing temporary addresses created upon
receipt of a router advertisement. I'm only seeing the HostID-based
SLAAC IP be generated. Has something changed recently that would
prevent RFC3041 from
On Tue, 29 Jan 2019 11:36:37 +0300
"Andrey V. Elsukov" wrote:
> On 28.01.2019 15:44, O. Hartmann wrote:
> > Stopping all jails, destroying all epairs and bridge0 doesn't change
> > anything. The problems occured when IPv6 came into play on the specific
> > ho
rio:
The server has IPv6 fdff:dead:beef::faaf and IP 192.168.168.200.
The test client has IPv6 fdff:dead:beef:: and IP 192.168.168.2.
On the syslog server:
The syslog server's syslogd is configured as (etc/rc.conf):
syslogd -C -v -v -b [fdff:dead:beef::faaf]:514 -b 192.168.168.200:514 \
On 28.01.2019 15:44, O. Hartmann wrote:
> Stopping all jails, destroying all epairs and bridge0 doesn't change anything.
> The problems occured when IPv6 came into play on the specific host in
> question.
>
> Does anyone have any ideas? I'm out of ideas.
Hi,
I think
On 28.01.2019 15:44, O. Hartmann wrote:
> Stopping all jails, destroying all epairs and bridge0 doesn't change anything.
>
> The problems occured when IPv6 came into play on the specific host in
> question.
>
> Does anyone have any ideas? I'm out of ideas.
Sinc
On 28 Jan 2019, at 12:44, O. Hartmann wrote:
I ran into severe problems on CURRENT ( FreeBSD 13.0-CURRENT #193
r343521: Mon Jan 28 10:26:36 CET 2019 amd64), VIMAGE enabled host with
jails
utilizing IPv6.
and you forget to mention in the subject that it seems to be an ipfw
problem and thus
I ran into severe problems on CURRENT ( FreeBSD 13.0-CURRENT #193
r343521: Mon Jan 28 10:26:36 CET 2019 amd64), VIMAGE enabled host with jails
utilizing IPv6.
Scenario:
The main host has two Braodcom (bce0|1) NICs. bce0 is the physical NIC attached
to a routed/switched network for the main host
> On 3 Dec 2018, at 08:15, O. Hartmann wrote:
>
>
> The documentation lacks in many aspects how to deal with IPv6, especially
> when it comes
> to "well known things from the old IPv4 world". Since DDNS also is still
> something people
> use with IP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Fri, 30 Nov 2018 14:32:52 +
Gary Palmer schrieb:
> On Fri, Nov 30, 2018 at 01:12:32PM +0100, O. Hartmann wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > My ISP is offering IPv6 only "a
> >
> >> As far as I know, with the IPv4 stack a IPv4 address is obtained
> >> automatically, so I would expect the same for IPv6.
> >
> > The fun with "automatically" is that there's more than one way...
> > DHCPv6 and NDP (IPV6 Neigh
, but
they are, in fact, statically assigned. In radius we assign IPv6
addresses. On the servers, we run this ifaceup script:
#!/bin/bash
#
# Add a route to the interface, if appropriate.
PATH=/sbin:/usr/local/bin:$PATH
date=`date`
interface="$1"
authname="$5"
route=`psql -t
## Bjoern A. Zeeb (bzeeb-li...@lists.zabbadoz.net):
> No, IPV6CP, to my very best 15 year old memory only negotiates the
> interface identifiers, which are used to generate the link-local addresses.
Ah, you're right - it's IPV6CP-then-NDP, not "IPV6CP or NDP".
I got ahead of the protocol...
Rega
On 11/30/2018 7:12 AM, O. Hartmann wrote:
>
> For IPv6, I only see my local linklocal address, fe80::...
>
> Checking the log of ppp (/var/log/ppp.log), there is also a fe80::
> linklocal address
> assigned to the variable HISADDR. Somehow, the tun0 never obtains a
> IPv6 ap
On 30 Nov 2018, at 15:59, Christoph Moench-Tegeder wrote:
> ## O. Hartmann (ohartm...@walstatt.org):
>
>> As far as I know, with the IPv4 stack a IPv4 address is obtained
>> automatically, so I would expect the same for IPv6.
>
> The fun with "automatically"
## O. Hartmann (ohartm...@walstatt.org):
> As far as I know, with the IPv4 stack a IPv4 address is obtained
> automatically, so I would expect the same for IPv6.
The fun with "automatically" is that there's more than one way...
DHCPv6 and NDP (IPV6 Neighbour Disc
On Fri, Nov 30, 2018 at 01:12:32PM +0100, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> My ISP is offering IPv6 only "as an experimental feature", so I had to ask to
> enable the
> IPv6 stack on my connection. I'm using FreeBSD 12-S
Hi,
> On 30 Nov 2018, at 12:12, O. Hartmann wrote:
>
> Signed PGP part
> My ISP is offering IPv6 only "as an experimental feature", so I had to ask to
> enable the
> IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis for a
> router/firewa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
My ISP is offering IPv6 only "as an experimental feature", so I had to ask to
enable the
IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis for a
router/firewall/PBX system, FreeBSD's onboard ppp client is pe
On 23 Sep 2018, at 22:10, David P. Discher wrote:
I say yes, especially if we wish to support a IPv6 only system at some
point in the future … which seemed to be a “think” of the few
major IPv6 advocates in the industry.
I guess best practice, this should suck in rc.* config files, and use
I say yes, especially if we wish to support a IPv6 only system at some point in
the future … which seemed to be a “think” of the few major IPv6 advocates in
the industry.
I guess best practice, this should suck in rc.* config files, and use v6 if v6
is set via one of the ipv6_* variables
Does it make sense to add an IPv6 localhost (::1) to our setup scripts
for local_unbound? unbound is definitely listening on ::1 as well at
127.0.0.1 so things like "host -6" will work if we add it like this perhaps?
--- /usr/sbin/local-unbound-setup 2018-09-20 21:47:41.0
Hi!
> As Rick told me there's a ongoing debate on this, here's a copy
> from my mail to stable@:
PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231050
--
p...@freebsd.org +49 171 3101372 2 years to go !
___
freebsd-current@
Hi!
As Rick told me there's a ongoing debate on this, here's a copy
from my mail to stable@:
I've seen a strange effect: NFS via IPv6 between 11.2-REL amd64
boxes failed for directories with more than 45 files or directories.
Small directories worked. It seems to be an
On 15.08.2018 23:47, Lars Schotte wrote:
> Hey folks,
>
> when you create a gif with IPv6 tunnel endpoints
> tcpdump on the underlying interface will show you some kind of error
> that 0 != 6 and packets will be dropped.
>
> IP6 version error: 0 != 6
> repeating for eac
Hey folks,
when you create a gif with IPv6 tunnel endpoints
tcpdump on the underlying interface will show you some kind of error
that 0 != 6 and packets will be dropped.
IP6 version error: 0 != 6
repeating for each packet.
happens only while sending. receiving works.
This happens only on 12
1 - 100 of 503 matches
Mail list logo
