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 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
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_
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 'struct
> in6_addr'
>95 | ipv6->sin6_addr.s6_addr32[3] = 0;
> |
On 25 Apr 2024, at 15:56, Gregory Shapiro wrote:
>> of course, gethostid(3) is now deprecated in favour of sysctl(3), and the
>> hostid(8) command is gone, and there's now more than one flavour of
>> Internet-capable UNIX in the world, and there's more than one Internet
>> address family now. so w
On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
>> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
>>
>> Hello all!
>>
>> It works just fine!
>> System performance is OK.
>> Using patch on main-n268841-b0aaf8beb126(-dirty).
>>
>> ---
>> net.inet.tcp.functions_available:
>> Stack
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 | grep Interface
> Interface vnet0
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
On 20 Nov 2023, at 15:16, Franco Fichtner wrote:
>> On 20. Nov 2023, at 21:56, Kristof Provost wrote:
>>
>> I’d look in the direction of just adding a field to struct ifnet with the
>> original interface name (likely easily done in if_attach()), along with a
>> new ioctl to retrieve that field.
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
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 name
>> in their groups ?
>>
>> So an if_ure interface ue0 will look like:
>>
>> ```
>> ue0: flags=1008843 metric 0
>> mtu 1500
>>
>> options=60009b
>>
>> ethe
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 could
>> be, though. Would this
On 19 Nov 2023, at 8:34, Mina Galić wrote:
>>> FreeBSD currently does not preserve the old ( original ) name of
>>> interfaces if it is renamed ( either physical or cloned ones ).
>>> While there's an attempt https://reviews.freebsd.org/D28247
>>> to get the device name (physical
>>> ones) but it
On 9 Nov 2023, at 4:30, Ronald Klop wrote:
> On 11/4/23 15:39, Ronald Klop wrote:
>> Hi,
>>
>> For issue 274092 [1] I'm looking for reviewers.
>>
>> A user on the ML had an issue that the MAC address was not assigned on some
>> Raspberry PI compute modules.
>> I tried and succeeded in using the M
I have a machine running a recent main system, 765ad5b28d3f, just after
ALPHA1. It hosts a VM on bhyve. About the time I installed and configured
ALPHA1 on the guest, the host got this LOR from IPv6 (nd6_llinfo_timer):
lock order reversal:
1st 0xf802ea7dce90 lle (lle, rw) @ netinet6/in6.c:2
On 1 Mar 2023, at 5:36, Michael Gmelin wrote:
>> On 1. Mar 2023, at 11:35, Yuri wrote:
>>
>> Windows system connects to FreeBSD through ssh and then this connection
>> dies because of WiFi or VPN issues.
>>
>> FreeBSD still has the sshd process alive for this connection for 30+ minutes.
>>
>> T
On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
> Hi,
>
> trpt(8) is utility to pull TCP debugging data from the kernel
> in 4.2BSD. We still have it in the base, with corresponding
> TCPDEBUG option in the kernel and SO_DEBUG socket option.
>
> At the same time we have much more powerful debuggin
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
I recently noticed the following behavior:
% ping6 redrock
ping6: Name does not resolve
% host redrock
redrock.karels.net has address 10.0.2.2
redrock.karels.net mail is handled by 10 mail.karels.net.
% ping6 nonexistenthost
ping6: Name does not resolve
The first error message is misleading, beca
I have been corresponding with the authors of Internet-Drafts that relax
restrictions on parts of the IPv4 address space to allow normal unicast
use, and I have FreeBSD changes to allow experimentation with these
updates. This message summarizes my changes, and solicits input.
The changes are all
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) the field w
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
On 15 May 2022, at 10:53, Benoit Chesneau wrote:
> Thanks but I have already set them to 1. This is kind of unexpected :/
>
> ```
> # sysctl net.inet.ip.forwarding
> net.inet.ip.forwarding: 1
> # sysctl net.link.tap.up_on_opennet.link.tap.up_on_open: 1
> ```
>
> in the vm, pinging the IP hosts are
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.
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 system crashed shortly
thereafter with this:
panic: Assertion in_epoch(net_epoch_preempt) failed at
/usr/src/
> Hi,
> Are there any (even preliminary) docs/manpages for genet?
> I'm not seeing it in main-n251261-25d0ccbe101 or any earlier system.
Sorry, no. I'll try to move this up on my list of things to do.
> Can someone confirm whether pf's ALTQ is supported with this NIC? =
> It's not list
I hope to commit the INET changes I have in review soon; please review
now if you are interested. I could still use reviewers for the ifconfig
and res_init.c reviews. Both are fairly simple; res_init.c just deletes
some old code that is ifdef'ed out. The links to the reviews:
kernel ht
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
> > &
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
mask (24 bits). A question has arisen as to what the default mask should
be for loopback interfaces. The standard 127.0.0.1 is added with an 8 bit
I started a series of reviews for changes to clean up old code relating
to Internet Class A/B/C usage, including man pages that mark routines
as deprecated. Most of them have no reviewers yet; please feel free to
add yourselves and/or comment.
The kernel and ifconfig changes add warning messages
> > Rod wrote:
> >
> > > > I plan to do some cleanup of the residual code defining and using the
> > > > old Internet network classes (A/B/C), which have been obsolete since
> > > > CIDR took hold. This is an outline of what I plan, as it will happen
> > > > in a number of steps and reviews, and
Rod wrote:
> > I plan to do some cleanup of the residual code defining and using the
> > old Internet network classes (A/B/C), which have been obsolete since
> > CIDR took hold. This is an outline of what I plan, as it will happen
> > in a number of steps and reviews, and I would like feedback on
I plan to do some cleanup of the residual code defining and using the
old Internet network classes (A/B/C), which have been obsolete since
CIDR took hold. This is an outline of what I plan, as it will happen
in a number of steps and reviews, and I would like feedback on some
of it.
I want to redu
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
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 part of all ones. 4.3BSD changed its
default, and made the broadcast address settable with ifconfig. However,
FreeBSD *s
> From: "Rodney W. Grimes"
> Subject: Re: ip(8) in base
> Date: Sun, 16 Aug 2020 09:38:47 -0700 (PDT)
> > > From: "Alexander V. Chernikov"
> > > To: net , freebsd-hackers
> > > Subject: ip(8) in base
> > > Date: Sun, 16 Aug 2020 10:11:11 +0100
> >
> > > I want to introduce ip(8) or something s
> From: "Alexander V. Chernikov"
> To: net , freebsd-hackers
> Subject: ip(8) in base
> Date: Sun, 16 Aug 2020 10:11:11 +0100
> I want to introduce ip(8) or something similar in base.
> Basically, I need some userland tool to explicitly operates on nexthops,
> nexthop groups and fib lookup algo
I just created a review with the following description:
Allow TCP to reuse local port with different destinations
Summary:
Previously, tcp_connect() would bind a local port before connecting,
forcing the local port to be unique across all outgoing TCP connections
for the address family. Instead
> 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
> > > > Hi All
> > > >
> > > > I have (noob) questions about multicast routing under FreeBSD.
> > > >
> > > > I have FreeBSD box with two (or more) multicast enabled interfaces
> > > > (e.x.
> > > > vlan750 and vlan299). vlan750 connected to multicast source.
> > > >
> > > > Then pimd install
> > Hi All
> >
> > I have (noob) questions about multicast routing under FreeBSD.
> >
> > I have FreeBSD box with two (or more) multicast enabled interfaces (e.x.
> > vlan750 and vlan299). vlan750 connected to multicast source.
> >
> > Then pimd installed and only this two interfaces enabled i
> Recently at work I had a system crash while executing RTFREE() in
> udp_notify(). In looking at the system I discovered that two threads
> had called udp_notify() on the same pcb. This was possible because
> the threads only held a read lock on the socket. The obvious solution
> is to hold a w
> > A change a while back (r264986) broke the ability to change a route's
> > parameters if the gateway wasn't explicitly specified again. For
> Was the a feature by accident or design? As the man page does not
> say that "gateway" is optional on a change command, it shows it
> as a required par
understand its not a big deal, especially since there’s a
way to configure that in latest FreeBSD code. I shall fix my code one
of the above 2 ways.
Why not just set maxhold to your favorite value (e.g. 43?).
Thank You all for your support and help.
--Gopu
On 8/19/17, 9:56 AM, "Mike K
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
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.
IIRC, it requires queuing at least one packet. Queing one packet is
what BSD has done essent
Responding to the thread as a whole: another alternative is the FLOWTABLE
kernel option. I added route and link-layer caching for endpoints (TCP and
UDP), which makes the FLOWTABLE option less useful (or undesirable) there,
but FLOWTABLE adds route caching for packet forwarding as well. I’d sugge
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 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
>>
>>
> Hi All,
> Eugene has reported about the following assertion in the ARP code:
> http://www.grosbein.net/freebsd/crash/arp-kassert.txt
> After some investigation I found that L2 cache has reference leak, that
> can lead to integer overflow and this assertion.
> The one of the ways to reprod
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
https:
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,
honzhan_microsoft.com,
> 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> >
> On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote:
> T> Hi!
> T>
> T> I got this panic in a bhyve VM, which was just compiling stuff
> T> and had two ssh sessions open. It has static network configuration,
> T> one interfaces, one IP address, IPv4 only and it sees only hardware
>
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 PREFERENCES
https://reviews.freebsd.or
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/emailpreference
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
mike-karels.net added a comment.
I believe that the original code is wrong, and the change is not sufficient
to fix it. The retransmit timer should be running if and only if we have
sent data into the receive window and are awaiting an ACK. The persist
timer should be running if and onl
> > Any news on this issue? Is anyone working on a solution for -head ?
> I believe a variant of Mike's patch is in phabricator now?
My patch, plus addition of new 10/40 Gb types, is in review D1965.
There is an althernative approach in D2008. There hasn't been much
activity on either. Take a l
mike-karels.net added a comment.
>>! In D1965#11, @gnn wrote:
> BTW Mike Karels was in favor of this in an email thread. He's not yet on
> phabricator but I'll ask him here as well.
Agreed, with minor exceptions. Given the ixl changes, I don't think the vtnet
exam
mike-karels.net added a subscriber: mike-karels.net.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1965
To: erj, adrian, jfvogel, gnn
Cc: mike-karels.net, glebius, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebs
> M> I'm not sure what would be different about your approach; you mentioned "n"
> M> versions rather than "x" versions of the ioctls, but I don't know what you
> M> have in mind for encoding. Any compatible version would be limited to int.
> The difference is that I suggest to go with a complete
> > Hi,
> >
> > There are 6 token ring bits, which I presume are available when token
> > ring is not selected.
> >
> > #define IFM_TOK_ETR 0x0200 /* Early token release */
> > #define IFM_TOK_SRCRT 0x0400 /* Enable source routing
> > features */
> > #define IFM_TOK_ALLR
> I'm doing some work for Mellanox and we need some 100GBase types for
> coming hardware products too.
> I think we are not using the 32-bits of "ifm_media" well enough.
> Has it been discussed to add more bits to "IFM_NMASK" and have more
> ethernet types like IFM_ETHER_0, IFM_ETHER_1, IFM_ETH
> On Wed, Feb 25, 2015 at 02:42:16PM -0800, Eric Joyner wrote:
> E> Tbh, I respect Gleb's approach, but developing such a thing would take a
> E> while; the fix Mike proposed would be a fix now.
> E>
> E> I mean, I'd like to see a decoupling of media types and speeds from
> E> "standard" names, an
On Feb 9, gnn wrote:
> On 8 Feb 2015, at 22:41, Mike Karels wrote:
> > Sorry to reply to a thread after such a long delay, but I think it is
> > unresolved, and needs more discussion. I'd like to elaborate a bit on
> > my goals and proposal. I believe Adrian ha
Alfred wrote:
> On 2/8/15 2:41 PM, Mike Karels wrote:
> >
> > To solve the second problem, I think the right approach would be to reduce
> > this interface to a truly generic one, such as media type (e.g. Ethernet),
> > generic flags, and perhaps generic status. Then
f they don't want to.
>
> Adrian -- where can I look for more information on what net80211 does for
> media types? Do you mean what it does with MCS values, or something more;
> I've looked at it a bit, but I don't know very much about how Wi-Fi works.
>
> - Eric
&g
nt,
not a typedef. I would propose a similar API that is not limited, but easy
to convert (e.g. using a new typedef). I'd be willing to sketch out something
like that.
> > On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote:
> > > > Any other thoughts, or should I start loo
> Any other thoughts, or should I start looking at seeing what I can take
> copy from net80211?
> Also adding -net, since this is pretty relevant.
I had the same reaction as Adrian initially, as an int with numerous fields
seems really messy. However, I don't think we have the challenges of 802.
> Sure, but it would be nice to file bugs with VMware and such to ensure
> they fix their bugs.
fwiw, I use IPv6 with recent versions of ESXi and VMware Workstation,
and have not seen this problem. I'm curious if the problem is in old
versions or with particular configurations.
> Anyone have any
> As for if_vlan.c, I verified that in the case when NIC's MAC adress is
> modified, it updates the values in the vlan to keep them in sync. However,
> I don't see this behavior when the changes are performed over the vlan.
There is no existing driver API to add MAC addresses in FreeBSD, which is
> On 24 December 2012 17:01, Ryan Stone wrote:
> > I don't believe that this is fixed in later versions of the driver. The
> > problem is that when the interface loses link the transmit queue can fill
> > up. Once that happens the driver never gets any more calls from the network
> > stack to make
> On Thu, Dec 06, 2012 at 02:39:11PM +0800, Kevin Lo wrote:
> K> Here's the patch mostly from NetBSD to make socket(2) return EAFNOSUPPORT
> K> rather than EPROTONOSUPPORT if the family cannot be found.
> K>
> K> http://people.freebsd.org/~kevlo/patch-socket
> K>
> K> The man page documents the b
Has anyone had any success using the bxe driver with FreeBSD 9.0 or
pre-releases? If so, are you using BCM57710 or BCM57711[E]? We are
trying to use the 57710 without any success; it does not receive
unicast packets, just broadcast or multicast.
Thanks,
Mike
_
Return-Path: [EMAIL PROTECTED]
Delivery-Date: Thu Jan 24 05:00:27 2008
Received: from staring.karels.net ([EMAIL PROTECTED] [206.196.45.1])
by redrock.karels.net (8.13.8/8.13.6) with ESMTP id m0OB0Rb6097199
for <[EMAIL PROTECTED]>; Thu, 24 Jan 2008 05:00:27 -0600 (CST)
(enve
> Len Gross wrote:
> > Thanks so much for the response. Here is some additional information.
> >
> > I'm trying to emulate an RF network where there are colisions (e.g. "Aloha"
> > type protocol) so I actually need collisions! I had forgotten that modern
> > hardware
> > essentially eliminated t
> Mike Karels wrote:
> >>> Secure Computing (my employer) has a modification that seems reasonable
> >>> to me (well, I guess I wouldn't have done it otherwise). We adopted the
> >>> existing but unused JUMBO_MTU capability flag, and, if enabled, instru
> > Secure Computing (my employer) has a modification that seems reasonable
> > to me (well, I guess I wouldn't have done it otherwise). We adopted the
> > existing but unused JUMBO_MTU capability flag, and, if enabled, instructs
> > the driver to receive jumbo frames according to the hardware lim
> I'd like to just ask around as to whether relaxing the limit on drivers
> makes sense, and if so, how much to relax it. While we're about it,
> what size is the actual maximal sized jumbo packet we will ever see?
> (including
> likely misconfigurations).
> It is possible we should just allow a
> Any two hosts, connected to single Layer2 network MUST use
> same MTU. Any other cases lead to hard-to-solve problems.
I'd have to disagree. In fact, I'd say that any two hosts on the
same L2 network must use the same MRU. In particular, if a host
choses to use a lower MTU, if that also lowers
> I think that the possible courses of action are:
> 1/ Ignore further incoming data, but ACK it.
> (this is basically what the userland code does in this case)
This could lead to indefinite data transfer, while misleading the sender
into thinking the data are being delivered.
> 2/ Stop AC
> Mike Karels wrote:
> >> There are also things to consider such as if a GigE card is connected to
> >> a GigE device (switch/card etc) and the card supports jumbo frames
> >> should the MRU be set to the max jumbo receive size for the card? This
> >>
> There are also things to consider such as if a GigE card is connected to
> a GigE device (switch/card etc) and the card supports jumbo frames
> should the MRU be set to the max jumbo receive size for the card? This
> could cause confusion when people plug jumbo capable devices in with
> hardw
> A related change that should probably be discussed if we want to think more
> about asymmetry in maximum transmission unit is this one:
>
>revision 1.98
>date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0
>In syncache_respond() do n
> In -CURRENT my changes to the ethernet input path maintain the use of
> ETHER_MAX_FRAME() however the check is folded under #ifdef DIAGNOSTIC. I
> don't recall adding this conditional or touching it so it seems to be
> something which was already thereo radded by someone else.
It has been the
1 - 100 of 101 matches
Mail list logo
