On 5/20/2024 11:54 AM, Mike Karels wrote:
That sounds like an outright bug. Looks like it was true in 14.0 as well.
Is there a bug report? I couldn't find one.
I didnt open one. Wasnt sure if it the change was a deliberate one or on the
wrong side of POLA. To me it feels unnecessary to have
On 20 May 2024, at 10:15, mike tancsa wrote:
> On 5/19/2024 8:59 PM, Mike Karels wrote:
>> On 19 May 2024, at 18:29, mike tancsa wrote:
>>
>>> On 5/18/2024 10:49 AM, Mike Karels wrote:
>>>> I have no networking changes at all in the 14.1 release notes.
On 5/19/2024 8:59 PM, Mike Karels wrote:
On 19 May 2024, at 18:29, mike tancsa wrote:
On 5/18/2024 10:49 AM, Mike Karels wrote:
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be mentioned? Feel free to reply to me individually.
Not sure
On 19 May 2024, at 18:29, mike tancsa wrote:
> On 5/18/2024 10:49 AM, Mike Karels wrote:
>> I have no networking changes at all in the 14.1 release notes. Is there
>> anything that should be mentioned? Feel free to reply to me individually.
>>
> Not sure if appropriat
On 5/18/2024 10:49 AM, Mike Karels wrote:
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be mentioned? Feel free to reply to me individually.
Not sure if appropriate or not, but when going to 13.x to 14.x, not all
vlan configs work now in rc.conf
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be mentioned? Feel free to reply to me individually.
Thanks,
Mike
On 26 Apr 2024, at 23:02, Bakul Shah wrote:
> On Apr 26, 2024, at 8:41 PM, Warner Losh wrote:
>>
>>
>>
>> On Fri, Apr 26, 2024, 9:33 PM Bakul Shah wrote:
>>
>>
>>> On Apr 26, 2024, at 5:02 PM, Mike Karels wrote:
>>>
>>> On 26 Ap
On 26 Apr 2024, at 18:06, Warner Losh wrote:
> On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
>
>> On 26 Apr 2024, at 15:49, Mike Karels wrote:
>>
>>> On 26 Apr 2024, at 15:01, Warner Losh wrote:
>>>
>>>> This has to be a FAQ
>>>>
On 26 Apr 2024, at 15:49, Mike Karels wrote:
> On 26 Apr 2024, at 15:01, Warner Losh wrote:
>
>> This has to be a FAQ
>>
>> I'm porting a program from Linux, I often see an error like:
>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in
f the structure, so I don't see a problem with exposing them all even
in a POSIX environment.
I would have no objection to exposing all four definitions, especially
if Linux apps use them.
Mike
4 got the interface wrong
when the alias was on the loopback.)
Anyone know why -ifa is ineffective in 14.0 and -current? It could
be fallout from netlink.
The documentation is weak at best; route(8) says only "the -ifp or -ifa
modifiers may be used to determine the interface or interface
into this problem in layered networks where the next hop
is often RFC 1918 addrs. I bind applications to internal NICs that have
addresses that have routing to/from.
---Mike
ression.
Ideally, tcphpts could enable this automatically when it starts to be
used (enough?), but a sysctl could select auto/on/off.
Mike
> Best regards
> Michael
>>
>> Thanks all!
>> Really happy here :)
>>
>> Cheers,
>>
>> Nuno Teix
On 21 Nov 2023, at 19:57, Mike Karels wrote:
> ... My newer code prints "drivername: igb1" at the end of
> the list of values for "ifconfig $interface-name" or "ifconfig -a"
> if the -D option is given. I decided that it was better to be able
> to ge
On 21 Nov 2023, at 19:35, Jamie Landeg-Jones wrote:
> Mike Karels wrote:
>
>> I have a proof of concept that makes the presumed original name
>> (driver name + unit number) available to ifconfig, which prints
>> the string with everything else in the standard output
On 21 Nov 2023, at 12:16, Mina Galić wrote:
> Hi Mike,
>
>> Mina, do you care about epair, or is the behavior I described sufficient
>> for your purposes?
>
> I do deeply care about epair, but for me, ifinfo does the
> right thing for me:
>
> root@irc:~ # ifinfo |
On 21 Nov 2023, at 0:43, Franco Fichtner wrote:
>> On 20. Nov 2023, at 23:06, Mike Karels wrote:
>>
>> On 20 Nov 2023, at 15:16, Franco Fichtner wrote:
>>
>>> All that is really missing is a way to print it via ifconfig command.
>>
>> That is t
; I just tested it. It also has problems with
epair. Maybe that isn't an issue for this purpose. I hate to invent
something new when there is something already existing that solves
most of the problem.
Mike
> Cheers,
> Franco
On 20 Nov 2023, at 14:56, Kristof Provost wrote:
> On 20 Nov 2023, at 21:29, Mike Karels wrote:
>> On 19 Nov 2023, at 15:35, Mina Galić wrote:
>>> Hi Zhenlei,
>>>
>>>
>>>> Since it is just for physical devices, may I propose to have the driver
&g
ing the same
option. It should probably be an option rather than a keyword,
so something like this:
# ifconfig -N interface-name
igb 1
#
Or the unit number could be on a separate option.
Comments?
Mike
> Unrelatedly, I don't see anything in ure(4) mentioning that if_ure
> devices will be named "ue".
> Don't we usually document such deviation from the norm?
>
>
> Kind regards,
>
> Mina
On 19 Nov 2023, at 13:13, Mina Galić wrote:
> Hi Mike,
>
>> The kernel has a driver name for each interface, which looks like it
>> doesn't change currently in most cases. There is a kernel accessor
>> function, but I don't think it is exported to user space now. It co
which looks like it
doesn't change currently in most cases. There is a kernel accessor
function, but I don't think it is exported to user space now. It could
be, though. Would this be sufficient for your purposes? There is also
a unit number, which could also be exported.
Mike
d more approval and if yes, how can I get that?
>
> Regards,
> Ronald.
The change looks good to me now. I think it would be good if someone who
works on USB looked at it too. I am willing to approve the change; I think
you can commit it with approval.
Mike
the code and reading the history of changes
between stable/13 and stable/14 to see if there are something obvious,
but more insights from others would be appreciated :)
[/me takes a in the dark]
maybe something like net.inet.ipsec.filtertunnel=1 is needed now ?
---Mike
the same.
Just curious, how does iperf3 perform in comparison ?
---Mike
04b3a8 at amd64_syscall+0x138
#16 0x8101da7b at fast_syscall_common+0xf8
Mike
auses a reset, and the session gets cleaned up. I use a longer keepidle
value for other reasons.
Mike
justification
> to me.
I have used trpt, but not for many years. It was done before tcpdump
as well. Its time has long since gone.
Mike
> --
> Gleb Smirnoff
On Oct 17, I wrote:
> On Wed, 28 Sep 2022, Konstantin Belousov wrote:
> > On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote:
> > > I recently noticed the following behavior:
> > >
> > > % ping6 redrock
> > > ping6: Name does not resolve
On Wed, 28 Sep 2022, Konstantin Belousov wrote:
> On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote:
> > I recently noticed the following behavior:
> >
> > % ping6 redrock
> > ping6: Name does not resolve
> > % host redrock
> >
On 27 Sep 2022, at 17:41, Viktor Dukhovni wrote:
> On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote:
>
>> The first error message is misleading, because the name *does* resolve,
>> but has no record, and it is the same error message as for a name
>> t
internally and then translates. But it will benefit
from greater accuracy in other cases as well (e.g. "out of memory"
rather than "Name does not resolve").
Comments? I have a change in progress, but wanted to float the idea
before I finish it and put it into review.
Mike
sion first.
Changes are also being made in Linux, although I don't know their state.
Note that there is a related proposal and change to allow use of the
lowest host on a network/subnet [4]. This change was essentially a bug
fix for FreeBSD, and is already in -current and 13.1-RELEASE.
On 2 Jul 2022, at 10:11, Mike Karels wrote:
On 1 Jul 2022, at 4:11, Ronald Klop wrote:
Van: George Michaelson
Datum: vrijdag, 1 juli 2022 00:50
Aan: "Rodney W. Grimes"
CC: mike tancsa , Chris Ross
, freebsd-net@freebsd.org
Onderwerp: Re: Netstat -i 5-character interface n
On 1 Jul 2022, at 4:11, Ronald Klop wrote:
Van: George Michaelson
Datum: vrijdag, 1 juli 2022 00:50
Aan: "Rodney W. Grimes"
CC: mike tancsa , Chris Ross
, freebsd-net@freebsd.org
Onderwerp: Re: Netstat -i 5-character interface name length?
Is there a reason (avoid bikeshedding)
in /etc/csh.cshrc
---Mike
significant impact,
sometimes they even reduce performance. So I m hoping when this goes into
production the scheduler will be sane enough to do the same, but we shall see.
Thanks.
On Fri, 17 Jun 2022 11:03:04 -0400 Dave Cottlehuber
wrote ---
On Fri, 17 Jun 2022, at 02:38, Mike
Responding to parts of two emails:
On 27 Jun 2022, at 7:41, Marek Zarychta wrote:
W dniu 27.06.2022 o 13:44, Dave Cottlehuber pisze:
I've found a workaround for this issue, but don't understand why this
occurs. Reading RFC1122 has left me none the wiser. What am I
missing?
Is this a
receiver
iperf Done.
Thank You!
On Thu, 16 Jun 2022 17:00:25 -0400 Alexander V. Chernikov
wrote
> On 16 Jun 2022, at 21:48, Mike Jakubik
> <mailto:mike.jaku...@swiftsmsgateway.com> wrote:
>
> After multiple tests and tweaks i believe the issue is not with
After multiple tests and tweaks i believe the issue is not with the HW or Numa
related (Infinity fabric should do around 32GB) but rather with FreeBSD TCP/IP
stack. It's like it cant figure itself out properly for the speed that the HW
can do, i keep getting widely varying results when testing.
] 0.00-30.00 sec 29.4 GBytes 8.42 Gbits/sec 3863 sender
[ 5] 0.00-30.00 sec 29.4 GBytes 8.42 Gbits/sec receiver
On Tue, 14 Jun 2022 10:21:51 -0400 Mike Jakubik
wrote
Disabling rx/tx pause seems to produce higher peaks.
[root@db-02
lem is, if it's
PCI backpressure or something else.
sysctl -a | grep diag_pci_enable
sysctl -a | grep diag_general_enable
Set these two to 1, then run some traffic and dump all mce sysctls:
sysctl -a | grep mce > dump.txt
--HPS
Mike Jakubik
https://www.swiftsmsgateway.com/
Yes, it is the default of 1500. If I set it to 9000 I get some bizarre network
behavior.
On Tue, 14 Jun 2022 09:45:10 -0400 Andrey V. Elsukov
<mailto:bu7c...@yandex.ru> wrote
Hi,
Do you have the same MTU size on linux machine?
Mike Jakubik
sec 31.1 GBytes 8.91 Gbits/sec 1330 sender
[ 5] 0.00-30.00 sec 31.1 GBytes 8.91 Gbits/sec receiver
Thanks.
On Mon, 13 Jun 2022 14:41:05 -0400 Santiago Martinez
<mailto:s...@codenetworks.net> wrote
Mike Jakubik
.77 Gbits/sec 244 sender
[ 5] 0.00-30.00 sec 30.6 GBytes 8.77 Gbits/sec receiver
More data can be found @
https://forums.freebsd.org/threads/poor-performance-with-stable-13-and-mellanox-connectx-6-mlx5.85460/
Mike Jakubik
https://www.swiftsmsgateway.
[bhyve options: -c 1 -m 2G -Hwl
> bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CSM.fd -U
> ac3dafab-bedb-11ec-b24d-1402ec690a80 -u]
> May 15 17:55:25: [bhyve devices: -s 0,hostbridge -s 31,lpc -s
> 4:0,virtio-blk,/vms/utm/disk0.img -s
> 5:0,virtio-net,tap0,mac=58:9c:fc:07:c0:6
Kristof wrote:
> On 18 Mar 2022, at 19:02, Mike Karels wrote:
> > It looks like the IPv4 multicast code has not been fully converted to
> > use epochs. I installed this week's snapshot of -current, configured
> > and started mrouted, and started rwhod -m. The s
adding epoch handling in add_mfc(), and that seems to work.
The alternative would be to do it in Xip_mrouter_set() so it would cover
all the calls. Any opinions?
Mike
(kgdb) bt
#0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=textdump@entry=1
uspect the list in altq(4) is rather incomplete/out-of-date.
> thanks,
> --
> J.
Mike
https://reviews.freebsd.org/D32715
systat https://reviews.freebsd.org/D32720
Thanks,
Mike
Rod wrote:
> > Jamie wrote:
> >
> > > Oleksandr Kryvulia wrote:
> >
> > > > 04.11.21 01:01, Mike Karels wrote:
> > > > > I have a pending change to stop using class A/B/C netmasks when
> > > > > setting
> &
Jamie wrote:
> Oleksandr Kryvulia wrote:
> > 04.11.21 01:01, Mike Karels wrote:
> > > I have a pending change to stop using class A/B/C netmasks when setting
> > > an interface address without an explicit mask, and instead to use a
> > > default
> >
of the mask on a loopback address?
Thanks,
Mike
://reviews.freebsd.org/D32714
sockstathttps://reviews.freebsd.org/D32715
sendmailhttps://reviews.freebsd.org/D32716
Thanks,
Mike
et_makeaddr() is
> > > > almost as bad; it works almost by accident as long as a mask is a
> > > > multiple of 8 bits. I'd like to remove their use from the base
> > > > system. Unfortunately, I have no idea how much other software uses
> > > > the
t; system. Unfortunately, I have no idea how much other software uses
> > them. We can at least document them as deprecated and unsafe.
> Wrap them in a depricating macro, the do a EXP-RUN with that macro
> defined, should get a good idea of that fallout from that.
EXP-RUN?
> I do believe Linux still defines the CLASS macros.
It does. There are a surprising number of references even in base.
Mike
their use from the base
system. Unfortunately, I have no idea how much other software uses
them. We can at least document them as deprecated and unsafe.
Mike
Bjoern wrote:
> On 12 Sep 2021, at 15:25, Mike Karels wrote:
> > Long ago (4.2BSD), the IP broadcast address was the lowest address on
> > a
> > network, the one with a host part of 0. In RFC1122, the broadcast
> > address
> > was standardized using a host
of the discussion in https://reviews.freebsd.org/D19316.
Comments are welcome on the review. I will wait a couple of days
for comments before proceeding. I am also interested in comments on
whether this should be MFC'ed to 13-stable after a suitable delay.
Mike
Hi,
Is this an issue in HEAD only ? Or is it something that needs to be
MFC'd ?
---Mike
On 10/28/2020 4:27 PM, Alexander V. Chernikov wrote:
> 28.10.2020, 20:25, "Alexander V. Chernikov" :
>> 28.10.2020, 18:34, "Maxime Villard" :
>>> In icmp6_not
> However, I think that route and netstat are sufficiently extensible to
> > add additional facilities, as they have been so far. One suggestion,
> > though, would be to preserve the general strategy of using "route verb ...",
> > e.g. "route add nhop ..." rather t
r to existing functionality to share a tool.
Similarly, if possible I would prefer to see --libxo json rather than -j.
Mike
> I feel like there is a need of some cli tool that provides the ability to
> easily extend it by having separate namespaces for each sub-command (hel
more proxy connections
than the pool of ephemeral ports as long as the destinations were different.
Mike
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail
ve enough spare CPU to do
some netflow analysis on the box ? Or maybe take some periodic snapshots
of the interface stats and compare normal to bad periods via sysctl -A
dev.cxl | grep "_frames_"
Good luck!
---Mike
___
freebsd-net@freeb
> Hi All
> Still trying to run FreeBSD-box as multicast router :-)
> FreeBSD upgraded to 11.3-STABLE #1 r354778. netstat pacth by Mike Karels
> manually applied and netstat -gs looks OK now.
> Latest pimd version 3.0beta1 downloaded from git and configured. While
> c
> On 06/11/2019 05:41, Mike Karels wrote:
> >> On 05/11/2019 09:09, Mike Karels wrote:
> >>>> On 03/11/2019 08:22, Mike Karels wrote:
> >>>>>>>>> Hi All
> >>>>>>>>>
> >>>>>>>>&g
> On 05/11/2019 09:09, Mike Karels wrote:
> >> On 03/11/2019 08:22, Mike Karels wrote:
> >>>>>>> Hi All
> >>>>>>>
> >>>>>>> I have (noob) questions about multicast routing under FreeBSD.
> >>>&
> On 03/11/2019 08:22, Mike Karels wrote:
> >>>>> Hi All
> >>>>>
> >>>>> I have (noob) questions about multicast routing under FreeBSD.
> >>>>>
> >>>>> I have FreeBSD box with two (or more) multicast
> by pimd or another multicast routing program. Is it not working? It sounds
> > like you are very close.
> Could it be sysctl net.inet.ip.forwarding? Does that still apply to mroutes?
No, they are separate. The test is just whether MROUTING is enabled, and
whether
s installed
by pimd or another multicast routing program. Is it not working? It sounds
like you are very close.
> > Victor Gamov
> --
> Rod Grimes rgri...@freebsd.org
Mike
___
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"
> is to hold a write lock in this path. I haven't even compile-tested
> the patch below yet, but would anybody have any objections to this
> approach?
I think a write lock is definitely required. The approach seems fine.
Mike
> diff --git a/sys/netinet/udp_usrreq.c b/
d48 31e4c98a 3ae8c8ed
BTW, if you use a static psk, does not the above line essentially give
someone with access to the ESP traffic a way to decode your traffic ?
---Mike
> A: hmac-sha2-256 9f1a4188 7849ad94 41cfd974 a5e0570a cc7c54a5 c16f5
e the gateway either, for obvious reasons).
I'll take a look at the review.
Mike
___
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 21 Aug 2017, at 1:11, Gopakumar Pillai wrote:
Looks like later FreeBSD already has some amount of queueing from what
Oleg has pointed out:
$ sysctl net.link.ether.inet.maxhold
net.link.ether.inet.maxhold: 1
As Mike mentioned, my fix looks into a logical IP packet. And it keeps
only one
On 19 Aug 2017, at 4:00, Julian Elischer wrote:
On 18/8/17 11:33 am, Mike Karels wrote:
Another $.02 (inline):
On 17 Aug 2017, at 18:39, Gopakumar Pillai wrote:
Thank You Bjoern. Could you please point me to the RFC?
I don’t know if there is anything more recent than RFC1122
them.
A large UDP packet would btw see the same behaviour to your ping.
There’s no guarantee any of these packets will not be dropped
anywhere
on the network, so we can as well.
Just my 2ct
/bz
Mike
___
freebsd-net@fre
no memory leaks (that I can see anyways).
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.t
suggest
testing that also.
Mike
___
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"
kets or dropping some ?
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-net@freebsd.o
On 23 Mar 2017, at 9:02, Andrey V. Elsukov wrote:
On 20.03.2017 03:46, Mike Karels wrote:
The context has gotten messy here, so I’m going to break down and
top-post.
I started review https://reviews.freebsd.org/D10059 with a fix for
the
reference-count leak.
It changes the semantics so
for V6 in a separate review when this
one is done.
Andrey, could you try your iperf test again? Thanks,
Mike
On 14 Mar 2017, at 21:39, Mike Karels wrote:
On 14 Mar 2017, at 3:50, Andrey V. Elsukov wrote:
On 14.03.2017 11:40, Mike Karels wrote:
Hi All,
Eugene has reported
On 3/16/2017 2:15 AM, Ermal Luçi wrote:
>
>
> On Wed, Mar 15, 2017 at 7:33 PM, Kristof Provost <kris...@sigsegv.be
> <mailto:kris...@sigsegv.be>> wrote:
>
> On 15 Mar 2017, at 22:10, Mike Tancsa wrote:
>
> On 3/15/2017 4:28 AM, Kristof Provost
wise nat via pf on ppp connections would not work either.
I will try and setup a most simple test vm
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario C
On 14 Mar 2017, at 3:50, Andrey V. Elsukov wrote:
> On 14.03.2017 11:40, Mike Karels wrote:
>>> Hi All,
>>
>>> Eugene has reported about the following assertion in the ARP code:
>>> http://www.grosbein.net/freebsd/crash/arp-kassert.txt
>>
>>
working copy)
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include
@@ -431,4 +432,6 @@
out:
if (rt != NULL)
RTFREE(rt);
+ if (rin6.ro_lle)
+ LLE_FREE(rin6.ro_lle);
}
Thanks,
Mike
__
initiated TO openvpn
clients for some reason ?
eg
nat pass log on tun200 from 10.241.0.0/23 to 10.211.1.28 -> (tun200)
will not work. An IP address with a source address of 10.241.0.6 for
example, will not get natted as it travels to 10.211.1.28 on tun200 to
the client on OpenVPN
---M
would
expect.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-net@freebsd
On 3/7/2017 9:08 PM, Navdeep Parhar wrote:
> On Tue, Mar 7, 2017 at 5:46 PM, Mike Tancsa <m...@sentex.net> wrote:
>
>>
>> # dmesg | grep netm
>> netmap: loaded module
>> vcxl0: netmap queues/slots: TX 2/1023, RX 2/1024
>> vcxl0: 1 txq, 1 rxq (NIC)
On 3/7/2017 5:07 PM, Navdeep Parhar wrote:
> On Tue, Mar 7, 2017 at 1:53 PM, Mike Tancsa <m...@sentex.net> wrote:
> ...
>>
>> Using netsend, I cant seem to blast through a single flow of packets
>> greater than 800Kpps without packet loss. Can you point m
nofldtxq: 1
dev.vcxl.0.nofldrxq: 1
dev.vcxl.0.rss_size: 64
dev.vcxl.0.first_txq: 4
dev.vcxl.0.first_rxq: 4
dev.vcxl.0.ntxq: 1
dev.vcxl.0.nrxq: 1
dev.vcxl.0.viid: 1226
dev.vcxl.0.%parent: cxl0
dev.vcxl.0.%pnpinfo:
dev.vcxl.0.%location:
dev.vcxl.0.%driver: vcxl
dev.vcxl.0.%desc: port 0 vi 1
--
(r314848).
---Mike
t5nex0@pci0:2:0:4: class=0x02 card=0x1425 chip=0x54071425
rev=0x00 hdr=0x00
vendor = 'Chelsio Communications Inc'
device = 'T520-SO Unified Wire Ethernet Controller'
class = network
subclass = ethernet
bar [10] = type
karels added a comment.
I think the change is a step in the right direction. Certainly, "ifconfig
xxN down" followed by an implicit UP should not cause any change to the routing
table. Does anyone know why the "down" is removing the route? That seems
wrong to me.
REVISION DETAIL
karels added a comment.
Seems fine to me; will let someone else approve.
REVISION DETAIL
https://reviews.freebsd.org/D8905
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com,
1.1-2/32 and 2001:550:2:8::1e-f
Try without an alias0 for the first set of IPs
ifconfig_lo1="inet 192.168.1.1/32"
ifconfig_lo1_ipv6="inet6 2001:550:2:8::1e prefixlen 126"
ifconfig_lo1_alias0="inet 192.168.1.2/32"
ifconfig_lo1_ipv6_alias0="inet6 2001:550:2:8::1f pr
> On Wed, Oct 19, 2016 at 07:26:44PM -0500, Mike Karels wrote:
> M> > On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote:
> M> > T> Hi!
> M> > T>
> M> > T> I got this panic in a bhyve VM, which was just compiling stuff
> M> >
derstand correctly, you have modifications? Could we see
them (assuming they are not in the tree, I haven't been watching closely)?
Mike
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-n
On 7/4/2016 12:36 PM, Patrick Lamaiziere wrote:
> As openbgpd(*) looks broken for the BGP password, is there any BGP
> daemon that works with tcp md5 signature (using setkey and ipsec of
> course) ?
Quagga should work.
---Mike
--
---
Mike Tancsa, tel +1 519
mike-karels.net added a comment.
I disagree; congestion is congestion, not "congestion for everyone but me".
I'd prefer to leave the cwnd change until it is replaced by something more
modern.
REVISION DETAIL
https://reviews.freebsd.org/D5872
EMAIL PREFERENC
mike-karels.net added a comment.
btw, I think the line to set the snd_cwnd should remain for now, until
something replaces it. ENOBUFS signals local congestion.
REVISION DETAIL
https://reviews.freebsd.org/D5872
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel
mike-karels.net added a comment.
Setting a retransmission timer on an ACK makes no sense; I don't think
tcp_output will send an ACK on a retransmission timeout.
Setting timers in the ENOBUFS case is at best a partial fix. If the ACK is
lost locally, we know; if it is lost elsewhere, we
1 - 100 of 903 matches
Mail list logo
