Hi Michael,
On Sun, Apr 11, 2021 at 2:27 PM Michael Sierchio wrote:
>
> On Sun, Apr 11, 2021 at 2:20 PM Matt Joras wrote:
>
> > Hi Michael,
> >
> > On Sun, Apr 11, 2021, 1:25 PM Michael Sierchio wrote:
> >
> >> Hi, all. I noticed my firewall was dropp
bhārata
> ___
> 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"
>
Matt Joras
>
_
On Tue, Mar 20, 2018 at 8:43 PM, Eugene Grosbein wrote:
> On 21.03.2018 08:03, Michael Tuexen wrote:
>
>>> On 21. Mar 2018, at 00:39, Eugene Grosbein wrote:
>>>
>>> 21.03.2018 3:09, Ronald F. Guilmette wrote:
>>>
I'm going to be doing some stuff with raw sockets pretty soon, and
while s
ernally.
Good luck.
Matt Joras
___
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 09/30/2017 11:36, Lee Brown wrote:
> It looks like the driver is not passing packets from the VLAN layer to the
> NIC. Switch counters verify this and netstat seems to indicate the same.
> ...
> root@rtr-net-r1: - # ifconfig igb0
> igb0: flags=8c02 metric 0 mtu 1500
igb0 looks to be OACTIVE, (
On Sep 13, 2017 6:43 AM, "David Horn" wrote:
I was under the impression that these Mellanox 40G->4x10G breakout cables
were for the Mellanox switch side (not Mellanox NIC) to provide more
flexible utilization options for the switch. I have never heard of doing
this from the 40G NIC (on any OS).
On 08/07/2017 09:11, Hans Petter Selasky wrote:
> Hi,
>
> Try to enter "kgdb" and run:
>
> thread apply all bt
>
> Look for the callout function in question.
>
> --HPS
>
If you don't have a way to attach kgdb handy you could also break into
ddb(4) and run "alltrace". Though gdb would be more useful
estions of alternative
approaches. An approach I did think about, but discarded, was to add a
protocol function to struct protosw, something like int
pr_getsockdescr(struct socket *, char *, size_t) which would fill in a
"human-readable" description of the socket based on whatever is appropr
On Tue, Jun 27, 2017 at 5:05 AM, Youssef GHORBAL
wrote:
>
> There is nothing in the 802.3ad that mandates stickiness of flows per NIC,
> the only thing explicit is that hash algorithm needs to maintain packet
> order. In this case, strictly speaking, it's : Packets do leave in "order"
> and do
Out of curiosity, what sort of lagg setup are you using that's causing
the TCP packets to be split across the two lagg interfaces?
Matt
On Mon, Jun 26, 2017 at 1:35 PM, Navdeep Parhar wrote:
> On Thu, Jun 22, 2017 at 3:57 PM, Youssef GHORBAL
> wrote:
>> Hello,
>>
>> I'm having an issue
e has an interest in this work please review the revision:
https://reviews.freebsd.org/D11370
Thanks,
Matt Joras
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to &
On Mon, Jun 26, 2017 at 6:36 AM, Andrey V. Elsukov wrote:
> On 26.06.2017 16:29, Ben RUBSON wrote:
>>
>>> On 26 Jun 2017, at 15:25, Andrey V. Elsukov wrote:
>>>
>>> On 26.06.2017 16:27, Ben RUBSON wrote:
> On 26 Jun 2017, at 15:13, Andrey V. Elsukov wrote:
>
> I think it is not
I thought I'd bring this review to people's attention:
https://reviews.freebsd.org/D9164
The problem is fairly straightforward, as is the fix. ixgbe(4) uses
ifmedia_removeall in a way that other drivers do not, which ends up
leaving a dangling pointer in the ifmedia struct leading to incorrect
inf
es drivers sleeping in the vlan_*config event handlers (which
involves having a global rmlock _and_ sx in if_vlan).
I was planning on doing a similar audit/fixing of if_lagg soon when I
get the chance.
Matt Joras
___
freebsd-net@freebsd.org mailing list
htt
top of bxe and then you
downed bxe you could very easily hit a use-after-free since bxe free'd
its rings while if_lagg is trying to transmit a packet.
Matt Joras
On Mon, Apr 11, 2016 at 2:03 PM, K. Macy wrote:
> You do understand that init needs to be run every time interface
> sett
yone would like to review them.
https://reviews.freebsd.org/D5825
The essence of the changes is to make the global vlan lock an
rmlock(9) and expand its scope to synchronize reading/using ifvlans
with destruction events as well as ensure exlusivity in certain
configuration paths.
Thanks,
16 matches
Mail list logo
