Let me know if there is anything else I can do for this issue (e.g. open a
bug).
From: Zhenlei Huang
Date: Tuesday, May 6, 2025 at 10:30 PM
To: Mike Belanger
Cc: freebsd-net@freebsd.org , Gleb Smirnoff
Subject: Re: [EXTERNAL] - Re: Race condition in ether_ifattach
CAUTION - This email is
by adding an artificial delay after the if_attach in
ether_ifattach.
Mike.
From: owner-freebsd-...@freebsd.org on behalf
of Zhenlei Huang
Date: Saturday, May 3, 2025 at 9:34 PM
To: Mike Belanger
Cc: freebsd-net@freebsd.org , Gleb Smirnoff
Subject: [EXTERNAL] - Re: Race condition
Yey, hopefully you're not shipping to Canada via Canaa Post :P
On Wed, Dec 11, 2024 at 12:54 PM Adrian Chadd wrote:
> That's great, I just ordered one from Amazon and will go figure it out
> with you!
>
>
>
> -adrian
>
>
> On Wed, 11 Dec 2024 at 08:54, Mik
n you take a photo of the NIC itself, so I can make sure it lines
> up with what I have in my box of Atheros parts?
>
> Thanks!
>
>
>
> -adrian
>
>
> On Sun, 1 Dec 2024 at 05:41, Mike Jakubik wrote:
>
>> Hello,
>>
>> After all the info i gathered
Indeed, compiles cleanly and works fine on this system. Thank you sir!
FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0
main-e8d027be6: Fri Nov 29 20:19:55 EST 2024
mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
amd64
[root@fbsd15 /usr/ports/net
Oh OK, sorry missed that, will test and report.
Thanks!
On 2024-12-01 4:58 a.m., Ronald Klop wrote:
I think a quick fix for your problem was committed a few days ago (Nov
28).
https://cgit.freebsd.org/ports/commit/?id=4ca9ea9d4060a4a494456a0e56306bd508fe20e8
Regards,
Ronald.
*Van:* Mike
th0: [HT] LDPC transmit/receive enabled
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9460 mac 640.2 RF5110 phy 0.0
ath0: 2GHz radio: 0x; 5GHz radio: 0x
[255] ath0: device timeout
[287] ath0: device timeout
^ This repeats hundreds of times, network is unusable during these reports.
[mike
Hello,
Seems like it wont compile on recent current, noticed about 2 days ago
and /usr/src/sys/sys/mbuf.h hasnt been touched it seems.
15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-56043cbfdd: Thu Nov 21
20:30:44 EST 2024
[root@fbsd15 /usr/ports/net/realtek-re-kmod]# make MAKE_JOBS_UNSAFE=ye
Any update on this from upstream maybe? Seems like an easy fix, I got
new system that needs this driver too (Realtek 5Gb).
Ty.
Hello,
Seems like it wont compile on recent current, noticed about 2 days ago
and /usr/src/sys/sys/mbuf.h hasnt been touched it seems.
15.0-CURRENT FreeBSD 15.0-
ath0: device timeout
[287] ath0: device timeout
^ This repeats hundreds of times, network is unusable during these reports.
[mike@fbsd15 ~]$ ifconfig -m wlan0
wlan0: flags=8843 metric 0 mtu 1500
options=0
capabilities=0
ether c0:38:96:39:66:f5
inet 192.168.100.180 netmask 0xff00 broadcast
th0: [HT] LDPC transmit/receive enabled
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9460 mac 640.2 RF5110 phy 0.0
ath0: 2GHz radio: 0x; 5GHz radio: 0x
[255] ath0: device timeout
[287] ath0: device timeout
^ This repeats hundreds of times, network is unusable during these reports.
[mike
a fit.
I do not have the hardware. I am trying to help somebody else with this. I
have seen the dtb.
It’s a Variscite DAR-MX8M-PLUS.
Regards,
Mike.
From: owner-freebsd-...@freebsd.org on behalf
of Milan Obuch
Date: Friday, September 13, 2024 at 3:08 AM
To: freebsd-net@freebsd.org
Subject
The following device tree specifies a shared mdio.
The ffec driver uses miibus.
When there is a shared mdio, one of the device instances will not be able to
properly configure the PHY, as it needs to use the other devices resource to
read/write the PHY.
&fec1 {
pinctrl-names = "d
On 8/29/2024 3:45 PM, Olivier Cochard-Labbé wrote:
On Thu, Aug 29, 2024 at 8:52 PM mike tancsa wrote:
But this would kill all UDP fragments. If the host has some other
UDP
application that needs to deal with fragmented packets, is there a
way
to get around that and only
to get around that and only drop packets with a certain port in the
first fragment ?
---Mike
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
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. I
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 if
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 appropriate o
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_
addr, but it allows other members
of 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
oobar ... does not fail. (12.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 determi
I run 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 forma
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
ial to add; 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
ibly as two words using 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
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 could
be, though. Would this be sufficient for your purposes? There is also
a unit number, which could also be exported.
Mike
I need 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
g 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
3a8 at amd64_syscall+0x138
#16 0x8101da7b at fast_syscall_common+0xf8
Mike
tion
and causes 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
from 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 name le
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
e any 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,
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 Linuxism
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
e the problem 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.swiftsmsg
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
0.00-30.00 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 ----
Mik
.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.
17:55:25: [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:
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.
h.
I tried 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=textdu
u find that it works. I
suspect the list in altq(4) is rather incomplete/out-of-date.
> thanks,
> --
> J.
Mike
kstathttps://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
> > &
use 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
ld be
> > > > deprecated, as they use the historical masks. inet_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. Unfort
r 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.
> 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
emove 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
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 icmp
; 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 to
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 8 Nov 2019, at 7:30, Mike Karels wrote:
> >> P.S. I rebuild kernel with MROUTING option but
> >> =
> >> # netstat -gs -f inet
> >> No IPv4 MROUTING kernel support
> >> =
> >
> >> still here
> >
> > Oh, I se
> 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
> >>>>>>>>>
> >>>>>>>>> I
> 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"
t; 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
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
s not require 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 on this
ld 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@freebsd.org mailing list
https://l
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
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 <mailto:kris...@sigsegv.be>> wrote:
>
> On 15 Mar 2017, at 22:10, Mike Tancsa wrote:
>
> On 3/15/2017 4:28 AM, Kristof Provost wrote:
>
>
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
>>
>>
1 - 100 of 1032 matches
Mail list logo
