Page MenuHomeFreeBSD

networkUmbrella
ActivePublic

Recent Activity

Wed, Feb 13

manu added inline comments to D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.
Wed, Feb 13, 1:12 PM · network, ARM, arm64
mw requested changes to D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.
Wed, Feb 13, 1:04 PM · network, ARM, arm64
mw added a comment to D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.

Thanks for the patch. After you resubmit, I'd like to try it on the Clearfog board as well.

Wed, Feb 13, 1:04 PM · network, ARM, arm64

Fri, Feb 8

manu added inline comments to D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.
Fri, Feb 8, 10:47 AM · network, ARM, arm64
manu requested changes to D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.

Added some comments.
Keep up the good work :)

Fri, Feb 8, 10:42 AM · network, ARM, arm64

Thu, Feb 7

xistence_0x58.com added a comment to D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.

I also have these changes up on Github at: https://github.com/freebsd/freebsd/compare/master...theasylum:fix/e6000sw-fdt if it is easier to review there due to more context. I did re-create the diff as requested by @manu with -U999, so hopefully that helps.

Thu, Feb 7, 6:55 PM · network, ARM, arm64
xistence_0x58.com updated the diff for D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.

Updated to match style(9) thanks to @dteske's comment.

Thu, Feb 7, 6:49 PM · network, ARM, arm64
dteske added a comment to D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.

Try to get ahold of mw@ and loos@ to review

Thu, Feb 7, 7:43 AM · network, ARM, arm64
dteske added inline comments to D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.
Thu, Feb 7, 7:30 AM · network, ARM, arm64

Wed, Jan 30

xistence_0x58.com created D19036: Update mvneta/e6000sw for new style Distributed Switch Architecture Device Tree Bindings.
Wed, Jan 30, 7:05 PM · network, ARM, arm64

Dec 21 2018

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

Yes, I've changed those.

Ok!

Now that the server part is about to be committed, do you also plan to do a section about the client? We have an article mentioning pam_ldap, but that article should either be reworked or put into the handbook altogether.

Yes, maybe you are referring to this section.

Dec 21 2018, 7:49 AM · Doc Committers, network

Dec 20 2018

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

Yes, I've changed those.

Dec 20 2018, 10:59 PM · Doc Committers, network
bcr closed D10600: Revision of LDAP section of the FreeBSD Handbook.
Dec 20 2018, 9:54 PM · Doc Committers, network
bcr added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.

Yes, I've changed those.
Now that the server part is about to be committed, do you also plan to do a section about the client? We have an article mentioning pam_ldap, but that article should either be reworked or put into the handbook altogether.

Dec 20 2018, 9:40 PM · Doc Committers, network
rockyhotas_post.com added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.
In D10600#397141, @bcr wrote:

I think the patch is fine now. I'll see to it that it gets committed.
Thanks for your patience, Rocky Hotas.

Dec 20 2018, 9:27 PM · Doc Committers, network
bcr accepted D10600: Revision of LDAP section of the FreeBSD Handbook.

I think the patch is fine now. I'll see to it that it gets committed.
Thanks for your patience, Rocky Hotas.

Dec 20 2018, 8:30 PM · Doc Committers, network

Dec 17 2018

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

Dec 15 2018

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.

Dec 15 2018, 4:52 AM · network

Dec 14 2018

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

That makes sense, thanks.

Dec 14 2018, 8:58 PM · network
cem added inline comments to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
Dec 14 2018, 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;

}

Dec 14 2018, 8:39 PM · network
eugen_grosbein.net added a comment to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
Dec 14 2018, 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. :(

Dec 14 2018, 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:

Dec 14 2018, 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.

Dec 14 2018, 4:39 PM · network
sobomax added inline comments to D18546: dhclient(8) issues unneeded ioctl(SIOCSIFMTU) on every lease renew.
Dec 14 2018, 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?

Dec 14 2018, 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.

Dec 14 2018, 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:

Dec 14 2018, 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.

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

Dec 13 2018

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.

Dec 13 2018, 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.

Dec 13 2018, 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.
Dec 13 2018, 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.

Dec 13 2018, 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?

Dec 13 2018, 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?

Dec 13 2018, 7:58 AM · network

Dec 12 2018

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.

Dec 12 2018, 10:58 PM · network
sobomax created D18535: Allow ng_nat to be attached to a ethernet interface directly via ng_ether(4) and such.
Dec 12 2018, 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