Rustls is an all-new TLS implementation written entirely in Rust. Its
memory-safe design makes it inherently resistant to attacks like
Heartbleed. Now, its creators are claiming that it outperforms
OpenSSL, too. But it lacks support for FreeBSD's ktls. I think that
adding ktls support would be
On Fri, Oct 11, 2024 at 1:05 AM Michael Tuexen
wrote:
>
> > On 11. Oct 2024, at 01:07, Alan Somers wrote:
> >
> > Can somebody please explain to me how the TCP measurement period
> > works? When does h_ertt decide to take a new measurement?
> >
> > Motivat
7;ve expected throughput to
recover once RTT did. My theory is that h_ertt never made a new
measurement. However, I cannot reproduce the problem using dummynet
on a local VM. With dummynet, as soon as I return the RTT to normal,
the throughput quickly recovers, as one would expect.
Grateful for any insights.
-Alan
On Wed, Aug 7, 2024 at 7:21 PM Navdeep Parhar wrote:
>
> On 8/7/24 7:06 AM, Alan Somers wrote:
> > I'd like to track the rate of packet loss for outbound packets from
> > some production servers. Obviously, that's impossible. But I think
> > that the rate
of NIC, or
congestion on one network segment but not another, or a regression in
the OS.
-Alan
Coexist how? Do you mean that one socket can use one and a different
socket uses the other? That makes sense.
On Thu, Jul 18, 2024 at 10:34 AM wrote:
>
> > On 18. Jul 2024, at 15:00, Junho Choi wrote:
> >
> > Alan - this is a great result to see. Thanks for experimenting.
On Wed, Jul 17, 2024 at 2:27 PM wrote:
>
> > On 17. Jul 2024, at 22:00, Alan Somers wrote:
> >
> > On Sat, Jul 13, 2024 at 1:50 AM wrote:
> >>
> >>> On 13. Jul 2024, at 01:43, Alan Somers wrote:
> >>>
> >>> I've b
I'm not sure what you're asking. BBR and RACK are two different
algorithms that accomplish the same thing. It wouldn't make sense to
use both on the same socket at the same time.
On Thu, Jul 18, 2024 at 7:01 AM Junho Choi wrote:
>
> Alan - this is a great resu
On Sat, Jul 13, 2024 at 1:50 AM wrote:
>
> > On 13. Jul 2024, at 01:43, Alan Somers wrote:
> >
> > I've been experimenting with RACK and BBR. In my environment, they
> > can dramatically improve single-stream TCP performance, which is
> > awesome. But p
rmine exactly what aspect of my pf configuration is responsible.
If so, can anybody suggest what changes would have to happen to make
the two compatible?
-Alan
On Mon, Jun 28, 2021 at 6:24 PM Rick Macklem wrote:
> The Linux NFS client now has a mount option "nconnect",
> which specifies that multiple TCP connections be created
> for an NFS mount, where RPCs are done on the connections,
> in a round robin fashion. (Alternating between the two TCP
> conne
On Mon, Mar 22, 2021 at 7:31 PM Kevin Bowling
wrote:
> Hi,
>
> I was talking with gnn and kevans on IRC about the tcp testsuite
> (https://github.com/freebsd-net/tcp-testsuite).
>
> Currently we maintain this in ports, although the way the port is set
> up doesn't make a lot of sense because the
On Wed, Mar 17, 2021 at 3:37 PM Rick Macklem wrote:
> Jason Breitman wrote:
> >Please review the details below and let me know if there is a setting
> that I should >apply to my FreeBSD NFS Server or if there is a bug fix that
> I can apply to resolve my >issue.
> >I shared this information with
gt; https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=17&view=markup
> )
> > [2]: [base Diff of /head/sys/net/route.c](
> https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839&r2=180840&;)
> >
> > /Alexander
>
I just want to say that I completely agree with this proposal.
-Alan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Make sure that dns resolution is working, forward and reverse.
On Wed, Feb 19, 2020, 2:53 PM Eric Joyner wrote:
> Have you tried turning off jumbo frames?
>
> - Eric
>
> On Tue, Feb 18, 2020 at 10:04 PM KIRIYAMA Kazuhiko
> wrote:
>
> > Hi, all
> >
> > I wonder how to work ixgbe in 1GbE network.
If you mount your NFS share with the -o intr option, then you can forcibly
unmount it when the server is unavailable. However, that's not generally
recommended. A lot of applications can't gracefully handle an error in
read(2) or write(2).
-Alan
On Thu, Jun 20, 2019 at 7:38 AM Anand Khoje wrote:
>
> Hi,
>
> We have a patch with fix for an issue raised by Microsoft :
> "FreeBSD 11.2 - Kernel panic when flapping network interfaces on and off" .
> The issue was observed when the customer was trying to flap interface on and
> off in a loop m
FreeBSD hosts in
> bhyve) does not have a DHCPv6 server. Still, the /etc/resolv.conf on
> IPv6-only hosts is successfully populated from the router. The latter
> is running only rtadvd with the following config:
>
>
> bridge0:rdnss=&
On Sat, Sep 29, 2018, 11:24 PM Victor Sudakov wrote:
> Alan Somers wrote:
> > >
> > > When running FreeBSD as an IPv6 host im SLAAC mode, is
> > > "rtsold_enable=YES" really necessary? I did not enable rtsold and IPv6
> > > s
your machine seems to work even without rtsold. However, SLAAC addresses
expire after a certain amount of time. rtsold will ask the router for a
new advertisement before your address expires. You aren't guaranteed to
have problems if you don't run rtsol
Well that's not very illuminating. I was wondering if it had weird mount
options or something. Are you sure that's why find is hanging? What
happens if you unmount and repeat the command?
On Thu, Aug 30, 2018 at 7:44 AM Gerrit Kühn wrote:
> On Thu, 30 Aug 2018 07:25:54 -060
On Thu, Aug 30, 2018 at 1:09 AM Gerrit Kühn wrote:
> On Fri, 15 Dec 2017 15:46:59 +0100 Gerrit Kühn
> wrote about Re: Fw: 100.chksetuid handging on nfs mounts:
>
> Hello all,
>
> Sorry for picking this up after such a long time...
>
> > > This is a known bug. It happens when an NFS filesystem i
x27;2602::'
option ip6prefixlen '24'
...
/etc/config/dhcp:
...
config dhcp 'lan'
option interface 'lan'
option limit '150'
option leasetime '12h'
option start '101'
option dhcpv6 '
t probably
triggers some special cleanup that didn't happen when you killed nfsd.
-Alan
On Sun, Apr 29, 2018 at 12:49 PM, Mark Raynsford via freebsd-net <
freebsd-net@freebsd.org> wrote:
> Hello.
>
> I've never used NFS, so this has been my first time setting it up. I
> ra
tcp_input() will correctly handle this case.
>
> --
> WBR, Andrey V. Elsukov
>
Yep. With that patch I can receive the redirected packet whether listening
on the unspecified address or on the LLA.
-Alan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Tue, Jan 23, 2018 at 11:41 AM, Eugene Grosbein
wrote:
> 24.01.2018 1:26, Alan Somers wrote :
>
> >> # ipfw add fwd ::1,5678 tcp from any to any 4000
> >> # nc -6 -l ::1 5678
> >>
> >> And from another host tried:
> >> # telnet -6 fc00::1 40
On Tue, Jan 23, 2018 at 10:39 AM, Andrey V. Elsukov
wrote:
> On 23.01.2018 19:17, Alan Somers wrote:
> >>> Unfortunately, pf currently lacks this capability. But it looks like
> it
> >>> could be added without breaking existing pf.conf syntax. Would this
> be
On Tue, Jan 23, 2018 at 7:16 AM, Andrey V. Elsukov
wrote:
> On 23.01.2018 03:35, Alan Somers wrote:
> > All of these problems could be solved if pf were able to redirect a
> > packet's destination port but not its address. You could bind the daemon
> > to INADDR_ANY
dress that the sender intended.
Unfortunately, pf currently lacks this capability. But it looks like it
could be added without breaking existing pf.conf syntax. Would this be a
good idea?
I don't use ipfw, but from reading the man page I believe that it has the
same problem.
-Alan
ream.
>
> Thanks,
> Ryan
>
I'm sorry for you Ryan; this sounds like a doozy. I know you said that the
customer is unwilling to change, but would they consider using a lagg(4)
interface? Using lagg with laggproto=failover is designed to solve exactly
this problem. They wouldn'
On Fri, Dec 15, 2017 at 6:34 AM, Gerrit Kühn
wrote:
> Hello all,
>
> As I got no response at all on freebsd-fs, I try again here...
>
>
>
> Begin forwarded message:
>
> Date: Tue, 5 Dec 2017 09:04:51 +0100
> From: Gerrit Kühn
> To: freebsd...@freebsd.org
> Subject: 100.chksetuid handging on nfs
First of all, 10.3-RELEASE-p2 is very old and has known security
vulnerabilities. Have you tried 10.3-RELEASE-p21 or even 10.4-RELEASE
?
On Thu, Sep 28, 2017 at 1:30 PM, Josh Gitlin wrote:
> Hi FreeBSD Gurus!
>
> We're having an issue with mbuf exhaustion on a FreeBSD server which was
> recentl
On Mon, Jul 17, 2017 at 11:19 AM, Eugene Grosbein wrote:
> 17.07.2017 23:46, Alan Somers wrote:
>
>>> So, the solution depends of kind of NAT you use.
>>
>> That's not 100% true. The web server is choosing which gateway to
>> use. As Grzegorz said, it
Ensure that in each jail, the web server starts with the correct
fib. For example, if you're using apache24, I think you can put
"apache24_fib=1" in /etc/rc.conf. Other web servers may require
something different, depending on how their RC scripts are written.
Happy hacking!
-Alan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Fri, Jun 16, 2017 at 10:35 AM, Steven Crangle <
ste...@stream-technologies.com> wrote:
> Hi Alan,
>
>
> Thanks for the fast reply.
>
> I actually think I had the fib 5 part appended to the line previously, but
> had somehow removed it in my repeated attempts! Eith
n't very
important. It's only used for packet forwarding. The fib of an
interface address is more important, and each address can have a
different fib, even when they share an interface. In order to set the
interface address fibs, do this:
ifconfig_manee_alias0="inet 185.100.174.221 n
asomers added a comment.
In https://reviews.freebsd.org/D10485#217709, @kczekirda wrote:
> @asomers
> this change exactly provides compatibility with PXE standard, because in
the PXE specification option 150 doesn't exist, but 66 does.
> netproto variable and option 150 appears in
asomers added a comment.
Even if this is the correct change to make, the old option must still be
supported for backwards compatibility with older PXE servers. Shouldn't there
be an accompanying documentation change? How will users know to change their
DHCP options?
REVISION DETAIL
http
This revision was automatically updated to reflect the committed changes.
Closed by commit rS315458: Constrain IPv6 routes to single FIBs when
net.add_addr_allfibs=0 (authored by asomers).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D9451?vs=26053&id=26359#toc
REPOSITORY
rS FreeBSD s
asomers accepted this revision.
asomers added inline comments.
This revision has a positive review.
INLINE COMMENTS
> jhujhiti_adjectivism.org wrote in nd6_nbr.c:265
> I think this is the only thing left to consider for this patch, but it seems
> to me that using the receiving interface's FIB is
asomers added inline comments.
INLINE COMMENTS
> jhujhiti_adjectivism.org wrote in icmp6.c:2147
> @asomers, can you confirm that M_GETFIB(m) is always correctly set to the FIB
> of the receiving interface?
No. According to the comment at the bottom of icmp6_error, it isn't, because
icmp6_refl
asomers added a comment.
Almost done. I think the only thing left is to delete all of the related
atf_expect_fail statements from fibs_test.sh, not just one.
INLINE COMMENTS
> jhujhiti_adjectivism.org wrote in nd6.c:1353
> This seems like a good idea. Is this new code what you had in mind?
asomers added inline comments.
INLINE COMMENTS
> jhujhiti_adjectivism.org wrote in nd6.c:1295
> > It's totally valid for an interface to have multiple addresses assigned,
> > each of which is on a different fib.
>
> Is this true? I'm not aware of a way this could happen. Interface routes are
>
asomers added a comment.
This review is starting to look pretty good. But in addition to the few
things I mentioned inline, there's one other change that you need to make: you
get to clear the `atf_expect_fail` statements from
tests/sys/netinet/fibs_test.sh.
INLINE COMMENTS
> jhujhiti_adj
t_iface
set skip on lo0
# Allow all traffic to the DMZ. Filtering happens on individual vnet
# interfaces
pass in on $dmz_iface
pass out on $dmz_iface
# Put the www jail in a DMZ. Don't allow outgoing traffic from it except for
# the webserver
pass out on $www_jail_iface proto tcp to $www_ip port $
asomers added a comment.
In https://reviews.freebsd.org/D9451#196364, @jhujhiti_adjectivism.org wrote:
> As I mentioned in the PR, this is my first attempt at kernel work, so I
very much appreciate the comments. I'll go ahead and update the review summary
at my next opportunity.
>
>
It sounds like overkill, but if you put each PPPoE client in a
separate VIMAGE jail, then each one will get a separate vnet
interface, with distinct MACs. They can be bridged to the same
physical interface.
-Alan
On Wed, Feb 8, 2017 at 11:06 AM, Alex Dupre wrote:
> Hi,
> I need to est
asomers requested changes to this revision.
asomers added a subscriber: bz.
asomers added a comment.
This revision now requires changes to proceed.
In addition to the issues I mentioned inline, could you please also update
the review summary to include the full commit message? Try to mention
asomers added a reviewer: bz.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9451
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: jhujhiti_adjectivism.org, #network, asomers, bz
Cc: bz, imp, ae, freebsd-net-list
___
asomers added a comment.
Awesome work jhujhiti. Unfortunately, I won't be able to test it until PR
216734 is fixed or I make myself another FreeBSD head machine. I'll try to do
that sometime next week.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9
Are you mounting NFS with UDP? That handles switching interfaces better
than TCP. You might be able to boot on em0, then configure lagg0 on em1,
then add em0 to the lagg.
On Feb 4, 2017 2:05 PM, "Sean Bruno" wrote:
>
>
> On 02/04/17 14:00, Konstantin Belousov wrote:
> > Look at reroot support,
Please do open a PR and CC me. As well as the stack trace, post your
lagg configuration, and, if you can determine it, the ports' state at
the time of the crash.
-Alan
On Sat, Jan 28, 2017 at 11:21 AM, Slawa Olhovchenkov wrote:
> I am got panic on recent stable:
>
> Fatal tr
e you using?
>
> Regards,
> Kristof
Under heavy load, pf can drop information from its state table. You
can try increasing state table limits to see if it helps the problem.
Read the "set limits" section of the pf man page.
-Alan
alc added a comment.
Have you looked at https://reviews.freebsd.org/D1945, in particular, the most
recent postings by sbahra_repnop.org? It's not clear to me that these changes
will address the problem described in sbahra_repnop.org's postings. That said,
your proposed changes do correct t
trace ping
8.8.8.8; kdump" and searching for "bind". Once you know that, you can
try playing with ping's "-S" option to set different local addresses.
-Alan
On Tue, Sep 13, 2016 at 5:21 PM, wrote:
> Here is the nestat -rn output:
>
>
>
> setfib -2 netst
On Tue, Sep 13, 2016 at 4:41 PM, wrote:
> Hi,
>
> in r305382 on my router-box I see some issue with ICMP and UDP in IPv4 in
> non-default fib spaces. PF is disabled. For example,
>
> UDP:
>
> setfib -2 host -vvv www.cisco.com 8.8.8.8
> Trying "www.cisco.com"
> ;; connection timed out; no servers
hose speeds I would recommend link aggregation with LACP. It has
less lock contention than round-robin and should give you fine
distribution with 40K streams.
-Alan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Tue, Aug 2, 2016 at 2:49 AM, Gerrit Kühn wrote:
> Hi all,
>
> I already reported this issue here a year ago and unfortunately was not
> able to fix it back then. Now I had another run at it, using two recent
> 10.3-machines with a direct 10G link. I still see nfs is painfully
> slow (around 20-
On Sun, Jun 26, 2016 at 3:37 AM, wrote:
> Hello.
>
> On 2016-06-25T18:13:18 -0600
> Alan Somers wrote:
>
>> On Sat, Jun 25, 2016 at 4:05 PM, wrote:
>> > I'm not using vnet jails. I'm actually just trying to get filtering of
>> > outbound traf
On Sat, Jun 25, 2016 at 4:05 PM, wrote:
> Hello!
>
> On 2016-06-25T23:46:36 +0200
> Marko Zec wrote:
>>
>> if_bridge(4) works only with ethernet interfaces, and lo(4) isn't such a
>> thing.
>
> Has this always been the case? I'm almost certain that I set up jails
> with extra loopback devices th
ppens on individual vnet
# interfaces
pass in on $dmz_iface
pass out on $dmz_iface
# Put the www jail in a DMZ. Don't allow outgoing traffic from it except for
# the webserver
pass out on $www_jail_iface proto tcp to $www_ip port $www_services keep state
# Uncomment next line to allow o
access already, but I'm very ignorant of what's going on
> here.
>
> I don't see any other driver with locks in its get_counter()
> functions, so I'm not sure what the best course of action here is.
>
> Sean
I don't know the best answer either. But while yo
On Wed, Jun 8, 2016 at 4:43 AM, Eugene M. Zheganin wrote:
> Hi.
>
> (first part of the message is describing why I need this, so impatient
> people can proceed to th 'setfib 2 route delete' part directly).
>
> I have a FreeBSD router connected to the ISP network, which is organized
> according to
On Wed, May 4, 2016 at 11:49 PM, Julian Elischer wrote:
> On 4/05/2016 11:59 PM, Shawn Debnath wrote:
>
>> On 05/04, Alan Somers wrote:
>>
>>> Then maybe it's the bridged aspect that's screwing me up. Is there a
>>> guide
>>> for using pf o
On Wed, May 4, 2016 at 4:23 AM, Kristof Provost wrote:
>
> > On 04 May 2016, at 04:55, Alan Somers wrote:
> >
> > Is there any documentation on how to run pf on a host, using it to
> control
> > access to vimage jails? I see that only ipfw can be run from _in
,
you wouldn't trust the jail to control its own firewall. Another would be
to use jails as a poor man's DMZ.
-Alan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail
What you described doesn't work in FreeBSD, and there's even an open bug
for it. But as Julian described, you should see if VIMAGE will work for
you.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189088
-Alan
On Wed, Apr 20, 2016 at 4:19 AM, Julian Elischer wrote:
> On 20/04
Would it be more useful to log the NIC's interrupt rate using "vmstat -i"?
On Thu, Mar 17, 2016 at 8:25 AM, Pieper, Jeffrey E <
jeffrey.e.pie...@intel.com> wrote:
> Basically what we do is run TCP tx traffic using various message sizes
> with TSO enabled, while logging throughput and CPU usage, t
lene Kvello-Aune
>
This sounds like an awesome idea. ifconfig is my least favorite program to
parse. BTW, are you aware of the ongoing libxo work? That effort fixes
the problem of parsing the output of utilities like ifconfig, though it
doesn't do anything to simplify their maintenance.
-Alan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
It sounds like at least two drivers have the ability, and at least
three people have the interest. I'll put this on my list. I'm not
sure if I'll get to work on it soon, though.
-Alan
On Fri, Jul 17, 2015 at 9:40 AM, Eric Joyner wrote:
> ixl(4) will list all of the supporte
is? If so,
would anybody else be interested? If so, should I add it to the
"ifconfig -v" output?
-Alan
___
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"
I don't know. But I do know that if you delete the lo0 route, then
you can't talk to services running on localhost. On a system with
multiple fibs, that might conceivably be useful.
On Thu, Jun 18, 2015 at 4:06 AM, Eugene M. Zheganin wrote:
> Hi.
>
> Why we still have this anachronism - routes
carefully.
Many server processes, such as ntpd, have reduced security for
connections coming over 127.0.0.1. Whether or not it is appropriate
to add those routes depends on why you are using a jail.
-Alan
>
>
> * tcpdump on em0
> Source Destination Protoco
On Mon, Dec 29, 2014 at 10:19 AM, Bjoern A. Zeeb wrote:
>
>> On 29 Dec 2014, at 16:03 , Alan Somers wrote:
>>
>> On Sun, Dec 28, 2014 at 3:16 AM, Bjoern A. Zeeb wrote:
>>>
>>> People simply broke it (again). Please file a bug report. You may
>
dbeef and cafebabe) leak between the FIBs; both prefixes that I add are
>> listed in both FIBs (as well as the link-local stuff).
>>
>> According to:
>>
>>
>> https://www.freebsd.org/news/status/report-2012-01-2012-03.html#Multi-FIB:-IPv6-Support-and-Other-Enhance
On Wed, Dec 17, 2014 at 10:11 PM, Craig Rodrigues wrote:
> On Wed, Dec 17, 2014 at 9:08 PM, Craig Rodrigues
> wrote:
>>
>>
>>
>> On Wed, Dec 17, 2014 at 5:36 PM, David P. Discher wrote:
>>>
>>>
>>> Yeah, Alan - will do ... if I decided t
physical drives.
>
> If I have to add a physical drive (that's possible, but it will be a
> slow drive sitting on my shelf) then I need to wait until I get back
> from holiday travels.
You don't need to screw with your pools at al
On Wed, Dec 17, 2014 at 6:09 PM, David P. Discher wrote:
>
> On Dec 15, 2014, at 11:33 AM, Alan Somers wrote:
>
>> On Sun, Dec 14, 2014 at 6:23 PM, David P. Discher wrote:
>>>
>>> So, I think I’ve identified the issue. In sys/net/ieee8023ad_lacp.c,
>&g
On Sun, Dec 14, 2014 at 6:23 PM, David P. Discher wrote:
>
> So, I think I’ve identified the issue. In sys/net/ieee8023ad_lacp.c,
> lacp_pdu_input() has a sanity check :
>
> if (m->m_pkthdr.len != sizeof(*du)) {
> goto bad;
> }
>
> I added some debugging informati
will work to the list, but here is a pcap attached
> em1 (sudo tcpdump -i em1 -s 0 -w lacp.pcap). Attaching to the lagg0 with
> tcpdump, filters out the freebsd’s LACP packets, but still sees the TP-Link’s
> packets.
Did you remember to configure the switch to use LACP on those por
anks
I'm not sure what you're looking for. If you want to see problems
reported by other users, check https://bugs.freebsd.org/bugzilla/ .
If you want to see changes to FreeBSD source code that haven't yet
been merged to your released version, check
https://svn
On Mon, Oct 13, 2014 at 3:16 AM, Harald Schmalzbauer
wrote:
> Bezüglich Alexander V. Chernikov's Nachricht vom 13.10.2014 10:42
> (localtime):
>> On 13.10.2014 12:35, Harald Schmalzbauer wrote:
>>> Bezüglich Julian Elischer's Nachricht vom 23.04.2014 09:55
>>> (localtime):
> ...
yes, we ma
he
> reasonable thing to do.
Sounds interesting. I'll give it a thorough review soon, but probably
not today.
-Alan
___
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"
On Tue, Aug 26, 2014 at 1:51 PM, Mark Johnston wrote:
> On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote:
>> On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote:
>> > On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin wrote:
>> > > On Friday, Augu
pr=181741
>> > Please MFC into 9.X
>> >
>> > Description of the problem is within PR.
>> >
>> > Thanks,
>> > Yuri
>>
>> Hello,
>>
>> I guess this fix should make it into 10.1.
>> Can someone check please?
>
>
PACKET Unix domain sockets (or even
SOCK_STREAM if sending ancillary data). You could try the attached
patch that Alon and I are working on.
Even if the patch doesn't fix your problem, it would be interesting to
see the output of "vmstat -z".
-Alan
Index: sys/kern/uipc_usrreq.c
==
On Tue, Jun 24, 2014 at 3:08 AM, Gleb Smirnoff wrote:
> On Mon, Jun 23, 2014 at 10:44:58AM -0600, Alan Somers wrote:
> A> > On Fri, Jun 20, 2014 at 12:15:21PM -0700, Navdeep Parhar wrote:
> A> > N> Revision 264905 and 266860 that followed it seem to leak ifa
dn't use void * casts, but instead specify explicit member:
>
> ifa_free(&ia->ia_ifa);
>
> Apart from that it, the patch looks entirely correct and plugging a leak.
> Thanks!
I still don't see how this patc
!= NULL) {
> /*
I don't think this is quite right. ip_output() references ia at lines
366, 433, 630-637, 674, and 675. All of those references have NULL
checks, so your patch won't cause a use-after-free bug, but I think
that the patch mig
On Wed, May 7, 2014 at 5:43 PM, Marcelo Gondim wrote:
> Em 07/05/14 15:57, Marcelo Gondim escreveu:
>
>> Em 07/05/14 15:18, Alan Somers escreveu:
>>>
>>> On Wed, May 7, 2014 at 9:47 AM, Marcelo Gondim
>>> wrote:
>>>>
>>>> H
On Wed, May 7, 2014 at 9:47 AM, Marcelo Gondim wrote:
> Hi all,
>
> I'm having this problemon my FreeBSD 10-STABLE:
>
> (root@rt01)[~]# arp -an|grep 187.xxx.216.252
> ? (187.xxx.216.252) at 5c:e0:f6:00:11:29 on vlan4 permanent [vlan]
>
> (root@rt01)[~]# arp -d 187.xxx.216.252
> delete: cannot loca
explanation and patch are at
http://www.freebsd.org/cgi/query-pr.cgi?pr=189003&cat= . Can somebody
please review the patch?
-Alan
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any
On Thu, Apr 24, 2014 at 5:50 PM, Chris Smith wrote:
> On 25/04/14 11:15, Alan Somers wrote:
>>
>> On Thu, Apr 24, 2014 at 5:00 PM, Chris Smith
>> wrote:
>>>
>>> On 24/04/14 18:24, Alexander V. Chernikov wrote:
>>>>
>>>> On 24.
orks as expected (changes
>> interface fib to chosen one and announce interface route and host route
>> in this particular fib) - does this sound OK to you?
>
> Yes this sounds good.
>
> If I'm not mistaken the interface FIB only makes sense when the system is
>
On Thu, Apr 24, 2014 at 12:24 AM, Alexander V. Chernikov
wrote:
> On 24.04.2014 01:56, Chris Smith wrote:
>> On 23/04/14 19:55, Julian Elischer wrote:
>>> On 4/23/14, 4:38 AM, Nikolay Denev wrote:
On Tue, Apr 22, 2014 at 5:37 PM, Harald Schmalzbauer
wrote:
> Hello,
>
> here,
roblem without using
multiple FIBs, I will suggest a set of patches that may help you. I
will need
1) Your ifconfig_bge0 etc lines from /etc/rc.conf
2) The output for "setfib X netstat -rn -f inet" for each fib in use.
3) The rc.conf lines for any manually create routes that you'r
top the background dhclient
process. Then run "dhclient -d" to force it to remain in the
foreground, and see if it prints any useful debugging info. It might
also be useful to run "tcpdump -i em0 host
10.23.192.1" in another terminal.
>
> Respectfully,
>
>
ntrol printing of dropped input
packets as well as dropped output packets.
OTOH, this behavior has been around for more than 4 years, and some
scripts may rely on it. At the very least, the man page should be
updated to reflect r199803.
What do you think? Does the likelihood of
Replace 4.4BSD Lite's unix domain socket backpressure hack with
a cleaner mechanism, based on the new SB_STOP sockbuf flag. The
old hack dynamically changed the sending sockbuf's high water
mark whenever adding or removing data from the receiving
sockbuf. I
On Thu, Aug 29, 2013 at 3:40 PM, T.C. Gubatayao
wrote:
> On Aug 29, 2013, at 4:21 PM, Alan Somers wrote:
>
>> They're faster, but even with this change, jenkins_hash is still 6 times
>> slower than FNV hash.
>
> Actually, I think your test isn't accurately simul
1 - 100 of 137 matches
Mail list logo
