On Wed, Oct 09, 2019 at 08:13:39PM -0700, Jeremy Chadwick wrote:
> > Now we can get back on the ipv6 option.
> >
> > so if we want to proceed further in removing the option to build with or
> > without
> > ipv6 for the ports side. Please speak up in reply to this
> Now we can get back on the ipv6 option.
>
> so if we want to proceed further in removing the option to build with or
> without
> ipv6 for the ports side. Please speak up in reply to this email, if you are
> building without ipv6, why are you doing so, what are the real ben
Hi!
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 issue with
ipv6 fragmentation (?), as can be seen by tcpdump:
17:54:16.855978 IP6 nfs-serv > nfs-client
The routes are not affected. the strangest thing I find that the host
and jails are accessible from outside, and it can reach outside hosts
via v6, but everything that's staying on the server fails.
Alan Somers wrote:
> How did you assign the jails' IPv6 addresses in the first plac
How did you assign the jails' IPv6 addresses in the first place? The usual
way is to assign them as /128 aliases, in which case the command to remove
them would include a "/128", not "/48". I think when you're deleting a
"/48" you're also removing s
On a older server running FreeBSD 10.2 i have a number of jails. For
migration to FreeBSD I'm planning to shutdown the jail, move the data to
the new server and spin up the jail there. IP addresses are alse moved.
When I remove an IPv6 address with the following command 'ifconfig
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654
--- Comment #2 from Eugene Grosbein ---
Created attachment 192690
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192690&action=edit
debugging patch for single user only
Forgot to note that my kernel has VIMAGE too.
I've reprodu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654
--- Comment #1 from Eugene Grosbein ---
$ addr2line -e kernel.debug -i -f -C 806fe6ac
ether_output_frame
/data2/src/sys/net/if_ethersubr.c:449
ether_output
/data2/src/sys/net/if_ethersubr.c:435
(kgdb) l /data2/src/sys/net/if_ethe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654
Bug ID: 227654
Summary: [panic] repeatable crash with IPv6+lagg+vlan+em
Product: Base System
Version: 11.1-STABLE
Hardware: Any
OS: Any
Status: New
="mgmt0"
ifconfig_inet0="up addm vlan7"
ifconfig_inet0_alias0="inet /24"
ifconfig_inet0_ipv6="inet6 /64 auto_linklocal"
ifconfig_mgmt0="up addm vlan11"
ifconfig_mgmt0_alias0="inet /16"
ifconfig_mgmt0_ipv6="inet6 auto_linklocal"
defau
:6bf8%em1, icmp_seq=2 hlim=64 time=0.086 ms
16 bytes from fe80::222:4dff:fe9d:e093%em1, icmp_seq=2 hlim=64 time=0.713
ms(DUP!)
...
BTW, when I add address and default route by hands, everything starts to
work. So, this NIC doesn't have problems with IPv6 per se! Looks like some
weird configu
g em0 with simple config:
le>
le> ifconfig_em0="inet 192.168.134.2 netmask 255.255.255.0 mtu 9000"
le> ifconfig_em0_ipv6="inet6 accept_rtadv"
le>
le> everything works fine - em0 get IPv6 prefix from rtadvd of my router
le> and "tspdump -n -i em0 icmp6" shows so
"
everything works fine - em0 get IPv6 prefix from rtadvd of my router
and "tspdump -n -i em0 icmp6" shows some traffic, like router and prefix
announcements. So far so good.
I want to use em1 (and don't use em0 at all), because 82579LM has some
known bugs according to Sup
looking at netstat I see 300+ connections on this service in a “CLOSED”
state… All of the connections are via IPv6.
Sockstat shows all of these connections not related to a user, command, pid,
etc…. If I restart the process, all of the connections are freed and things
work as expected for a
On Sat, Apr 04, 2015 at 10:02:04AM +0200, Marten wrote:
> Hi all,
>
> fyi:
> pkg does not honor -4 or such config /usr/local/etc/pkg.conf
> http://vuxml.freebsd.org/freebsd/vuln.xml.bz2
> <http://vuxml.freebsd.org/freebsd/vuln.xml.bz2> is not reachable over ipv6
>
Hi all,
fyi:
pkg does not honor -4 or such config /usr/local/etc/pkg.conf
http://vuxml.freebsd.org/freebsd/vuln.xml.bz2
<http://vuxml.freebsd.org/freebsd/vuln.xml.bz2> is not reachable over ipv6
adding ipv4 addresses in /etc/hosts are a workaround
data below,
kind regards,
Marten
on th
Hi all,
fyi:
pkg does not honor -4 or such config /usr/local/etc/pkg.conf
http://vuxml.freebsd.org/freebsd/vuln.xml.bz2
<http://vuxml.freebsd.org/freebsd/vuln.xml.bz2> is not reachable over ipv6
adding ipv4 addresses in /etc/hosts are a workaround
data below,
kind regards,
Marten
on th
Hi all,
While bootstrapping pkg a fresh jail on FreeBSD 10.1 with IPv6 enabled the
process stalls.
#uname -a
FreeBSD node.vijn.org 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0: Tue Jan 27
08:55:07 UTC 2015
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
-> /
Hi all,
When I add an IPv6 manually on an interface vlan, I get a message
duplicated IP.
# ifconfig vlan2 inet6 2804:1054:0:2::1/64
dmesg message:
==
lagg1: IPv6 addresses on em2 have been removed before adding it as a
member to prevent IPv6 address scope violation.
lagg1: IPv6
/068987.html
> > http://lists.freebsd.org/pipermail/freebsd-stable/2012-August/069043.html
> >
> > I'm running stable/9 r255017 and I'm seeing the same issue, even with
> > the fix Bjoern committed in r238876.
>
> This is still with "modulate state" in some rules t
9043.html
>
> I'm running stable/9 r255017 and I'm seeing the same issue, even with
> the fix Bjoern committed in r238876.
This is still with "modulate state" in some rules that also hit ipv6 traffic ?
It almost looks like doing this kind of traffic alteration is conside
n with
the fix Bjoern committed in r238876.
My setup is a dual stack one (IPv6 is done through an IPv4 tunnel) and
the problem is only with IPv6. I have jails with both IPv4 and IPv6
addresses, and I use pf to rdr certain ports to certain jails. With IPv6
I'm seeing failed checksums on the
my case, it was after ~3
hours. And ports numbers are exactly the same as in the state table
entry from some hours before. So the state table entry seems to got lost!
My question:
Is such a problem known?
Did I miss enything else?
System runs 8.1-STABLE/x86
Another issue was that "no-rout
l 25090 root 4u IPv4 0xfe01e810f3d0 0t0 TCP *:25
>>> (LISTEN)
>>> sendmail 25090 root 5u IPv6 0xfe01a988f000 0t0 TCP *:25
>>> (LISTEN)
>>> sendmail 25090 root 6u IPv4 0xfe011c53d000 0t0 TCP *:587
>>> (LISTEN)
>
:*
root sendmail 3081 7 tcp6 *:587 *:*
You need the following lines in your `hostname`.mc:
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Name=IPv4, Family=inet')dnl
DAEMON_OPTIONS(`Name=IPv6, Family=inet6')dnl
DAEMON_OPTIONS(`Port=587, Name=MSA-IPv4, M=Ea, Family=inet')dnl
On 19.04.13 16:00, Jeremy Chadwick wrote:
>> Hi all,
>>
>> I did not recognize that 587 is only listening onIy on IPv4. Maybe it's
>> new, maybe it was alltime so.
>>
>> sendmail 25090 root 4u IPv4 0xfe01e810f3d0 0t0 TCP *:25
>>
P *:25 (LISTEN)
> sendmail 25090root5u IPv6 0xfe01a988f000 0t0
> TCP *:25 (LISTEN)
> sendmail 25090root6u IPv4 0xfe011c53d000 0t0
> TCP *:587 (LISTEN)
>
> FreeBSD 9.1-STABLE #8 r248707
>
> freebsd.submit.mc states:
>
> d
Hi all,
I did not recognize that 587 is only listening onIy on IPv4. Maybe it's
new, maybe it was alltime so.
sendmail 25090root4u IPv4 0xfe01e810f3d0 0t0
TCP *:25 (LISTEN)
sendmail 25090root 5u IPv6 0xfe01a988f000 0t0
TCP *:25 (LISTEN)
sen
With
Ipv6_enable="YES"
In my rc.conf
Same behavior.
:(
-Original Message-
From: alexey [mailto:co...@rambler.ru]
Sent: Tuesday, March 12, 2013 12:22 PM
To: Bogdan Turcanu
Cc: 'Kurt Jaeger'; freebsd-stable@freebsd.org
Subject: Re: 9.1-Stable rc.conf ifconfig IPv
Dear Bogdan.
Try:
ipv6_enable="YES"
in rc.conf first.
> It is not working even I put lo0 instead of alc0.
> -Original Message-
> From: Kurt Jaeger [mailto:p...@opsec.eu]
> Sent: Tuesday, March 12, 2013 12:07 PM
> To: Bogdan Turcanu
> Subject: Re: 9.1-
Hi!
> Try:
>
> ipv6_enable="YES"
>
> in rc.conf first.
>
> > It is not working even I put lo0 instead of alc0.
On my laptop with alc0 I have 9.0 i386 FreeBSD, and no ipv6_enable.
It still worked ?
--
p...@opsec.eu+49 171 3101372 7 years to go !
___
It is not working even I put lo0 instead of alc0.
-Original Message-
From: Kurt Jaeger [mailto:p...@opsec.eu]
Sent: Tuesday, March 12, 2013 12:07 PM
To: Bogdan Turcanu
Subject: Re: 9.1-Stable rc.conf ifconfig IPv6
Hi!
> hostname="master.bogdanturcanu.ro"
> ifc
11:07 AM
To: Bogdan Turcanu
Subject: Re: 9.1-Stable rc.conf ifconfig IPv6
Hi!
> Same.
Can you show me the exact line in /etc/rc.conf ?
--
p...@opsec.eu+49 171 3101372 7 years to go
!
smime.p7s
Description: S/MIME cryptographic signature
)
status: active
No error in /var/log/messages.
-Original Message-
From: Kurt Jaeger [mailto:p...@opsec.eu]
Sent: Tuesday, March 12, 2013 10:26 AM
To: Bogdan Turcanu
Subject: Re: 9.1-Stable rc.conf ifconfig IPv6
Hi!
> ifconfig_alc0_ipv6="inet6 x:x:x: prefixlen
x:x:x:x prefixlen 64
it's working.
But, if I put in my rc.conf:
ifconfig_alc0_ipv6="inet6 x:x:x: prefixlen 64"
nothing happen. After reboot I have no ipv6 address on alc0, only Ipv4.
Any clue?
smime.p7s
Description: S/MIME cryptographic signature
At 5PM -0500 on 15/01/13 you (Shawn Webb) wrote:
>
> I figured it out. In my jail initialization scripts, I'm running '/bin/sh
> /bin/rc' after doing initial network setup. The rc script puts the
> interface in IFDISABLED mode. So if I run the ifconfig command to remove
> the flag, I'm golden.
Y
>> > least set a timeout for DAD.
>>
>> DAD already has a timeout: it succeeds iff no packets indicating someone
>> else is using the address are received in a given time. The only reason
>> for an address remaining tentative indefinitely (without transi
0:8142:1::5 prefixlen 64 tentative
> > > > inet6 fe80::80:3ff:fe00:140b%epair0b prefixlen 64 tentative scopeid
> 0x2
> > > > inet 10.7.1.92 netmask 0xfe00 broadcast 10.7.1.255
> > > > nd6 options=29
> > >
> > > I suspect the addresses are
her 02:80:03:00:14:0b
> > > inet6 2001:470:8142:1::5 prefixlen 64 tentative
> > > inet6 fe80::80:3ff:fe00:140b%epair0b prefixlen 64 tentative scopeid 0x2
> > > inet 10.7.1.92 netmask 0xfe00 broadcast 10.7.1.255
> > > nd6 options=29
> >
> > I susp
On Tue, Jan 15, 2013 at 12:29 AM, Ben Morrow wrote:
> Quoth Shawn Webb :
> >
> > I've been working on sharing a 6in4 IPv6 tunnel (via a gif device) I have
> > with Hurricane Electric (tunnelbroker.net) to my jails via epair
> devices.
> > My setup is a bi
Quoth Shawn Webb :
>
> I've been working on sharing a 6in4 IPv6 tunnel (via a gif device) I have
> with Hurricane Electric (tunnelbroker.net) to my jails via epair devices.
> My setup is a bit unique in that the IPv6 tunnel is behind an OpenVPN
> connection. I've had vary
Hey All,
I've been working on sharing a 6in4 IPv6 tunnel (via a gif device) I have
with Hurricane Electric (tunnelbroker.net) to my jails via epair devices.
My setup is a bit unique in that the IPv6 tunnel is behind an OpenVPN
connection. I've had varying degrees of success. I might hav
fixlen 64 scopeid 0xd
uqs> inet6 2a02:2528:ff00:1b::2 --> 2a02:2528:ff00:1b::1 prefixlen 128
uqs> nd6 options=21
uqs> Opened by PID 82756
uqs> and I'd like to have ipv6 connection originating from this host use
uqs> 2a02:2528:ff0d::1%em0 instead
ame and the addresses returned from
ben> gethostbyname2(AF_INET6) ought to be sorted according to ip6addrctl,
ben> even if getipnodebyname special-cases the v4-mapped addresses to appear
ben> last.
Okay, it seems reasonable. I've just committed to obey ip6addrctl
only for IPv6 address:
e point binding separate v4
> and v6 sockets if the v6 socket is just going to end up bound to a
> v4-mapped address.
Mapped addresses are for dual stack hosts and sockets with IPV6_ONLY
turned off. They work much better when the IPv4 side of the stack
has been upgraded to support all of th
ays 'A query is first
> ben> made for records and if successful, the IPv6 addresses are
> ben> returned. Another query is then made for A records and any found are
> ben> returned as IPv4-mapped IPv6 addresses.'. I don't believe that is meant
> ben> to ind
he hint!
> > > >
> > > > I think this just hides the problem. If gshapiro@'s explanation is
> > > > correct, no :::0.0.0.0/96 address should be returned if the name
> > > > resolution works fine...
> > > >
> > > > -- Hiroki
> > > >
>
Hi,
>>>>> On Wed, 9 Jan 2013 16:29:00 +
>>>>> Ben Morrow said:
ben> Where does it say that? All I can find (but I might be being stupid) is
ben> the bit in the description of AI_ALL where it says 'A query is first
ben> made for records a
Ben Morrow wrote
in <20130109154435.ga81...@anubis.morrow.me.uk>:
be> So getipnodebyname is behaving correctly here: the host has both IPv4
be> and IPv6 addresses, and Sendmail is requesting both native and v4-mapped
be> addresses be returned in all cases. The v4-mapped addres
Quoth Hajimu UMEMOTO :
> >>>>> On Wed, 09 Jan 2013 23:01:52 +0900
> >>>>> Hajimu UMEMOTO said:
>
> ume> I changed getipnodebyname to obey ip6addrctl in years past. I read
> ume> RFC 2553 again, and realize that it mentions IPv6 addresses are
&g
ng under 8.x and 9.1 (the code is the same). I think
> gs> something changed with the upgrade to 9.1. As far as tracking it
> gs> down, the sendmail code does:
> gs>
> gs> getipnodebyname("acme.spoerlein.net", AF_INET6, AI_DEFAULT|AI_ALL,
> gs> &err);
&g
Hi,
>>>>> On Wed, 09 Jan 2013 23:01:52 +0900
>>>>> Hajimu UMEMOTO said:
ume> I changed getipnodebyname to obey ip6addrctl in years past. I read
ume> RFC 2553 again, and realize that it mentions IPv6 addresses are
ume> returned 1st. So, my past ch
+selection rule.
+If this flag is set, stop treating the address on the
+.Ar interface
+as special even when the
+.Ar interface
+is outgoing interface.
+The default value of this flag is off.
.It Ic disabled
Disable IPv6 operation on the interface.
When disabled, the interface discards any IPv
ess should be returned if the name
uq> > > resolution works fine...
uq> > >
uq> > > -- Hiroki
uq> > >
uq> >
uq> > getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:-
uq> >
uq> > If a host has both IPv6 and IPv4 addresses, both a
this just hides the problem. If gshapiro@'s explanation is
> > correct, no :::0.0.0.0/96 address should be returned if the name
> > resolution works fine...
> >
> > -- Hiroki
> >
>
> getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:-
>
s fine...
I changed getipnodebyname to obey ip6addrctl in years past. I read
RFC 2553 again, and realize that it mentions IPv6 addresses are
returned 1st. So, my past change might be bad thing. X-(
However, I'm still curious about use of AI_ALL in sendmail. As far as
I read the source of sendm
ppily finding the sockets to bind to. Thanks for the
hint!
I think this just hides the problem. If gshapiro@'s explanation is
correct, no :::0.0.0.0/96 address should be returned if the name
resolution works fine...
-- Hiroki
getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does
Ulrich Spörlein wrote
in <20130108184051.gi35...@acme.spoerlein.net>:
uq> After setting this, it now looks like this:
uq> root@acme: ~# ip6addrctl
uq> Prefix Prec Label Use
uq> ::1/128 50 00
uq> ::/0
t; something changed with the upgrade to 9.1. As far as tracking it
gs> down, the sendmail code does:
gs>
gs> getipnodebyname("acme.spoerlein.net", AF_INET6, AI_DEFAULT|AI_ALL,
gs> &err);
gs>
gs> This will only return an IPv4 mapped address if:
gs>
gs> 1. Th
rade to 9.1. As far as tracking it down, the sendmail code does:
>
> getipnodebyname("acme.spoerlein.net", AF_INET6, AI_DEFAULT|AI_ALL, &err);
>
> This will only return an IPv4 mapped address if:
>
> 1. There are no IPv6 addresses configured on the interfa
30 20
::/96 20 30
:::0.0.0.0/96 10 40
And even sendmail is happily finding the sockets to bind to. Thanks for the
hint!
The bigger question now is, why don't we want to have a working IP
On 01/08/2013 16:18, Ulrich Spörlein wrote:
[...]
98054 sendmail CALL bind(0x7,0x708dbc,0x1c)
98054 sendmail STRU struct sockaddr { AF_INET6, [:::88.198.49.12]:587 }
98054 sendmail RET bind -1 errno 49 Can't assign requested address
Yeah right ... I don't want an IPv6-m
debyname("acme.spoerlein.net", AF_INET6, AI_DEFAULT|AI_ALL, &err);
This will only return an IPv4 mapped address if:
1. There are no IPv6 addresses configured on the interfaces. How are your IPv6
addresses assigned? If auto-configured (DHCPv6, RTADV), is it possible
sendmail is being started be
EC)
98054 sendmail RET fcntl 0
98054 sendmail CALL bind(0x7,0x708dbc,0x1c)
98054 sendmail STRU struct sockaddr { AF_INET6, [:::88.198.49.12]:587 }
98054 sendmail RET bind -1 errno 49 Can't assign requested address
Yeah right ... I don't want an IPv6-mapped-IPv4 address, I want it
With FreeBSD 9.1-RC2 you can assign the same link local address manually to two
different hosts on the same network. The Neighbor Solicitations are not
responded to and you end up with non-working addresses. The simple way to
reproduce this is to boot two systems on the same network and get th
> How new is your kernel? There were some weird IPv6 issues a month
> or two back that have since been fixed. A kernel from 3 days ago
> (r240583) is working well for me here... so if you installed from
> the 9.1-RC1 ISO image you might try updating.
I've just one of the trou
the
> >first upgrade, I noticed something strange with networking but didn't
> >really dig into it much. After the second upgrade immediately experiencing
> >the same issues, I figured it seemed to be something related to 9.1rc1.
> >
> How new is your kernel? There w
>> the same issues, I figured it seemed to be something related to 9.1rc1.
> >>
> > How new is your kernel? There were some weird IPv6 issues a month or two
> > back that have since been fixed. A kernel from 3 days ago (r240583) is
> > working well for me here...
After the
>> first upgrade, I noticed something strange with networking but didn't
>> really dig into it much. After the second upgrade immediately
>> experiencing
>> the same issues, I figured it seemed to be something related to 9.1rc1.
>>
> How new is your kern
ch. After the second upgrade immediately experiencing
the same issues, I figured it seemed to be something related to 9.1rc1.
How new is your kernel? There were some weird IPv6 issues a month or
two back that have since been fixed. A kernel from 3 days ago (r240583)
is working well for me here
mmediately experiencing
the same issues, I figured it seemed to be something related to 9.1rc1.
What I am finding is that packets that originate from the FreeBSD boxes do
not get returned when running IPv6. V4 seems to be fine. I can also shell
into the boxes without issue, which is strange, since I would
r the most packets (not always with 16732 bytes, but
most packets over 10,000) - could that be reassembled somehow?
only slowly catching up on email so... chiming in now.
I'd assume in this case the iperf "server" is linux or did Jack add
IPv6 LRO support to e1000? Sorry, I am not
On Thu, Aug 30, 2012 at 5:06 PM, Norbert Aschendorff
wrote:
> I tested it using tcpdump: http://nopaste.info/9394068f54_nl.html
> The length field says for each packet 1408 bytes, so that should be OK.
>
TCP the packet size is OK (MSS negociated), it's in IPv6 UDP mode that
iperf
I tested it using tcpdump: http://nopaste.info/9394068f54_nl.html
The length field says for each packet 1408 bytes, so that should be OK.
The Wireshark instance on the iperf server says something like "16732
bytes on wire" for the most packets (not always with 16732 bytes, but
most packets over 10
On Wed, Aug 29, 2012 at 8:14 PM, Norbert Aschendorff
wrote:
> This confirms the FreeBSD IPv6 receive rate measured with Linux as
> sender (iperf client).
>
Hi,
Last time I've played with IPerf and IPV6 between my FreeBSD machines,
he didn't take care of the IPv6 Ethernet MTU
Norbert Aschendorff yahoo.de> writes:
> ...
> {Values in MBit/s}
>
> Configuration IPv6IPv4
> ---
> [1] -> [2]450 600
> [2] -> [1]401 85
So, I got the results using the Live system.
Machine [1] is an older Thinkpad T61 (running the Live system), Machine
[2] the well-known "FreeBSD" machine from the previous benchmark. Both
machines run FreeBSD 9.1-RC1 GENERIC.
{Values in MBit/s}
Configuration IP
That's a bit difficult because I own only one FreeBSD machine - to
provide a result FreeBSD->FreeBSD I'd have to set up a completely new
system. On the other side, I could try it using the Live system. I'll
try it and tell you when I have results.
Norbert
__
s, using the em(4) driver on
> FreeBSD) is able to send at full 1G speed. But why is IPv6 so slow?
Norbert,
may I ask you to provide one more stats item for this table, if you can ?
FreeBSD -> FreeBSD??? ???
Thanks,
jb
___
freebsd-sta
nux -> FreeBSD 450 700
> FreeBSD -> Linux 455 920
> ===
>
> The FreeBSD->Linux value shows that the ethernet chip on the FreeBSD
> machine (it's Intel stuff on both sides, using the em(4) driver on
> FreeBSD) is abl
think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B:
Sorry, my bad.
Are pcn0 and rl0 both connected to internal networks?
Having the same /64 configured on both is probably bad.
Why would it be?
Unless you bridge the two interface, yes. Which interface do you start ND on?
For the O
I'd guess it has to do with incomplete offload code for ipv6, but I'm sure
you'll see bz chiming in with details. :-)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, s
Hi,
I'm using here a Gigabit Ethernet network and some UN*X machines, among
others some Linux-based (Kernel 3.x) and one running FreeBSD 9.1-RC1.
Using iperf (in TCP mode), the IPv6 bandwith between two Linux machines
(directly attached to the same switch) is about 925 Mbit/s, IPv4
bandwi
> On 8/27/2012 12:27 PM, Christian Laursen wrote:
>> On 08/27/12 21:03, John Hawkes-Reed wrote:
>>> On 27/08/2012 19:06, Christian Laursen wrote:
On 08/27/12 18:49, John Hawkes-Reed wrote:
> rc.conf:
>
> (I'm not convinced that obfuscating the addresses is worth the
> confusion
Hi all,
mwi1# uname -a
FreeBSD mwi1.coffeenet.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #5
r239731: Mon Aug 27 09:53:18 CDT 2012
r...@mwi1.coffeenet.org:/usr/obj/usr/src/sys/GENERIC amd64
My ipv6 connections hang for several seconds when this scrub rule is
enabled:
scrub all
y what causes the problem.
> >>>
> >>> You should use the "Routed /64" on the inside. If you need more than one
> >>> /64, you can request a /48.
> >>
> >> I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B:
> >
>
On 8/27/2012 12:27 PM, Christian Laursen wrote:
> On 08/27/12 21:03, John Hawkes-Reed wrote:
>> On 27/08/2012 19:06, Christian Laursen wrote:
>>> On 08/27/12 18:49, John Hawkes-Reed wrote:
rc.conf:
(I'm not convinced that obfuscating the addresses is worth the
confusion)
>>
On 08/27/12 21:03, John Hawkes-Reed wrote:
On 27/08/2012 19:06, Christian Laursen wrote:
On 08/27/12 18:49, John Hawkes-Reed wrote:
rc.conf:
(I'm not convinced that obfuscating the addresses is worth the
confusion)
ipv6_gateway_enable="YES"
ip6addrctl_verbose="YES"
rtadvd_enable="YES"
rtadvd_
he default gateway on the box that I'm writing this from is link-local
and IPv6 works quite nicely.
Aha. Good.
Trying to ping6/traceroute6 out to (say) Google works on the BSD box,
but not on the clients.
Do I need to be running a routing daemon, or is there some ip6
handwaving I'm m
ng this from is link-local
and IPv6 works quite nicely.
Trying to ping6/traceroute6 out to (say) Google works on the BSD box,
but not on the clients.
Do I need to be running a routing daemon, or is there some ip6
handwaving I'm missing?
If you are running pf or another firewall, you sh
nto Prefix field. Since “:” is used
for termcap(5) file format as well as IPv6 numeric
address, the
field MUST be quoted by doublequote character.
Sorry I couldn't be much help.
___
freebsd-stable@freebsd.org ma
On 27/08/2012 17:56, Stanisław Halik wrote:
On 2012-08-27 18:49, John Hawkes-Reed wrote:
I'm sure this is a FAQ, but I've been staring at it too long to spot the
obvious.
rtadvd_interfaces="rl0"
Show also /etc/rtadvd.conf. Here's mine:
kronstadt ~# cat /etc/rtadvd.conf
vr0::rdnss="2001:470
On 2012-08-27 18:49, John Hawkes-Reed wrote:
I'm sure this is a FAQ, but I've been staring at it too long to spot the
obvious.
rtadvd_interfaces="rl0"
Show also /etc/rtadvd.conf. Here's mine:
kronstadt ~# cat /etc/rtadvd.conf
vr0::rdnss="2001:470:600d:dead::1":dnssl="misaki.pl":addr="2001:4
I'm sure this is a FAQ, but I've been staring at it too long to spot the
obvious.
BSD-box (9.1-PRE) is acting as default router/NAT gateway for local LAN.
IP4 works.
IP6 rig, per the setup on tunnelbroker.net, appears to work on the BSD box.
However, while LAN clients (XP, OSX) manage to acq
On Wed, 1 Aug 2012, Matthew Seaman wrote:
On 01/08/2012 18:13, Bjoern A. Zeeb wrote:
Any of you who are expereincing problems with packets dropped due to
invalid checksums with IPv6 and pf after the recent merges, can you
report back if you also see this without "modulate state&quo
On 01/08/2012 18:13, Bjoern A. Zeeb wrote:
> Any of you who are expereincing problems with packets dropped due to
> invalid checksums with IPv6 and pf after the recent merges, can you
> report back if you also see this without "modulate state" in your
> pf.conf (if you ha
On Thu, 26 Jul 2012, Matthew Seaman wrote:
Hi,
as there have been more people having problems with pf and IPv6 after
the changes I am replying to stable@ cc: pf@.
...
[...]
nat on $ext_if_plus from $xenophobe_int to any -> $xenophobe_ext
rdr inet6 proto tcp from to $xenophobe_ext \
p
schrieb Bjoern A. Zeeb am 29.07.2012 01:02 (localtime):
> On Thu, 26 Jul 2012, Matthew Seaman wrote:
>
> Just for the public; I am talking to him privately currently; I'll
> summarize findings either here or in a commit message.
>
Thanks for the info! Any news worth to share?
Best regards,
-Ha
On Thu, 26 Jul 2012, Matthew Seaman wrote:
Just for the public; I am talking to him privately currently; I'll
summarize findings either here or in a commit message.
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new a
On 26/07/2012 21:51, Mike Andrews wrote:
> Sounds like what I hit and filed kern/170070 on -- basically a host not
> being able to talk to itself on IPv6, except on the ::1 address.
>
> Workaround: ifconfig lo0 -txcsum6 -rxcsum6
>
> or in /etc/rc.conf:
>
> ifconf
1 - 100 of 345 matches
Mail list logo
