Page MenuHomeFreeBSD

networkUmbrella
ActivePublic

Recent Activity

Mon, Dec 17

sobomax closed D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.
Mon, Dec 17, 4:00 PM · network

Sat, Dec 15

cem accepted D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.

This is not quite what I am talking about here. We want the value returned by the DHCP server to have an effect when system boots, but we don't want dhclient to continuously restore the state back in case it has been changed by the administrator. My point is that dhclient does not do this periodic "check-up/fix-up" for any other part of configuration that it makes (e.g. ip address, netmask, default gateway, dns server), so there is no reason for an administrator to expect MTU to be in a different bucket. I believe "leave interface alone unless there are some changes on the DHCP side" is the proper approach.

Sat, Dec 15, 4:52 AM · network

Fri, Dec 14

eugen_grosbein.net accepted D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.

That makes sense, thanks.

Fri, Dec 14, 8:58 PM · network
cem added inline comments to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
Fri, Dec 14, 8:49 PM · network
sobomax added a comment to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
  1. At some point administrator logins and changes MTU from value X prescribed by the DHCP to some other value Y of his liking.

JFYI: the PR 229432 mentiones working way to ignore option 26 (MTU) supplied by DHCP server:

interface "em0" {

supersede interface-mtu 0;

}

Fri, Dec 14, 8:39 PM · network
eugen_grosbein.net added a comment to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
Fri, Dec 14, 8:08 PM · network
eugen_grosbein.net added a comment to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.

Hmm, there was https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229432 and corresponding commit https://svnweb.freebsd.org/base?view=revision&revision=336195 fixing the problem.

Was it insufficient or your tree does not have that fix?

Yes, you are right. We were looking at the FreeBSD 11.2 code here, I have not noticed there is another change in a trunk to fix the same issue. :(

Fri, Dec 14, 8:06 PM · network
sobomax added a comment to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.

@eugen_grosbein.net actually upon thinking a little bit more about the difference between this proposed change and r336195 I came to a conclusion that those two are not necessarily mutually exclusive, but rather complementing each other. The problem with just r336195 alone is that it invalidates implicit expectations that dhclient should not try to touch interface at all after initial configuration, unless there are some changes on the DHCP side. As an administrator, I'd not expect dhclient to be actively policing interface parameters and try to enforce them, which would be the case for MTU now. Consider the following hypothetical scenario:

Fri, Dec 14, 6:08 PM · network
sobomax added a comment to D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.

Yes, it requires corruption of private node memory. As owner of multiple routers mass servicing thousands of customers using multiple NETGRAPH nodes I can assure you that panic is not appropriatie action. Appropriate action is some form of block for traffic flow trough the node in question (with logging) leaving other nodes working.

Well, that's where I respectively disagree. As an owner of hundreds of FreeBSD systems servicing many millions of customers I think that rebooting the system immediately after any slight kernel heap/stack memory corruption is detected is not just appropriate but the only sane action available. Shutting down particular netgraph node and hope for the best would just leave the service down indefinitely with no hope for any sorts of automatic recovery.

Node destruction and recreation is easily implemented automatic recovery. We obviously have different usage patterns. I use net/mpd5 that can use ng_nat connecting it to the session that can be destroyed and re-created by any of "client" or "server" recovering from corruption and not interfering with other sessions. Other usage patterns can react on such event to re-create nodes too.

Fri, Dec 14, 4:39 PM · network
sobomax added inline comments to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
Fri, Dec 14, 4:11 PM · network
sobomax added a comment to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.

Hmm, there was https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229432 and corresponding commit https://svnweb.freebsd.org/base?view=revision&revision=336195 fixing the problem.

Was it insufficient or your tree does not have that fix?

Fri, Dec 14, 4:09 PM · network
eugen_grosbein.net added a comment to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.

Hmm, there was https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229432 and corresponding commit https://svnweb.freebsd.org/base?view=revision&revision=336195 fixing the problem.

Fri, Dec 14, 2:30 AM · network
cem added a comment to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.

The general idea seems sound to me. Ideally NIC drivers would also handle it gracefully, but this is nice in that it is close to the source (well, one common source). In fact, iflib handles this gracefully already:

Fri, Dec 14, 2:02 AM · network
eugen_grosbein.net added a comment to D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.

Yes, it requires corruption of private node memory. As owner of multiple routers mass servicing thousands of customers using multiple NETGRAPH nodes I can assure you that panic is not appropriatie action. Appropriate action is some form of block for traffic flow trough the node in question (with logging) leaving other nodes working.

Well, that's where I respectively disagree. As an owner of hundreds of FreeBSD systems servicing many millions of customers I think that rebooting the system immediately after any slight kernel heap/stack memory corruption is detected is not just appropriate but the only sane action available. Shutting down particular netgraph node and hope for the best would just leave the service down indefinitely with no hope for any sorts of automatic recovery.

Fri, Dec 14, 2:02 AM · network
sobomax updated the summary of D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
Fri, Dec 14, 1:18 AM · network
sobomax created D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
Fri, Dec 14, 1:13 AM · network

Thu, Dec 13

sobomax added a comment to D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.

Looks good with one exception: additional plain panic(). Can it be replaced with KASSERT?

IDK, there is no way this option to be set to anything but DLT_RAW or DLT_EN10MB in the course of normal operation of the node. So it would require some form of memory corruption to actually happen. IDK, panic(9) seems an appropriate action in that case. There are other panic(9) call in the code in similar situations.

Yes, it requires corruption of private node memory. As owner of multiple routers mass servicing thousands of customers using multiple NETGRAPH nodes I can assure you that panic is not appropriatie action. Appropriate action is some form of block for traffic flow trough the node in question (with logging) leaving other nodes working.

Thu, Dec 13, 9:12 PM · network
glebius accepted D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.

I would like to see a generic code in netgraph that marks hooks with DLT. So, no special messages to be needed, nodes will autosense what's connected to them. However, this is just a wish not a blocker for this change.

Thu, Dec 13, 6:55 PM · network
glebius added inline comments to D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.
Thu, Dec 13, 6:55 PM · network
eugen_grosbein.net added a comment to D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.

Looks good with one exception: additional plain panic(). Can it be replaced with KASSERT?

IDK, there is no way this option to be set to anything but DLT_RAW or DLT_EN10MB in the course of normal operation of the node. So it would require some form of memory corruption to actually happen. IDK, panic(9) seems an appropriate action in that case. There are other panic(9) call in the code in similar situations.

Thu, Dec 13, 4:20 PM · network
sobomax added a comment to D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.

Looks good with one exception: additional plain panic(). Can it be replaced with KASSERT?

Thu, Dec 13, 3:23 PM · network
eugen_grosbein.net added a reviewer for D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such: eugen_grosbein.net.

Looks good with one exception: additional plain panic(). Can it be replaced with KASSERT?

Thu, Dec 13, 7:58 AM · network

Wed, Dec 12

sobomax updated the diff for D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.

Make sure we have enough data for ethernet header.

Wed, Dec 12, 10:58 PM · network
sobomax created D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.
Wed, Dec 12, 10:48 PM · network

Nov 18 2018

farrokhi added a member for network: farrokhi.
Nov 18 2018, 1:53 PM

Oct 30 2018

araujo closed D17576: Allow changing lagg(4) MTU.
Oct 30 2018, 9:54 AM · network

Oct 24 2018

mav accepted D17576: Allow changing lagg(4) MTU.

I have no specific objections. Looks good to me. It just looks slightly odd, that MTU is handled different from other properties -- set before interface addition to LAGG, while multicast filters set after just before protocol initialization, and capabilities are set after the protocol initialization. As one of downsides this different order required addition of duplicate checks for LAGG nesting.

Oct 24 2018, 4:02 PM · network
ryan_freqlabs.com updated the diff for D17576: Allow changing lagg(4) MTU.

Addressed feedback by adding handling of new ports, so creating a lagg or adding new ports to an existing lagg sets all the port interfaces to the correct MTU automatically, too.

Oct 24 2018, 3:41 AM · network

Oct 16 2018

ryan_freqlabs.com updated the diff for D17576: Allow changing lagg(4) MTU.

Addressed feedback I received here and elsewhere on the previous patch. Please consider this alternative approach.

Oct 16 2018, 7:27 PM · network
ryan_freqlabs.com added a comment to D17576: Allow changing lagg(4) MTU.

For additional context, here is the code from if_bridge.c this is based on:

case SIOCSIFMTU:
        if (ifr->ifr_mtu < 576) {
                error = EINVAL;
                break;
        }
        if (LIST_EMPTY(&sc->sc_iflist)) {
                sc->sc_ifp->if_mtu = ifr->ifr_mtu;
                break;
        }
        BRIDGE_LOCK(sc);
        LIST_FOREACH(bif, &sc->sc_iflist, bif_next) {
                if (bif->bif_ifp->if_mtu != ifr->ifr_mtu) {
                        log(LOG_NOTICE, "%s: invalid MTU: %u(%s)"
                            " != %d\n", sc->sc_ifp->if_xname,
                            bif->bif_ifp->if_mtu,
                            bif->bif_ifp->if_xname, ifr->ifr_mtu);
                        error = EINVAL;
                        break;
                }
        }
        if (!error)
                sc->sc_ifp->if_mtu = ifr->ifr_mtu;
        BRIDGE_UNLOCK(sc);
        break;

It was not obvious to me why the minimum MTU should be limited by IPv4 but I included it here erring on the side of caution.

Oct 16 2018, 3:36 PM · network
pi added a comment to D17576: Allow changing lagg(4) MTU.

The value seems to come from RFC791, quote:

Oct 16 2018, 10:43 AM · network
0mp added inline comments to D17576: Allow changing lagg(4) MTU.
Oct 16 2018, 10:11 AM · network
araujo added inline comments to D17576: Allow changing lagg(4) MTU.
Oct 16 2018, 10:03 AM · network
0mp added a comment to D17576: Allow changing lagg(4) MTU.

Also, the manpage patch looks good to me.

Oct 16 2018, 9:50 AM · network
0mp added inline comments to D17576: Allow changing lagg(4) MTU.
Oct 16 2018, 9:47 AM · network
ryan_freqlabs.com updated the diff for D17576: Allow changing lagg(4) MTU.

Bumped the date in the man page.

Oct 16 2018, 7:44 AM · network
bcr accepted D17576: Allow changing lagg(4) MTU.

You need to bump the .Dd at the beginning of the document to the date of the commit since this is a content change.

Oct 16 2018, 7:36 AM · network
araujo accepted D17576: Allow changing lagg(4) MTU.

LGTM! I have spoke with Ryan to get a better scenario about this issue and here there is a reference for that: https://redmine.ixsystems.com/issues/25092

Oct 16 2018, 4:34 AM · network

Oct 15 2018

ryan_freqlabs.com created D17576: Allow changing lagg(4) MTU.
Oct 15 2018, 10:34 PM · network

Sep 19 2018

rockyhotas_post.com added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.

An update as regards the links issues. According to the Primer,

Sep 19 2018, 2:42 PM · Doc Committers, network
rockyhotas_post.com updated the diff for D10600: Revision of LDAP section of the FreeBSD Handbook.

Also the second part has been completely revisited, to be more concise and more uniform to the original text.
Links to specific versions of the OS are still present. Please, refer to this previous comment for more details. How to fix this?

Sep 19 2018, 2:09 PM · Doc Committers, network

Jul 1 2018

Diffusion closed D14536: Set DSCP bits in ip_carp.
Jul 1 2018, 8:37 AM · network

Jun 29 2018

darkfiberiru_gmail.com added a comment to D14536: Set DSCP bits in ip_carp.

Thanks for the help kristof. I couldn't find the documentation to bound input of sysctl's but I definitely agree it's better to validate it on entry.

Jun 29 2018, 10:49 AM · network
darkfiberiru_gmail.com updated the diff for D14536: Set DSCP bits in ip_carp.

Updated with help from kristof to validate sysctl on change.

Jun 29 2018, 10:46 AM · network

Jun 22 2018

rockyhotas_post.com added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.
In D10600#337622, @bcr wrote:

So, you're saying the we need testers for this configuration before we put it in the handbook as official instructions?

Jun 22 2018, 2:28 PM · Doc Committers, network

Jun 21 2018

bcr removed a reviewer for D10600: Revision of LDAP section of the FreeBSD Handbook: manpages.
Jun 21 2018, 4:59 PM · Doc Committers, network
bcr added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.

So, you're saying the we need testers for this configuration before we put it in the handbook as official instructions?

Jun 21 2018, 4:58 PM · Doc Committers, network

Jun 20 2018

rockyhotas_post.com updated the diff for D10600: Revision of LDAP section of the FreeBSD Handbook.

Applied all the modifications suggested by @bcr . Thank you!
The line-breaking were a first attempt to handle too-long lines, your solution is far better. A couple of comments:

Jun 20 2018, 2:49 PM · Doc Committers, network

Jun 18 2018

bcr added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.

A few suggestions, mostly about line breaks with a few textual corrections.

Jun 18 2018, 5:37 PM · Doc Committers, network
allanjude added a reviewer for D10600: Revision of LDAP section of the FreeBSD Handbook: bcr.
Jun 18 2018, 2:43 AM · Doc Committers, network