[Differential] D9270: Add support for user-supplied Host-Uniq tag and handle PADM messages in Netgraph PPPoE
mav accepted this revision. mav added a reviewer: mav. mav added a comment. This revision has a positive review. It's been years since I worked on this, but I see no problems from this. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D9270 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: ale, #manpages, adrian, #network, julian, mav Cc: mav, poolroom_gmail.com, mandree, imp, freebsd-net-list ___ 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"
[Bug 217413] panic: Assertion err == 0 failed at /usr/src/sys/net/iflib.c:2242 after 1000m physical link shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217413 --- Comment #3 from b...@kobyla.org --- Affects all 3 types of used cards - em, igb, bce. Tested only on amd64. When router on another side of one of 4 active links reboots, this server gets this panic either. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 217413] panic: Assertion err == 0 failed at /usr/src/sys/net/iflib.c:2242 after 1000m physical link shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217413 b...@kobyla.org changed: What|Removed |Added Summary|panic: Assertion err == 0 |panic: Assertion err == 0 |failed at |failed at |/usr/src/sys/net/iflib.c:22 |/usr/src/sys/net/iflib.c:22 |42 after attaching the |42 after 1000m physical |cable with 1000m fixed |link shutdown |speed at another end| -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 217463] socket calls can cause panic after passing socket to nfssvc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217463 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Differential] D9270: Add support for user-supplied Host-Uniq tag and handle PADM messages in Netgraph PPPoE
ale retitled this revision from "Add support for user-supplied Host-Uniq tag in
Netgraph PPPoE" to "Add support for user-supplied Host-Uniq tag and handle PADM
messages in Netgraph PPPoE".
ale updated the summary for this revision.
ale updated the test plan for this revision.
ale added a subscriber: mav.
ale updated this revision to Diff 25849.
ale added a comment.
This revision now requires review to proceed.
- add client and server support for PADM messages, HURL and MOTM
- Fix a regression in PPPoE server introduced by previous patch version
- handle missing service name tag in PADI requests to cope with non fully
compliant client implementations, treat it as empty service name
REPOSITORY
rS FreeBSD src repository
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D9270?vs=24314&id=25849
REVISION DETAIL
https://reviews.freebsd.org/D9270
AFFECTED FILES
share/man/man4/ng_pppoe.4
sys/netgraph/ng_pppoe.c
sys/netgraph/ng_pppoe.h
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: ale, #manpages, adrian, #network, julian
Cc: mav, poolroom_gmail.com, mandree, imp, freebsd-net-list
diff --git a/sys/netgraph/ng_pppoe.h b/sys/netgraph/ng_pppoe.h
--- a/sys/netgraph/ng_pppoe.h
+++ b/sys/netgraph/ng_pppoe.h
@@ -52,8 +52,10 @@
#define NGM_PPPOE_COOKIE 1089893072
#define NGM_PPPOE_SETMAXP_COOKIE 1441624322
+#define NGM_PPPOE_PADM_COOKIE 1488405822
#define PPPOE_SERVICE_NAME_SIZE 64 /* for now */
+#define PPPOE_PADM_VALUE_SIZE 128 /* for now */
/* Hook names */
#define NG_PPPOE_HOOK_ETHERNET "ethernet"
@@ -84,7 +86,11 @@
NGM_PPPOE_SETMODE = 12, /* set to standard or compat modes */
NGM_PPPOE_GETMODE = 13, /* see current mode */
NGM_PPPOE_SETENADDR = 14, /* set Ethernet address */
- NGM_PPPOE_SETMAXP = 15 /* Set PPP-Max-Payload value */
+ NGM_PPPOE_SETMAXP = 15, /* Set PPP-Max-Payload value */
+ NGM_PPPOE_SEND_HURL = 16, /* Send PADM HURL message */
+ NGM_PPPOE_HURL = 17, /* HURL for informational purposes */
+ NGM_PPPOE_SEND_MOTM = 18, /* Send PADM MOTM message */
+ NGM_PPPOE_MOTM = 19 /* MOTM for informational purposes */
};
/***
@@ -157,6 +163,13 @@
uint16_t data;
};
+/*
+ * This structure is used to send PADM messages from server to client.
+ */
+struct ngpppoe_padm {
+ char msg[PPPOE_PADM_VALUE_SIZE];
+};
+
/
* Constants and definitions specific to pppoe
/
@@ -171,6 +184,7 @@
#define PADR_CODE 0x19
#define PADS_CODE 0x65
#define PADT_CODE 0xa7
+#define PADM_CODE 0xd3
/* Tag identifiers */
#if BYTE_ORDER == BIG_ENDIAN
@@ -181,6 +195,8 @@
#define PTT_AC_COOKIE (0x0104)
#define PTT_VENDOR (0x0105)
#define PTT_RELAY_SID (0x0110)
+#define PTT_HURL (0x0111) /* PPPoE Extensions (CARREL) */
+#define PTT_MOTM (0x0112) /* PPPoE Extensions (CARREL) */
#define PTT_MAX_PAYL (0x0120) /* PPP-Max-Payload (RFC4638) */
#define PTT_SRV_ERR (0x0201)
#define PTT_SYS_ERR (0x0202)
@@ -198,6 +214,8 @@
#define PTT_AC_COOKIE (0x0401)
#define PTT_VENDOR (0x0501)
#define PTT_RELAY_SID (0x1001)
+#define PTT_HURL (0x1101) /* PPPoE Extensions (CARREL) */
+#define PTT_MOTM (0x1201) /* PPPoE Extensions (CARREL) */
#define PTT_MAX_PAYL (0x2001) /* PPP-Max-Payload (RFC4638) */
#define PTT_SRV_ERR (0x0102)
#define PTT_SYS_ERR (0x0202)
diff --git a/sys/netgraph/ng_pppoe.c b/sys/netgraph/ng_pppoe.c
--- a/sys/netgraph/ng_pppoe.c
+++ b/sys/netgraph/ng_pppoe.c
@@ -175,6 +175,20 @@
&ng_parse_uint16_type,
NULL
},
+{
+ NGM_PPPOE_COOKIE,
+ NGM_PPPOE_SEND_HURL,
+ "send_hurl",
+ &ngpppoe_init_data_state_type,
+ NULL
+},
+{
+ NGM_PPPOE_COOKIE,
+ NGM_PPPOE_SEND_MOTM,
+ "send_motm",
+ &ngpppoe_init_data_state_type,
+ NULL
+},
{ 0 }
};
@@ -226,9 +240,11 @@
const struct pppoe_tag *tags[NUMTAGS];
u_int service_len;
u_int ac_name_len;
+ u_int host_uniq_len;
struct datatag service;
struct datatag ac_name;
+ struct datatag host_uniq;
};
typedef struct sess_neg *negp;
@@ -589,18 +605,40 @@
pppoe_finduniq(node_p node, const struct pppoe_tag *tag)
{
hook_p hook = NULL;
- union uniq uniq;
+ sessp sp;
- bcopy(tag + 1, uniq.bytes, sizeof(void *));
/* Cycle through all known hooks. */
LIST_FOREACH(hook, &node->nd_hooks, hk_hooks) {
/* Skip any nonsession hook. */
if (NG_HOOK_PRIVATE(hook) == NULL)
continue;
- if (uniq.pointer == NG_HOOK_PRIVATE(hook))
+ sp = NG_HOOK_PRIVATE(hook);
+ if (sp->neg->host_uniq_len == ntohs(tag->tag_len) &&
+ bcmp(sp->neg->host_uniq.data, (const char *)(tag + 1),
+ sp->neg->host_uniq_len) == 0)
break;
}
- CTR3(KTR_NET, "%20s: matched %p for %p", __func__, hook, uniq.pointer);
+ CTR3(KTR_NET, "%20s: matched %p for %p", __func__, hook, sp);
+
+ return (hook);
+}
+
+static hook_p
+pppoe_findcookie(node_p node, const struct
[Differential] D9451: Constrain IPv6 interface routes to each FIB
asomers added a comment.
This review is starting to look pretty good. But in addition to the few
things I mentioned inline, there's one other change that you need to make: you
get to clear the `atf_expect_fail` statements from
tests/sys/netinet/fibs_test.sh.
INLINE COMMENTS
> jhujhiti_adjectivism.org wrote in nd6.c:1295
> I'm rethinking this a little bit. While I think it's true that the most
> correct way to answer the question "Is this address a neighbor?" is to
> consider addresses in any FIB, I'm not sure it's necessary. Since the caller
> is specifying which interface this address should be a neighbor on, it's safe
> to consider only that interface's FIB because interface routes (ie., those
> routes with neighbors) will always be added there.
Remember, the interface fib only matters for forwarding packets. It's totally
valid for an interface to have multiple addresses assigned, each of which is on
a different fib. So, to correctly determine whether `addr` is a neighbor of
`ifp`, we must either
1. Loop over all fibs, and check whether `addr` is a neighbor of `ifp` on any
of them, or
2. Loop over all addresses assigned to `ifp`, and check whether `addr` is a
neighbor of `ifp` on that address's fib. I'm guessing that this will be the
slower option, because an interface can have arbitrarily many addresses
> jhujhiti_adjectivism.org wrote in nd6.c:1353
> Should we pass the ifp->if_fib here? We compare ifps on line 1355, so
> searching all FIBs is usually fine, but if we have two identical addresses in
> two different FIBs, we could find the wrong one here and end up returning
> false.
The original code seems too complicated. I think it should go a little like
this (locks elided):
if (ifp->if_flags & IFF_POINTOPOINT) {
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
if (ifa->ifa_addr->sa_family != addr->sa_family)
continue;
if (ifa->ifa_dstaddr != NULL &&
sa_equal(addr, ifa->ifa_dstaddr)) {
return (1);
}
}
}
No unnecessary looping over either fibs or interfaces.
> nd6.c:1310
> if ((pr->ndpr_stateflags & NDPRF_ONLINK) == 0) {
> /* Always use the default FIB here. */
> dst6 = (const struct sockaddr *)&pr->ndpr_prefix;
This comment is incorrect now.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9451
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: jhujhiti_adjectivism.org, #network, bz, asomers
Cc: jch, bz, imp, ae, freebsd-net-list
___
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"
[Differential] D9847: Try to extract the RFC1048 data from PXE
kczekirda added a reviewer: freebsd-net-list. REVISION DETAIL https://reviews.freebsd.org/D9847 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: kczekirda, oshogbo, bapt, tsoome, glebius, #network, freebsd-net-list ___ 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"
Re: VNET / netgraph jails -- Locking down?
I do something similar, but I rely entirely on vnet and PF instead of
netgraph. My host has two ethernet ports, so I use one for the host
and one for all of the jails. That makes the pf setup easier. I use
iocage to configure an ordinary vnet jail, bridged to the host's
second ethernet port. Then I configure pf.conf like this. This
ensures that the only traffic allowed into the jail is that destined
for its intended service, and the only traffic allowed out are
responses to inbound traffic. The jail is able to change its own IP
address, but if it does then PF will block all of its traffic.
www_services = "{ http, https, 8080 }"
host_iface = "em0"
dmz_iface = "em1"
www_jail_iface = "vnet0:1"
www_ip = "192.168.0.40"
set state-policy if-bound
scrub in
block in all
block out all
pass in on $host_iface
pass out on $host_iface
set skip on lo0
# Allow all traffic to the DMZ. Filtering happens on individual vnet
# interfaces
pass in on $dmz_iface
pass out on $dmz_iface
# Put the www jail in a DMZ. Don't allow outgoing traffic from it except for
# the webserver
pass out on $www_jail_iface proto tcp to $www_ip port $www_services keep state
-Alan
On Wed, Mar 1, 2017 at 10:36 AM, Julian Elischer wrote:
> many good questions but looking at what you are doing, maybe we should be
> asking you the questions.
> Certainly firewalling on the outside of the jail makes sense. I've not used
> ng_ipfw but it would make sense to do a quick santity check for every packet
> leaving each jail.
>
>
>
> On 14/2/17 9:47 am, Jeff Kletsky wrote:
>>
>> For several years I've been using netgraph to provide connectivity for
>> "service hosts" in jails on a "jail server"
>>
>> Since I'm finally getting the jail server off FreeBSD 9 and solidly onto
>> 11, I've got the chance to rewrite the scripting of how I'm handling jail
>> connectivity and am hoping that I can lock things down a bit better than
>> what I have presently.
>>
>>
>> The approach I use looks similar to that now in the jail examples.
>> Basically
>>
>> /---> ng_eiface_jail1
>> real_interface = ng_ether <---> ng_bridge <---> ng_eiface_jail2
>> \---> ng_eiface_jail3
>>
>> While this works well, it concerns me that the real interface has to be in
>> promiscuous mode (and have autosrc off).
>>
>> If one of the service jails is "taken over" then there isn't a way that I
>> know of to lock out changing the IP address of the interface it has, or
>> potentially gaining access to another VLAN through creation of a cloned
>> interface, especially if the bridge is off the parent interface, not off a
>> VLAN interface.
>>
>>
>> How do people manage this in practice when the jail has the risk of
>> compromise?
>>
>>
>> I prefer approaches where the jail's notion of it's own IP address is the
>> same as that of other hosts connecting to it, at least within my own little
>> private-address-space world.
>>
>>
>> One thing that I've been considering is:
>> * Configure the jail's IP on the real interface (or appropriate VLAN
>> interface) as an alias
>> * Send packets through ng_ipfw to an ng_eiface that the jail gets, using
>> ipfw and a lookup table
>> * Tag the packets on return with ng_tag with a unique identifier for that
>> jail's interface so ipfw can tell the only acceptable source IP
>> * Deny any so-tagged packets that don't have the proper source address
>>
>> (jail ID by itself is not enough for the outbound packets, as some of the
>> jails are dual homed.)
>>
>>
>> Has anyone tried this kind of method? Any other/better suggestions?
>>
>>
>> Would ng_ip_input be the appropriate way to "send" the packets coming from
>> the jail?
>>
>>
>> Thanks!
>>
>>
>> Jeff
>>
>>
>>
>>
>> ___
>> 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"
>>
>
> ___
> 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"
___
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"
Re: VNET / netgraph jails -- Locking down?
many good questions but looking at what you are doing, maybe we should be asking you the questions. Certainly firewalling on the outside of the jail makes sense. I've not used ng_ipfw but it would make sense to do a quick santity check for every packet leaving each jail. On 14/2/17 9:47 am, Jeff Kletsky wrote: For several years I've been using netgraph to provide connectivity for "service hosts" in jails on a "jail server" Since I'm finally getting the jail server off FreeBSD 9 and solidly onto 11, I've got the chance to rewrite the scripting of how I'm handling jail connectivity and am hoping that I can lock things down a bit better than what I have presently. The approach I use looks similar to that now in the jail examples. Basically /---> ng_eiface_jail1 real_interface = ng_ether <---> ng_bridge <---> ng_eiface_jail2 \---> ng_eiface_jail3 While this works well, it concerns me that the real interface has to be in promiscuous mode (and have autosrc off). If one of the service jails is "taken over" then there isn't a way that I know of to lock out changing the IP address of the interface it has, or potentially gaining access to another VLAN through creation of a cloned interface, especially if the bridge is off the parent interface, not off a VLAN interface. How do people manage this in practice when the jail has the risk of compromise? I prefer approaches where the jail's notion of it's own IP address is the same as that of other hosts connecting to it, at least within my own little private-address-space world. One thing that I've been considering is: * Configure the jail's IP on the real interface (or appropriate VLAN interface) as an alias * Send packets through ng_ipfw to an ng_eiface that the jail gets, using ipfw and a lookup table * Tag the packets on return with ng_tag with a unique identifier for that jail's interface so ipfw can tell the only acceptable source IP * Deny any so-tagged packets that don't have the proper source address (jail ID by itself is not enough for the outbound packets, as some of the jails are dual homed.) Has anyone tried this kind of method? Any other/better suggestions? Would ng_ip_input be the appropriate way to "send" the packets coming from the jail? Thanks! Jeff ___ 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" ___ 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"
[Bug 212749] bridge fragment can leak mbufs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212749 Kristof Provost changed: What|Removed |Added CC||k...@freebsd.org --- Comment #3 from Kristof Provost --- (In reply to Aiko Barz from comment #2) It was merged to stable/11, but I don't think that was in time for 11.0. It'll turn up in 11.1 -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
Sockets unexpected behavior
Howdy, I'm maintainer of www/obhttpd - OpenBSD httpd. Currently I'm trying to update the port to current version of httpd in OpenBSD cvs and I'm facing problem with the sockets during startup. There is major change in sockets management which cause httpd to exited abnormally on FreeBSD during startup with correct configuration file: # ./httpd -d -f ~/nkolev/httpd-multi.conf startup server: invalid location lost child: pid 55160 exited abnormally server: invalid location server: invalid location lost child: pid 55159 exited abnormally lost child: pid 55161 exited abnormally logger exiting, pid 55162 parent terminating, pid 55158 and then the output of sockstat is: # sockstat -l | grep ":80 " ?? ? ? tcp4 192.168.104.17:80 *:* ?? ? ? tcp4 127.0.0.1:80 *:* ?? ? ? tcp4 192.168.104.17:80 *:* ?? ? ? tcp4 127.0.0.1:80 *:* ?? ? ? tcp4 192.168.104.17:80 *:* ?? ? ? tcp4 127.0.0.1:80 *:* I'm even able to connect to the socket once: # telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. ^] telnet> quit Connection closed. I'm facing the same problem on 11-STABLE and 10-STABLE and with IPv6 configuration also. I assume sockets should not appear in sockstat output after abnormally exit of httpd. Is this httpd problem or FreeBSD kernel problem? Regards, Nikola -- Nikola Kolev k...@chaosophia.net https://github.com/koue/ ___ 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"
[Bug 212749] bridge fragment can leak mbufs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212749 Aiko Barz changed: What|Removed |Added CC||a...@torrentkino.de --- Comment #2 from Aiko Barz --- (In reply to Olivier Cochard from comment #1) That patch you described is not yet part of the 11.0 release. Am I right? Kind regards, Aiko -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530
On Tue, Feb 28, 2017 at 3:13 AM, Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER SCIENCE CORP] wrote: > As a summarywe have a Dell R530 with a Chelsio T580 cardwith -CURRENT. > > In an attempt to reduce the time the system was taking to look for the > cpus; we changed the BIOS setting to let the system have 8 visible cores > and tested cxl* and vcxl* chelsio interfaces. Scores are still way lower > than what we expected: > > > Based on previous scores with Centos 7 (over 3M pps), we can assume that > it is not the hardware. However, we are still looking for a reason of > why are we getting these scores. > > Any feedback or suggestion would be highly appreciated. > > During your bench load, can you display each queue usage of your cxl interface and post the result here ? You can use this python script (from Alexander Chernikov): https://github.com/ocochard/BSDRP/blob/master/BSDRP/Files/usr/local/bin/nic-queue-usage Here is an example showing traffic shared between all 8 queues: [root@hp]~# nic-queue-usage cxl0 [Q0 346K/s] [Q1 343K/s] [Q2 339K/s] [Q3 338K/s] [Q4 338K/s] [Q5 338K/s] [Q6 343K/s] [Q7 346K/s] [QT 2734K/s 3269K/s -> 0K/s] [Q0 347K/s] [Q1 344K/s] [Q2 339K/s] [Q3 339K/s] [Q4 338K/s] [Q5 338K/s] [Q6 343K/s] [Q7 346K/s] [QT 2735K/s 3277K/s -> 0K/s] [Q0 344K/s] [Q1 341K/s] [Q2 338K/s] [Q3 338K/s] [Q4 337K/s] [Q5 337K/s] [Q6 342K/s] [Q7 345K/s] [QT 2727K/s 3262K/s -> 0K/s] [Q0 355K/s] [Q1 352K/s] [Q2 348K/s] [Q3 349K/s] [Q4 348K/s] [Q5 347K/s] [Q6 352K/s] [Q7 355K/s] [QT 2809K/s 3381K/s -> 0K/s] [Q0 351K/s] [Q1 348K/s] [Q2 344K/s] [Q3 343K/s] [Q4 342K/s] [Q5 344K/s] [Q6 349K/s] [Q7 352K/s] [QT 2776K/s 3288K/s -> 0K/s] [Q0 344K/s] [Q1 341K/s] [Q2 338K/s] [Q3 339K/s] [Q4 338K/s] [Q5 338K/s] [Q6 343K/s] [Q7 346K/s] [QT 2731K/s 3261K/s -> 0K/s] Thanks ___ 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"
