Re: How to tell if a network interface was renamed (and from what)

[Kyle Evans]

On 11/18/23 19:15, Zhenlei Huang wrote:



On Nov 19, 2023, at 6:20 AM, Mina Galić <mailto:free...@igalic.co>> wrote:


Hi folks,

Linux has an "easy" way of telling if an interface has been renamed.
See cloud-init's is_renamed function: 
https://github.com/canonical/cloud-init/blob/5496745b394f9b7b9eaf57fd619330d484ce2da8/cloudinit/net/__init__.py#L338-L350 <https://github.com/canonical/cloud-init/blob/5496745b394f9b7b9eaf57fd619330d484ce2da8/cloudinit/net/__init__.py#L338-L350>
This code reads /sys/class/net//name_assign_type and if that is 
3 or 4, it's been renamed.


I can't even think of an sensible way of replicating that.
I can only think of terrible / wrong way of finding it out:

dmesg | grep "changing name to ''"

a less terrible method would be to check for, say:

sysctl dev..0.%driver

if that fails, we probably have a renamed interface… but we don't know 
what it was renamed from, and this only works for *real* interfaces, 
not for cloned devices, or epairs.


Now, ignoring my terrible hacky attempts at command line tooling, I 
would also happily accept a solution in C, which is fairly easily 
accessible from Python, and which we already use to figure out the 
uptime (or rather, the boottime): 
https://github.com/canonical/cloud-init/blob/5496745b394f9b7b9eaf57fd619330d484ce2da8/cloudinit/util.py#L2073-L2105 <https://github.com/canonical/cloud-init/blob/5496745b394f9b7b9eaf57fd619330d484ce2da8/cloudinit/util.py#L2073-L2105>


Looking forward to reading your ideas.


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 
<https://reviews.freebsd.org/D28247>  to get the device name (physical 
ones) but it is not perfect and not completed.


So may I ask why you need to know if a network interface was renamed ?



Just last week I found this quite a pain as well; once an interface has 
been renamed, if it's not a pseudo-interface with an obvious group 
there's no clear way, AFAICT, to determine which driver created it 
without perusing pciconf output or whatnot and hopefully being able to 
associate the NICs listed with the new names (easier when there's only 
one NIC, of course).  Kind of a pain when you're working on a remote 
machine that you're not at all familiar with.


Thanks,

Kyle Evans

domain(9) reviews

[Kyle Evans]

Hi,

I have a small series of domain reviews that I opened a while ago; I'd
like to push them out of my queue within the next week or so if
anyone's interested in reviewing them:

https://reviews.freebsd.org/D25062 - allow domains to probe for
availability, so that domains inherently tied to machine/vm features
(e.g. hvsock) can more cleanly not attach on non-HyperV guests

https://reviews.freebsd.org/D25459 - remove a race as a result of
loading a kmod that attaches a domain, making it safe to add a domain
after domainfinalize() and kill off that particular warning message on
boot

https://reviews.freebsd.org/D26709 - tracks protocols that have
fasttimo/slowtimo callbacks so that pfslowtimo() and pffasttimo() only
iterate over protocols actually known to have callbacks (very few)

Thanks,

Kyle Evans

Re: Client Networking Issues / NIC Lab

[Kyle Evans]

On Fri, Apr 23, 2021 at 12:22 AM Kevin Bowling  wrote:
>
> Greetings,
>
> [... snip ...]
>
> Tehuti Networks seems to have gone out of business.  Probably not
> worth worrying about.
>

That's unfortunate. I had a box of their 10G NICs and I got them to
put a driver up for review[0][1], but they weren't very responsive and
the existing codebase was in pretty rough shape.

Beyond that, your #3 seems to be the most appealing. #2 could probably
work in the mid-to-long term, but we'd likely be better off
bootstrapping interest with solid community-supported drivers then
reaching out to vendors once we can demonstrate that plan field of
dreams can work and drive some substantial amount of business.

Thanks,

Kyle Evans

[0] https://reviews.freebsd.org/D18856
[1] https://reviews.freebsd.org/D19433
___
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: source of ether address for tap0 ?

[Kyle Evans]

On Tue, Apr 20, 2021 at 4:38 AM Kurt Jaeger  wrote:
>
> Hello,
>
> does anyone know how the system selects the MAC/ether adress of a
> newly-created tap0 device ?
>
> ifconfig tap0 create
>
> has this:
>
> tap0: flags=8802 metric 0 mtu 1500
> options=8
> ether 58:9c:fc:10:98:02
> groups: tap
> media: Ethernet autoselect
> status: no carrier
> nd6 options=29
>
> How is that selected ?
>
> We had a case where two devices selected the same ether/MAC...
>

tap MACs are derived from the hostid (/etc/hostid) -- you generally
end up with the same MAC in one of two scenarios:

1.) The hosts have identical /etc/hostid (bad, probably an issue with
machine provisioning where the hostid file is getting copied and thus,
not regenerated at boot?), or
2.) hostid isn't being preloaded

#2 may be the case if it's a machine that doesn't use loader, or
you've specifically disabled it with hostuuid_load="NO" in
loader.conf. I've got a WIP to improve the failure mode for that one
to fallback to a fully random MAC.

#1 can be fixed by moving hostid out of the way and letting the hostid
rc scripts generate and save a new one, assuming they're not getting
their data from bogus/duplicate smbios uuids.

Thanks,

Kyle Evans
___
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: Domain Patches

[Kyle Evans]

On Wed, Oct 7, 2020 at 11:45 AM Kyle Evans  wrote:
>
> Hi,
>
> I have a couple of domain patches in review, if anyone would like to
> comment/review the area:
>
> https://reviews.freebsd.org/D25062 adds a dom_probe callback so that
> domains can indicate whether they should be supported at all or not.
> This avoids some dirty stuff in domains that may not be supported
> based on the hardware that's present (e.g. hvsock included in the
> review, which shouldn't be available outside of HyperV). Instead of
> having to account for circumstances like that in individual callbacks,
> this is a single hammer to prevent any further reach into the domain.
>
> D25062 also updates domain(9) to reflect some changes from the past 11
> years (splitting initialization out into domain_init, dom_destroy
> addition).
>
> https://reviews.freebsd.org/D25459 should make it safe to add domains
> after domainfinalize (i.e. they can be loadable at runtime). The big
> issue with doing this previously is that pfslowtimo/pffasttimo have
> already been setup and may be called on domains that aren't completely
> initialized. There are some additional races re: socket creation that
> should be addressed, but this review should be sufficient for at least
> removing the warning.

Add https://reviews.freebsd.org/D26709 to the list -- in D25459, mjg
suggested adding some lists with domains or protocols that actually
have {slow,fast}timo callbacks to avoid additional overhead from
branching+atomics in those callbacks.

Thanks,

Kyle Evans
___
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"

Domain Patches

[Kyle Evans]

Hi,

I have a couple of domain patches in review, if anyone would like to
comment/review the area:

https://reviews.freebsd.org/D25062 adds a dom_probe callback so that
domains can indicate whether they should be supported at all or not.
This avoids some dirty stuff in domains that may not be supported
based on the hardware that's present (e.g. hvsock included in the
review, which shouldn't be available outside of HyperV). Instead of
having to account for circumstances like that in individual callbacks,
this is a single hammer to prevent any further reach into the domain.

D25062 also updates domain(9) to reflect some changes from the past 11
years (splitting initialization out into domain_init, dom_destroy
addition).

https://reviews.freebsd.org/D25459 should make it safe to add domains
after domainfinalize (i.e. they can be loadable at runtime). The big
issue with doing this previously is that pfslowtimo/pffasttimo have
already been setup and may be called on domains that aren't completely
initialized. There are some additional races re: socket creation that
should be addressed, but this review should be sufficient for at least
removing the warning.

Thanks,

Kyle Evans
___
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: Abandoning ifnet work

[Kyle Evans]

On Thu, Jul 23, 2020 at 3:38 AM Hans Petter Selasky  wrote:
>
> On 2020-07-23 05:45, Kyle Evans wrote:
> > abandoning because the review process for this area is simply not
>
> Are you looking for this:
>
> https://reviews.freebsd.org/D24914
>

No, not at all. The race I was reliably hitting is more like:

1. epair sets its vnet 'to the other half' in epair_clone_destroy
2. destroys that
3. goes to CURVNET_RESTORE(), but the vnet we were in has been
destroyed out from underneath us and we die in a fire trying to check
saved_vnet->vnet_magic_n

Thanks,

Kyle Evans
___
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"

Abandoning ifnet work

[Kyle Evans]

Hi,

Just a heads up... I had been doing some ifnet work that I'm now
abandoning because the review process for this area is simply not
worth it: D22691[0]. I'd quite like to see someone else pick it up and
finish out, though... I've been running with some success an earlier
version of this that coordinates if_vmove() and vnet shutdown's
evacuation of ifnets with if_detach() to render some of the common
epair/vnet races harmless.

Feel free to tag me for reviewing if you want to pick it up.

Thanks,

Kyle Evans

[0] https://reviews.freebsd.org/D22691
___
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] D24989: netinet: Generate a random RSS key on boot.

[kevans (Kyle Evans)]

kevans added inline comments.

INLINE COMMENTS

> neel_neelc.org wrote in rss_config.c:251
> I'm not sure, I'm not an expert on entropy, but we could wait for entropy 
> before calling this.

When in doubt, perhaps CC #csprng 

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D24989/new/

REVISION DETAIL
  https://reviews.freebsd.org/D24989

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org
Cc: kevans, debdrup, rwatson, imp, ae, melifaro, #contributor_reviews_base, 
freebsd-net-list, mmacy, kpraveen.lkml_gmail.com, marcnarc_gmail.com, 
simonvella_gmail.com, novice_techie.com, tommi.pernila_iki.fi, 
krzysztof.galazka_intel.com
___
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: Bridges on VLAN-tagged interfaces.

[Kyle Evans]

On Wed, May 29, 2019 at 9:13 AM Rodney W. Grimes
 wrote:
>
> > [I cast level 3 necromancy and revive this thread from the dead]
>
> But this is all layer 2 stuff :-)
>
> >
> > On Tue, Mar 19, 2019 at 4:02 AM Eric Bautsch  wrote:
> > >
> > > Hi Patrick.
> > >
> > >
> > > I get that point, but then I have two options only: I somehow convince 
> > > the BIOS
> > > to do a network boot over a VLAN for installation - not a capability this 
> > > BIOS
> > > appears to have, or I end up creating a whole new VLAN that's either 
> > > routed or
> > > has YP, DNS, time and installation servers on it. That's a massive 
> > > headache
> > >
> > > It'd be much neater if FreeBSD could handle the tagged/untagged traffic. 
> > > It just
> > > works (TM) on Solaris and Linux, so I expected it to do the same on 
> > > FreeBSD... :-(
> > >
> > > Surely, there must be a way
> > >
> >
> > This is a product of how vlans and bridges work on FreeBSD, but I
> > think it doesn't have to be this way. Let's break it down: re0.33 is a
> > vlan(4) attached to re0. Ordinary traffic coming in on vlan 33 does
> > this little dance number:
> >
> > incoming -> re0:ether_input -> ether_demux -> vlan_input -> 
> > re0.33:ether_input
> >
> > Let's mix it up: add re0.33 to a bridge0. Traffic is passed to
> > potential bridge for processing in ether_input_internal prior to
> > ether_demux, so you end up with this setup:
> >
> > incoming -> re0:ether_input -> ether_demux -> vlan_input ->
> > re0.33:ether_input -> bridge0:bridge_input -> ether_demux
> >
> > Now let's evolve into our final form. add re0 to bridge1; this is what
> > I'm most certain is happening
> >
> > incoming -> re0:ether_input -> bridge1:bridge_input -> bridge_forward
> >
> > oops. bridge1 grabs the re0 packet before we have a chance to do any
> > vlan processing. Traffic isn't bound for *this* bridge or any of the
> > other interfaces, so it will perform the bridge forwarding function
> > and everything goes off the rails.
>
> That makes sense as to what I saw happening last time I had
> issues with this.
>
> >
> > This is not an unsolvable problem, though, from a developer
> > perspective. I think if_bridge(4) simply needs to be taught a little
> > about if_vlan(4) (needs more hooks...) so that traffic coming in on
> > re0 with a vlan that matches an if_vlan(4) interface doesn't get
> > snagged in the wrong bridge too early.
>
> Sounds reasonable, both vlan and bridge/switch are layer 2
> functionality and should fully co-operate.  One thing to
> note if you are going to dig around in this code it is known
> to have poor performance and is one of the bottleneck areas
> for getting packets in and out of a bhyve vm via the tap to bridge
> path.
>
> I defanitly would enjoying having the configuration and performance
> of the ESXi vswitch paradigm in FreeBSD if we can implement it with
> this code in a reasonable fasion.
>
> I can provide some sample config files if desired.
>

I think something like [0] would do the trick, but this is only
compile-tested and probably not quite correct. Patch bypasses all
bridge checking if we have an if_vlan(4) interface that this mbuf will
be getting demuxed to. After bypassing the bridge re0 is in, it'll hit
ether_demux and peel off any 802.1q headers and reinject it to
ether_input. This time it'll hit the re0.33 bridge sans vlan tag and
theoretically do the right thing. If mbuf is tagged for vlan != 33 and
we don't have an re0. for it, it'll still hit the re0 bridge and
maintain current behavior.

Thanks,

Kyle Evans

[0] https://people.freebsd.org/~kevans/bridge-vlan.diff
___
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: Bridges on VLAN-tagged interfaces.

[Kyle Evans]

[I cast level 3 necromancy and revive this thread from the dead]

On Tue, Mar 19, 2019 at 4:02 AM Eric Bautsch  wrote:
>
> Hi Patrick.
>
>
> I get that point, but then I have two options only: I somehow convince the 
> BIOS
> to do a network boot over a VLAN for installation - not a capability this BIOS
> appears to have, or I end up creating a whole new VLAN that's either routed or
> has YP, DNS, time and installation servers on it. That's a massive 
> headache
>
> It'd be much neater if FreeBSD could handle the tagged/untagged traffic. It 
> just
> works (TM) on Solaris and Linux, so I expected it to do the same on 
> FreeBSD... :-(
>
> Surely, there must be a way
>

This is a product of how vlans and bridges work on FreeBSD, but I
think it doesn't have to be this way. Let's break it down: re0.33 is a
vlan(4) attached to re0. Ordinary traffic coming in on vlan 33 does
this little dance number:

incoming -> re0:ether_input -> ether_demux -> vlan_input -> re0.33:ether_input

Let's mix it up: add re0.33 to a bridge0. Traffic is passed to
potential bridge for processing in ether_input_internal prior to
ether_demux, so you end up with this setup:

incoming -> re0:ether_input -> ether_demux -> vlan_input ->
re0.33:ether_input -> bridge0:bridge_input -> ether_demux

Now let's evolve into our final form. add re0 to bridge1; this is what
I'm most certain is happening

incoming -> re0:ether_input -> bridge1:bridge_input -> bridge_forward

oops. bridge1 grabs the re0 packet before we have a chance to do any
vlan processing. Traffic isn't bound for *this* bridge or any of the
other interfaces, so it will perform the bridge forwarding function
and everything goes off the rails.

This is not an unsolvable problem, though, from a developer
perspective. I think if_bridge(4) simply needs to be taught a little
about if_vlan(4) (needs more hooks...) so that traffic coming in on
re0 with a vlan that matches an if_vlan(4) interface doesn't get
snagged in the wrong bridge too early.

Thanks,

Kyle Evans
___
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"

if_bridge(4)/bpf on incoming packets

[Kyle Evans]

Hi,

Given a setup like:

ifconfig bridge0 create
ifconfig bridge0 addm em0 addm wlan0 up

Packets coming in on em0 that get routed to wlan0 by the bridge will
not be passed over to wlan0's bpf(4). I have an open review [0] that
proposes changing this so that if we're passing traffic over a bridge,
it gets exposed to the destination interface's bpf interface assuming
it's not the interface that just injected it into the bridge.

I don't know the history here, though- is there any particular reason
bridge doesn't/shouldn't do this now, or is it just that it's not
useful by conventional (read: almost all) usage of a bridge?

My motivation is that in a particular testing setup I am playing with,
either em0 or bridge0 get a DHCP address and wlan0 (actually not wlan0
in my testing setup, but keeping with the above example for
convenience) also needs to pull a DHCP address from the em0 side of
the bridge for... reasons. =) I also anticipate needing to actually
monitor traffic received from the bridge by wlan0 along with traffic
received on wlan0, rather than monitoring the bridge, so the above
change makes this most convenient.

Thanks,

Kyle Evans

[0] https://reviews.freebsd.org/D19586
___
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: if_bridge(4)/bpf on incoming packets

[Kyle Evans]

On Sat, Mar 16, 2019 at 11:37 PM Kyle Evans  wrote:
>
> On Sat, Mar 16, 2019 at 11:17 PM Kyle Evans  wrote:
> >
> > Hi,
> >
> > Given a setup like:
> >
> > ifconfig bridge0 create
> > ifconfig bridge0 addm em0 addm wlan0 up
> >
> > Packets coming in on em0 that get routed to wlan0 by the bridge will
> > not be passed over to wlan0's bpf(4). I have an open review [0] that
> > proposes changing this so that if we're passing traffic over a bridge,
> > it gets exposed to the destination interface's bpf interface assuming
> > it's not the interface that just injected it into the bridge.
> >
> > I don't know the history here, though- is there any particular reason
> > bridge doesn't/shouldn't do this now, or is it just that it's not
> > useful by conventional (read: almost all) usage of a bridge?
> >
>
> Further reading leads me to believe that it's maybe technically a bug
> -- see [1], where packets running through bridge_forward and destined
> for a member interface *do* get pushed through bpf. The problem is
> that this can never happen, because we've either grabbed it and bailed
> out in bridge_input [2] before we call bridge_forward, or we're
> calling bridge_forward for broadcast/multicast [3].
>
> This also leads me to wonder if we should be invoking pfil hooks
> before bailing out of bridge_input in this case, though, so that pfil
> hooks have a chance to operate on bridge-passed local traffic as well.

Apologies for the extra noise... this last e-mail was me failing to
notice that the linked snippet is tapping it for the bridge interface,
not the destination interface. This is likely irrelevant to my
original question.

> [1] 
> https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l
> [2] 
> https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l2480
> [3] 
> https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l2367
___
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: if_bridge(4)/bpf on incoming packets

[Kyle Evans]

On Sat, Mar 16, 2019 at 11:17 PM Kyle Evans  wrote:
>
> Hi,
>
> Given a setup like:
>
> ifconfig bridge0 create
> ifconfig bridge0 addm em0 addm wlan0 up
>
> Packets coming in on em0 that get routed to wlan0 by the bridge will
> not be passed over to wlan0's bpf(4). I have an open review [0] that
> proposes changing this so that if we're passing traffic over a bridge,
> it gets exposed to the destination interface's bpf interface assuming
> it's not the interface that just injected it into the bridge.
>
> I don't know the history here, though- is there any particular reason
> bridge doesn't/shouldn't do this now, or is it just that it's not
> useful by conventional (read: almost all) usage of a bridge?
>

Further reading leads me to believe that it's maybe technically a bug
-- see [1], where packets running through bridge_forward and destined
for a member interface *do* get pushed through bpf. The problem is
that this can never happen, because we've either grabbed it and bailed
out in bridge_input [2] before we call bridge_forward, or we're
calling bridge_forward for broadcast/multicast [3].

This also leads me to wonder if we should be invoking pfil hooks
before bailing out of bridge_input in this case, though, so that pfil
hooks have a chance to operate on bridge-passed local traffic as well.

[1] 
https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l
[2] 
https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l2480
[3] 
https://svnweb.freebsd.org/base/head/sys/net/if_bridge.c?view=markup&pathrev=345194#l2367
___
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: iwn(4) association issues in 11-Stable (and maybe RC)

[Kyle Evans]

On Wed, Aug 24, 2016 at 2:45 PM, Glen Barber  wrote:
> Dumb question, but with reason.
>
> Does ifconfig(8) actually show wlan0 'UP'?
>
> I'm asking this because I'm seeing something strange locally on one
> machine.
>
> Glen

Follow up dumb question, but I've very recently experienced (with ath(4),
however) the following:

* wlan0 is declared 'UP' and even associated, as declared by ifconfig(8)
* DHCP seems successful- wlan0 has my static reservation

However, the machine would otherwise seem to have no network. All ping(8)
packets lost, but the network is otherwise fine. Related, by chance?
___
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: How can I send packets to 255.255.255.255 from the command line?

[Kyle Evans]

Hello!

Is netcat [nc(1)] an option? It doesn't seem to have any objections to
doing this, but I don't have a setup to test it properly with at the
moment.

Thanks,

Kyle Evans

On Thu, Aug 18, 2016 at 2:29 PM, Ryan Stone  wrote:
> I want to test a change to broadcast packet handling and I want to confirm
> that 255.255.255.255 is still handled correctly. Are there any command-line
> tools in FreeBSD that can send to the broadcast address?  ping
> 255.255.255.255 does not work correctly, unfortunately.
> ___
> 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"