, what can be done to bind both sockets to their required
ports?
I also tried to set ip4.saddrsel = 1 in the jail config, but it appeared
that nothing changed. If the IP address configuration is omitted for the
jail, the service does not encounter the error of an address that is
already in
outside a jail. Is this
actually intended? If so, what can be done to bind both sockets to their
required ports?
I also tried to set ip4.saddrsel = 1 in the jail config, but it appeared
that nothing changed. If the IP address configuration is omitted for the
jail, the service does not
ssion, but the third one is not of
concern here.
So, essentially I have a multicast-enabled socket and a "conventional"
unicast socket that need to be bound to the same port. On Linux, I can
bind the the multicast socket to the legacy IP multicast address, but
for FreeBSD this does
CC||gleb...@freebsd.org
Status|New |Open
--- Comment #7 from Gleb Smirnoff ---
I like your patch. Note that EFTYPE and EEXIST are not listed in specification
for bind(2), thus this allows us consider suggested functionality to be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265489
--- Comment #3 from todene...@gmail.com ---
https://serverfault.com/questions/1106883/freebsd-bind-non-local-ipv6-address
--
You are receiving this mail because:
You are the assignee for the bug.
fd, IPPROTO_IPV6, IPV6_BINDANY, &on, sizeof(on));
sin.sin6_family = AF_INET6;
sin.sin6_port = htons(0);
if(inet_pton(AF_INET6, bind_ip, &sin.sin6_addr) != 1)
{
fprintf(stderr, "Invalid bind source address.\n");
return 1;
}
sa.sin6_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265489
Zhenlei Huang changed:
What|Removed |Added
CC||zlei.hu...@gmail.com
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265489
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262172
--- Comment #6 from f...@cantconnect.ru ---
Created attachment 232216
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232216&action=edit
new patch
--
You are receiving this mail because:
You are the assignee for the bug.
t of them just fails on any bind error,
2) some of them tries to cleanup stale socket before bind, or after any bind
error,
3) some of them tries to cleanup stale socket on EADDRINUSE and displays a
error for all other codes.
Third type of applications may be broken due to this change, and they are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262172
Mike Karels changed:
What|Removed |Added
CC||kar...@freebsd.org
--- Comment #4 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262172
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org
Assi
dditional stack variables, 'sin->sin6_scope_id' ends
up being set to '0', while in the other case it
retains a random value. The random value then means
that we're trying to bind not "::1", but
"::1%", which is why this fails.
Fun.
-Jan
Konstantin Belousov wrote:
> On Tue, Nov 23, 2021 at 09:08:39PM -0500, Jan Schaumann via freebsd-net wrote:
> > - Why does _any_ of those fail?
> > - Why does a.c succeed when compiled with clang, but
> > b.c does not?
> Most likely because you did not fully initialized *sin.
> Really it is UB
On Tue, Nov 23, 2021 at 09:08:39PM -0500, Jan Schaumann via freebsd-net wrote:
> Hello,
>
> I'm observing the following strange behavior, where
> trying to bind(2) a socket on "::1" fails with
> EADDRNOTAVAIL, but binding in6addr_any will succeed
> (and then yiel
Jan Schaumann via freebsd-net wrote:
> Compiling either with gcc version 10.3.0 fails.
Sorry, this is misleading. I meant to say:
Compiling either with gcc version 10.3.0 yields a
program that fails to bind(2). Compilation itself
succeeds just fine.
-Jan
Hello,
I'm observing the following strange behavior, where
trying to bind(2) a socket on "::1" fails with
EADDRNOTAVAIL, but binding in6addr_any will succeed
(and then yield a bound ::1). What's more, the
behavior is inconsistent depending on the compiler
used.
Here
On Fri, May 28, 2021 at 03:21:15PM -0700, Bakul Shah wrote:
> On May 28, 2021, at 3:12 PM, Mark Johnston wrote:
> >
> > On Fri, May 28, 2021 at 02:40:26PM -0700, Bakul Shah wrote:
> >> ttcp runs fine on 13.0-RELEASE but fails on -stable.
> >>
> >> The
On May 28, 2021, at 3:12 PM, Mark Johnston wrote:
>
> On Fri, May 28, 2021 at 02:40:26PM -0700, Bakul Shah wrote:
>> ttcp runs fine on 13.0-RELEASE but fails on -stable.
>>
>> The culprit seems to be bind(2). Running ttcp under gdb:
>>
>> $ gdb a.out
>>
On Fri, May 28, 2021 at 02:40:26PM -0700, Bakul Shah wrote:
> ttcp runs fine on 13.0-RELEASE but fails on -stable.
>
> The culprit seems to be bind(2). Running ttcp under gdb:
>
> $ gdb a.out
> Reading symbols from a.out...
> (gdb) b 295
> Breakpoint 1 at 0x203127: file
ttcp runs fine on 13.0-RELEASE but fails on -stable.
The culprit seems to be bind(2). Running ttcp under gdb:
$ gdb a.out
Reading symbols from a.out...
(gdb) b 295
Breakpoint 1 at 0x203127: file ttcp.c, line 295.
(gdb) run -s -r
Starting program: /usr/ports/benchmarks/ttcp/work/ttcp-1.12_2/a.out
Check it out:
https://forums.freebsd.org/threads/useful-scripts.737/page-14#post-483070
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd
Hi,
I think that making dns/bind911, dns/bind912, etc, depend on bind-tools which
depends on dns/bind914 is a really bad idea.
Bind versions ship with their own bind tools and it’s a POLA violation to mix
release versions.
It’s understandable to make bind-tools depend on the latest stable
> On Nov 13, 2017, at 4:02 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> I think keys can be updated by updating the port or by some dedicated
> periodic script. It seems safer to me.
In theory it may be safer. In practice, it tends to not happen in a timely
manner, leading to outages. A
.
This has the additional benefit that if files in the chroot are compromised
they get overwritten by the originals on service restart. Could this be
implemented for BIND as well?
Another little question regarding chroot, is it possible to make net/kea
chrootable? There are currently no such options
tarted.
> This has the additional benefit that if files in the chroot are compromised
> they get overwritten by the originals on service restart. Could this be
> implemented for BIND as well?
> Another little question regarding chroot, is it possible to make net/kea
> chrootable? T
they get overwritten by the originals on service restart. Could this be
implemented for BIND as well?
Another little question regarding chroot, is it possible to make net/kea
chrootable? There are currently no such options in the kea rc script.
With regards,
Dries
This revision was automatically updated to reflect the committed changes.
Closed by commit rS295792: hyperv/hn: Add option to bind TX taskqueues to the
specified CPU (authored by sephe).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D5316?vs=13407&id=13480#toc
REPOSITORY
rS Fre
adrian accepted this revision.
This revision has a positive review.
REVISION DETAIL
https://reviews.freebsd.org/D5316
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com,
honzhan_microsoft.com, howard0s
sepherosa_gmail.com updated the summary for this revision.
REVISION DETAIL
https://reviews.freebsd.org/D5316
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com,
honzhan_microsoft.com,
sepherosa_gmail.com added a comment.
In https://reviews.freebsd.org/D5316#113452, @howard0su_gmail.com wrote:
> I worried so many options just brings headache to the end user without the
clearly instruction on how to tune it. Please introduce new option when it is
really needed. Maybe it
howard0su_gmail.com added a comment.
I worried so many options just brings headache to the end user without the
clearly instruction on how to tune it. Please introduce new option when it is
really needed. Maybe it is good time now to write a man page for hn.
REVISION DETAIL
https://reviews
CTLFLAG_RDTUN,
+&hn_bind_tx_taskq, 0, "Bind TX taskqueue to the specified cpu");
+
/*
* Forward declarations
*/
@@ -383,8 +387,20 @@
if (hn_tx_taskq == NULL) {
sc->hn_tx_taskq = taskqueue_create("hn_tx", M_WAITOK,
t
On Thu, Jan 8, 2015 at 9:48 AM, hiren panchasara
wrote:
[skip]
> Btw, do you mind opening a phabricator review request so we can get a
> closure on this?
Thanks for the patch ume@. I've committed it to -head and will mfc in a week.
https://reviews.freebsd.org/D1527
https://svnweb.freebsd.org/bas
On Thu, Jan 8, 2015 at 9:48 AM, hiren panchasara
wrote:
> On Thu, Jan 8, 2015 at 9:28 AM, Hajimu UMEMOTO wrote:
>> Hi,
>>
>>> On Wed, 7 Jan 2015 16:56:58 -0800
>>> hiren panchasara said:
>>
>> hiren> I see this message on july 2014 time-frame -CURRENT. I tried to
>> hiren> disable IPv6 i
On Thu, Jan 8, 2015 at 9:28 AM, Hajimu UMEMOTO wrote:
> Hi,
>
>> On Wed, 7 Jan 2015 16:56:58 -0800
>> hiren panchasara said:
>
> hiren> I see this message on july 2014 time-frame -CURRENT. I tried to
> hiren> disable IPv6 in rc.conf via ipv6_activate_all_interfaces="NO" without
> hiren> s
Hi,
> On Wed, 7 Jan 2015 16:56:58 -0800
> hiren panchasara said:
hiren> I see this message on july 2014 time-frame -CURRENT. I tried to
hiren> disable IPv6 in rc.conf via ipv6_activate_all_interfaces="NO" without
hiren> success.
hiren> Has this been fixed? Or any workarounds?
Perhaps,
I see this message on july 2014 time-frame -CURRENT. I tried to
disable IPv6 in rc.conf via ipv6_activate_all_interfaces="NO" without
success.
Has this been fixed? Or any workarounds?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mail
g chrooted to /var/named. All paths will have /var/named
>tacked onto the front.
Ah! OK. It makes sense now.
>> So, um, what is the Right Solution here? Do I need to re-jigger
>> the permissions on /var/named/etc/namedb/master to 0775 and then
>> add user-ID "bind&qu
're running chrooted to /var/named. All paths will have /var/named
tacked onto the front.
> The more troublesome problem however is that at first, my dynamic
> updates were failing with SERVFAIL errors, and I couldn't figure
> out why until I looked at the tail of /var/log/messag
I've just been messing around with the nsupdate program, which,
as I'm sure you all know, is part of the BIND 9 package.
For now, I'm just using in in "local" mode, i.e. invoking it with
the -l option.
I did managed to get it to perform a dynamic update, but I enco
Greetings.
I have a machine with interface IP1 connected to Provider1.
Some time ago i've connected Provider2 to another interface IP2.
I set new fib №1 with provider2 setting and configure interface2 for
fib 1 ('ifconfig if2 inet IP1 netmask mask2 fib 1').
Now i can do 'setfib 1 ping google.
) = 0 (0x0)
setsockopt(0x4,0x,0x20,0x7fbfd7d8,0x4,0x0) = 0 (0x0)
getsockopt(0x4,0x,0x1008,0x7fbfd77c,0x7fbfd778,0x83f5292d8) = 0
(0x0)
setsockopt(0x4,0x,0x200,0x7fbfd7e0,0x4,0x83f5292d8) = 0 (0x0)
setsockopt(0x4,0x,0x4,0x7fbfd7e0,0x4,0x83f5292d8) = 0 (0x0)
bind(4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246
--- Comment #2 from Craig Rodrigues ---
I did some more analysis and found that this code:
13253 java CALL bind(0x4,0x7fbfd7a8,0x1c)
13253 java STRU struct sockaddr { AF_INET6, [::]:33848 }
13253 java RET bind 0
_REUSEADDR,0x7fbfd7e0,0x4)
13253 java RET setsockopt 0
13253 java CALL bind(0x4,0x7fbfd7a8,0x1c)
13253 java STRU struct sockaddr { AF_INET6, [::]:33848 }
13253 java RET bind 0
13253 java CALL setsockopt(0x4,0x29,0x9,0x7fbfd7f4,0x4)
13253 java RET setsockop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246
Craig Rodrigues changed:
What|Removed |Added
CC||freebsd-j...@freebsd.org,
On 6/19/2014 4:57 AM, Massimiliano Stucchi wrote:
On 19/06/14 05:11, Darren Pilgrim wrote:
FreeBSD doesn't support 6rd. Ironically, pfSense does.
This is not entirely true. 6RD is about establishing a 6to4 tunnel to a
well-defined tunnel server in your provider's infrastructure, so as long
> On 19/06/14 05:11, Darren Pilgrim wrote:
>
>>
>> FreeBSD doesn't support 6rd. Ironically, pfSense does.
>
> This is not entirely true. 6RD is about establishing a 6to4 tunnel to a
> well-defined tunnel server in your provider's infrastructure, so as long
> as you have the details about the tunn
> On 6/18/2014 10:12 PM, Chris H wrote:
>>> FreeBSD doesn't support 6rd. Ironically, pfSense does.
> >
>> Are you sure?
>> There are even a couple of 6rd ports:
>> net/stf-6rd-kmod
>> and
>> net/u6rd
>> or am I to understand that _without_ those ports, FreeBSD doesn't
>> support 6rd.
>
> Yes, if
On 19/06/14 05:11, Darren Pilgrim wrote:
>
> FreeBSD doesn't support 6rd. Ironically, pfSense does.
This is not entirely true. 6RD is about establishing a 6to4 tunnel to a
well-defined tunnel server in your provider's infrastructure, so as long
as you have the details about the tunnel server's
On 6/18/2014 10:12 PM, Chris H wrote:
FreeBSD doesn't support 6rd. Ironically, pfSense does.
>
Are you sure?
There are even a couple of 6rd ports:
net/stf-6rd-kmod
and
net/u6rd
or am I to understand that _without_ those ports, FreeBSD doesn't
support 6rd.
Yes, if you bring in third-party cod
> Chris,
>
> On 6/18/2014 8:11 PM, Mail Delivery System wrote:
>> : host mx99.ultimatedns.net[209.180.214.225]
>> said: 550 5.0.0 SPAM and BULK mail REJECTED (in reply to MAIL FROM
>> command)
>
> You might need to adjust your mail filters. :)
Thanks for the heads up. Appears the IP block yoshi.brt
> On 6/18/2014 9:36 AM, Chris H wrote:
>> Greetings,
>> I manage a /29 at $home. While I manage _real_ IPv6 on many networks
>> at $work. I'm stuck with 6rd at $home. I don't much care for 6rd. It's
>> still pretty much 6to4. But it's all I have to work with, given the
>> CPE's limitations. So, a
Chris,
On 6/18/2014 8:11 PM, Mail Delivery System wrote:
: host mx99.ultimatedns.net[209.180.214.225]
said: 550 5.0.0 SPAM and BULK mail REJECTED (in reply to MAIL FROM
command)
You might need to adjust your mail filters. :)
On 6/18/2014 9:36 AM, Chris H wrote:
Greetings, I manage a /29 at
On 6/18/2014 9:36 AM, Chris H wrote:
Greetings,
I manage a /29 at $home. While I manage _real_ IPv6 on many networks
at $work. I'm stuck with 6rd at $home. I don't much care for 6rd. It's
still pretty much 6to4. But it's all I have to work with, given the
CPE's limitations. So, as I'm new to it
Greetings,
I manage a /29 at $home. While I manage _real_ IPv6 on many networks
at $work. I'm stuck with 6rd at $home. I don't much care for 6rd. It's
still pretty much 6to4. But it's all I have to work with, given the
CPE's limitations. So, as I'm new to it, I'm not quite sure _which_
address to
On Wednesday, July 17, 2013 5:23:37 pm Mikolaj Golub wrote:
> On Tue, Jul 16, 2013 at 11:12:46AM -0400, John Baldwin wrote:
> > On Thursday, March 15, 2012 8:07:46 pm Sean Bruno wrote:
> > > On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote:
> > > > Hey, I just
On Tue, Jul 16, 2013 at 11:12:46AM -0400, John Baldwin wrote:
> On Thursday, March 15, 2012 8:07:46 pm Sean Bruno wrote:
> > On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote:
> > > Hey, I just found a bind bug ticket in my queue about bind. I noted
> > > that on
On Thursday, March 15, 2012 8:07:46 pm Sean Bruno wrote:
> On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote:
> > Hey, I just found a bind bug ticket in my queue about bind. I noted
> > that on stable/6 stable/7 stable/9 & head the referenced code "fails".
>
El día Thursday, May 30, 2013 a las 02:48:52PM +0300, Zeus Panchenko escribió:
> hi,
>
> may somebody help with the subject, please?
>
> is there way to bind tun device which ppp creates/uses to the definite
> one, let's say tun0 ? to avoid interface appointment change (i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
may somebody help with the subject, please?
is there way to bind tun device which ppp creates/uses to the definite
one, let's say tun0 ? to avoid interface appointment change (in case I
need binding WAN on tunN)
for example OpenVPN allo
s my typo, ff02:, of course.
MR> I've looked into getting MDNS to update BIND like DHCP would do for
MR> DDNS, but had no luck to get that going.
I've tried to get ANY DDNS updates from Win7 without AD, but it
looks like there is no updates are sent :( But it is an
Am 28.03.2013 15:58, schrieb Mattia Rossi:
Am 28.03.2013 14:49, schrieb Lev Serebryakov:
Hello, Freebsd-net.
This question is not very FreeBSD specific, but as my router and DNS
server are FreeBSD-based, I think a could ask it here and don't
subscribe do BIND-related list, Ok?
When D
Am 28.03.2013 14:49, schrieb Lev Serebryakov:
Hello, Freebsd-net.
This question is not very FreeBSD specific, but as my router and DNS
server are FreeBSD-based, I think a could ask it here and don't
subscribe do BIND-related list, Ok?
When DHCPv4 is not available, Win7 clients
Hello, Freebsd-net.
This question is not very FreeBSD specific, but as my router and DNS
server are FreeBSD-based, I think a could ask it here and don't
subscribe do BIND-related list, Ok?
When DHCPv4 is not available, Win7 clients on my network pick up
proper IPv6 prefix, but cannot pi
Hi,
On Mar 26, 2013, at 15:39, kit wrote:
>
> try setting ipv6_activate_all_interfaces to yes
I had that set all along.
> and configuring the corresponding $ifconfig_IF_ipv6 in your rc.conf if you
> haven't done so already
Can't really do this, because dhclient needs to have finished so I ca
--- On Tue, 3/26/13, kit wrote:
> --- On Tue, 3/26/13, Eggert, Lars
>
> wrote:
> > On Mar 26, 2013, at 12:59,
> > wrote:
> > > How do you configure your network interfaces?
> Using
> > /etc/start_if* or /etc/rc.conf?
> >
> > The latter.
> >
> > (Actually, most of them are configured in rc.loc
--- On Tue, 3/26/13, Eggert, Lars wrote:
> On Mar 26, 2013, at 12:59,
> wrote:
> > How do you configure your network interfaces? Using
> /etc/start_if* or /etc/rc.conf?
>
> The latter.
>
> (Actually, most of them are configured in rc.local with a
> bit of shell code that generates the IP addre
On Mar 26, 2013, at 12:59,
wrote:
> How do you configure your network interfaces? Using /etc/start_if* or
> /etc/rc.conf?
The latter.
(Actually, most of them are configured in rc.local with a bit of shell code
that generates the IP address from the MAC address for a set of machines.)
Lars
__
How do you configure your network interfaces? Using /etc/start_if* or
/etc/rc.conf?
___
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"
Hi,
>> I confirm I have the same issue on 9.1 r247912 , as below:
same here, on FreeBSD 10.0-CURRENT #5 r+16848a4-dirty:
Mar 26 11:43:17 ntpd[2783]: bind() fd 23, family AF_INET6, port 123, scope 1,
addr fe80::92e2:baff:fe2b:3a00, mcast=0 flags=0x11 fails: Can't assign
requested
Hi,
> On Fri, 15 Mar 2013 22:54:42 +0100 (CET)
> "M. Schulte" said:
m-freebsd> I fear I cannot answer all of these questions. I don't have any IPv6
m-freebsd> addresses configured in rc.conf. Also, I am not using dhcp. Basically
m-freebsd> I only have IPv4 networking configured with stat
To add a few notes:
I did some more debugging/testing and this behaviour seems to be a bit
random. Sometimes I boot the system and no error is triggered the
number of 'cannot assign requested errors' varies between 0 and 2 on
my system and I have no idea what might influence it. :-/
Thanks,
Hi,
What is the address space is the address you are seeing on the interface?
Is it is a link-local address or one assigned by the router, a static from
rc.conf or DHCPv6? You should have two inet6 addresses, one is link-local
(starts with "fe") and another should start with "2". There may be mo
t;> environment, in case that matters) and during boot the following
> >> messages appear:
> >>
> >> ntpd[766]: ntpd 4.2.4p5-a (1)
> >> ntpd[767]: bind() fd 23, family AF_INET6, port 123, scope 2, addr
> >> fe80::216:36ff:fe74:2076, mcast=0 fl
the set of
>> subscribers here and those of the forum do not completely coincide.]
>>
>> I have installed FreeBSD 9.1 on my server (it's a virtualized qemu/kvm
>> environment, in case that matters) and during boot the following
>> messages appear:
>>
>
> I have installed FreeBSD 9.1 on my server (it's a virtualized qemu/kvm
> environment, in case that matters) and during boot the following
> messages appear:
>
>ntpd[766]: ntpd 4.2.4p5-a (1)
>ntpd[767]: bind() fd 23, family AF_INET6, port 123, scope 2, addr
> fe80::
> I have installed FreeBSD 9.1 on my server (it's a virtualized qemu/kvm
> environment, in case that matters) and during boot the following
> messages appear:
>
> ntpd[766]: ntpd 4.2.4p5-a (1)
> ntpd[767]: bind() fd 23, family AF_INET6, port 123, scope 2, addr
> fe8
t, in case that matters) and during boot the following
messages appear:
ntpd[766]: ntpd 4.2.4p5-a (1)
ntpd[767]: bind() fd 23, family AF_INET6, port 123, scope 2, addr
fe80::216:36ff:fe74:2076, mcast=0 flags=0x11 fails: Can't assign requested
address
ntpd[767]: unable to create soc
le to
> > > > disable
> > > > igb's manual binding and instead let the default system round-robin
> > > > be
> > > > preserved.
> > >
> > > also, yes. Why *are* we binding to CPUs in the first place? Are we
> > &
>
> > also, yes. Why *are* we binding to CPUs in the first place? Are we
> > afraid that the scheduler won't do the right thing and we're trying to
> > work around some unknown performance issue ?
> >
> > Sean
> >
>
> Still haven't seen
x27;s manual binding and instead let the default system round-robin
> > be
> > preserved.
>
> also, yes. Why *are* we binding to CPUs in the first place? Are we
> afraid that the scheduler won't do the right thing and we're trying to
> work around so
won't do the right thing and we're trying to
> work around some unknown performance issue ?
Well, in some cases you want to know exactly which CPUs are being used
as you might bind other resources associated with the queue to those
specific CPUs as well.
--
John Baldwin
On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote:
> CPU IDs are not guaranteed to be dense. However, you can use
> CPU_FIRST() and
> CPU_NEXT() with your static global instead.
>
Ah, does CPU_NEXT() reset to 0 when it reaches the end of its list of
CPUs?
> OTOH, if igb were to just leave
On Tuesday, April 24, 2012 8:11:07 pm Sean Bruno wrote:
> http://people.freebsd.org/~sbruno/if_igb.c.txt
>
> Scenario I've just seen:
>
> 8 core machine
> 2 igb(4) interfaces
> set num_queues=4
>
> igb0:0 --> cpu0
> igb0:1 --> cpu1
> igb0:2 --> cpu2
> igb0:3 --> cpu3
>
> igb1:0 --> cpu0
> igb1:
ounter
> and the number of cpus in the box.
This seems like a plausible approach, and certainly much more DWIM
than what I've done in the past, which is to use cpuset with -x to
bind each IRQ to a core by hand. If there were a way for interfaces
to export queue information including any relevant
http://people.freebsd.org/~sbruno/if_igb.c.txt
Scenario I've just seen:
8 core machine
2 igb(4) interfaces
set num_queues=4
igb0:0 --> cpu0
igb0:1 --> cpu1
igb0:2 --> cpu2
igb0:3 --> cpu3
igb1:0 --> cpu0
igb1:1 --> cpu1
igb1:2 --> cpu2
igb1:3 --> cpu3
I suspect, that we need a static global to
On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote:
> Hey, I just found a bind bug ticket in my queue about bind. I noted
> that on stable/6 stable/7 stable/9 & head the referenced code "fails".
>
> It seems that this is a problem, but I have no idea if its a real
&
Hey, I just found a bind bug ticket in my queue about bind. I noted
that on stable/6 stable/7 stable/9 & head the referenced code "fails".
It seems that this is a problem, but I have no idea if its a real
problem or not. Our devs think it is. Anyway, here is a code snippet
to sh
Hello all,
I have problems running programs that need to receive multicast traffic
from the network in a jailed environment.
For example, a program udpxy I wanted to use, says:
"setup_mcast_listener: bind: Can't assign requested address".
This looks like jail restriction. Unfort
Just so we have pointers in the public archives: alternatives to truss
are strace (in ports) and ktrace/kdump; and to obtain socket statistics,
try lsof (from ports, too) possibly with -i and optionally -n and/or -P
option.
___
freebsd-net@freebsd.org mai
- Original Message -
From: "Matthias Andree"
No I'm not its replying to the sender.
Yes you are, check your trace: The sendto address and port are the same
as the bound address.
This is a bug in truss it seems, Bjoern said he's gonna have a look at
it. Doesn
Am 25.06.2011 13:28, schrieb Steven Hartland:
>
> - Original Message - From: "Matthias Andree"
>
>
> I'm adding back in -java as based on you comments it may well be
> something in the jdk passing invalid values down to the kernel
> syscall.
>
On Sat, Jun 25, 2011 at 04:10:34PM +, Bjoern A. Zeeb wrote:
> On Jun 25, 2011, at 4:05 PM, Steven Hartland wrote:
>
> Hi,
>
> > - Original Message - From: "Bjoern A. Zeeb"
> >> Sigh, I'll need to look at that then.
> >> I think you are hitting:
> >> http://svnweb.freebsd.org/base?vie
On Jun 25, 2011, at 4:05 PM, Steven Hartland wrote:
Hi,
> - Original Message - From: "Bjoern A. Zeeb"
>> Sigh, I'll need to look at that then.
>> I think you are hitting:
>> http://svnweb.freebsd.org/base?view=revision&revision=220463
>> Can you apply that to your kernel, and see if that
- Original Message -
From: "Bjoern A. Zeeb"
Sigh, I'll need to look at that then.
I think you are hitting:
http://svnweb.freebsd.org/base?view=revision&revision=220463
Can you apply that to your kernel, and see if that helps?
Had to modify the patch slightly for 8.2-RELEASE but yes
>> This doesn't seen to be related to the above as 3800::10:0:0:0 is
>> not a v4-mapped-v6 address. Now there could be the problem really.
>> Do you know which address the code above was trying to talk with?
>
> I'm wondering if thats a decode error by truss, as it doesn't seem
> to corrispond to
- Original Message -
From: "Bjoern A. Zeeb"
To: "Steven Hartland"
Cc:
Sent: Saturday, June 25, 2011 10:27 AM
Subject: Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send
On Jun 24, 2011, at 9:11 PM, Steven Hartland wrote:
Hi,
We're trying
- Original Message -
From: "Matthias Andree"
I'm adding back in -java as based on you comments it may well be
something in the jdk passing invalid values down to the kernel
syscall.
The socket bind works fine and the packets sent to the server arrive
and are proce
it's old(er) and I have lately been tolded that openjdk has a problem.
> using truss we see the following:-
> socket(PF_INET6,SOCK_DGRAM,0)= 20 (0x14)
> setsockopt(0x14,0x29,0x1b,0x7edf0318,0x4,0x0) = 0 (0x0)
> setsockopt(0x14,0x,0x20,0x7edf031c,0x4,0x0) =
1 - 100 of 242 matches
Mail list logo