dhclient cause up/down cycle after 239356 ?

[satan]

Hi all,

After last update my home machine begin doin some strange things -

Aug 21 08:28:25 home kernel: fxp0: link state changed to UP
Aug 21 08:28:25 home kernel: fxp0: link state changed to DOWN
Aug 21 08:28:27 home kernel: fxp0: link state changed to UP
Aug 21 08:28:33 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 21 08:28:33 home kernel: fxp0: link state changed to DOWN
Aug 21 08:28:33 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 21 08:28:33 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 21 08:28:33 home dhclient: New Routers (fxp0): xx.xx.xx.1
Aug 21 08:28:33 home dhclient[1395]: Interface fxp0 is down, dhclient exiting
Aug 21 08:28:33 home dhclient[1339]: connection closed
Aug 21 08:28:33 home dhclient[1339]: exiting.
Aug 21 08:28:35 home kernel: fxp0: link state changed to UP
Aug 21 08:28:35 home kernel: fxp0: link state changed to DOWN
Aug 21 08:28:37 home kernel: fxp0: link state changed to UP
Aug 21 08:28:40 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 21 08:28:40 home kernel: fxp0: link state changed to DOWN
Aug 21 08:28:40 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 21 08:28:40 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 21 08:28:40 home dhclient: New Routers (fxp0): xx.xx.xx.1
Aug 21 08:28:40 home dhclient[1519]: Interface fxp0 is down, dhclient exiting
Aug 21 08:28:40 home dhclient[1465]: connection closed
Aug 21 08:28:40 home dhclient[1465]: exiting.
Aug 21 08:28:42 home kernel: fxp0: link state changed to UP
Aug 21 08:28:42 home kernel: fxp0: link state changed to DOWN
Aug 21 08:28:44 home kernel: fxp0: link state changed to UP
Aug 21 08:28:48 home dhclient: New IP Address (fxp0): xx.xx.xx.xx

I have next configuration

in rc.conf - ifconfig_fxp0="SYNCDHCP"
in /etc/dhclient.conf
 interface "fxp0" {
   supersede domain-name "home";
   supersede domain-name-servers 127.0.0.1;
 }

Also /etc/start_if.fxp0
With content -

ifconfig fxp0 ether xx:xx:xx:xx:xx:xx
ifconfig fxp0 -tso
ifconfig fxp0 polling

And yes, no problem with static ip on fxp0 and no up/down sequence



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Garrett Cooper]

On Tue, Aug 21, 2012 at 2:55 AM, Vitalij Satanivskij <[hidden email]> wrote:
> Hi all,
>
> After last update my home machine begin doin some strange things -

...

Try reverting r239356 -- if that works, then please let jhb@ know.
-Garrett
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, Garrett.
You wrote 21 августа 2012 г., 15:18:05:

GC> Try reverting r239356 -- if that works, then please let jhb@ know.
  I'm confused by  this commit, because it seems (from comment alone),
that  dhclient  will not work without devd anymore (with "synchronous
dhcp" option in rc.conf).
  Am I right?

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, Lev.
You wrote 21 августа 2012 г., 15:40:35:

GC>> Try reverting r239356 -- if that works, then please let jhb@ know.
LS>   I'm confused by  this commit, because it seems (from comment alone),
LS> that  dhclient  will not work without devd anymore (with "synchronous
LS> dhcp" option in rc.conf).
LS>   Am I right?
 Also,  I  don't  like idea of removing IP address from interface when
cable is unplugged. It was very disturbing behavior of Windows
machines for years. I've unplug cable to change switch port for only a
second and all connections are broken, even if one second later
dhcpclient receive SAME lease! I don't like this. FreeBSD was very
tolerant to unplugging cable for eons, and I (and not only me) like
it. If I understand this change properly, it is no more the case :(

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, Garrett.
You wrote 21 августа 2012 г., 15:40:35:

GC>> Try reverting r239356 -- if that works, then please let jhb@ know.
LS>   I'm confused by  this commit, because it seems (from comment alone),
LS> that  dhclient  will not work without devd anymore (with "synchronous
LS> dhcp" option in rc.conf).
LS>   Am I right?
  And if I'm right about understanding what this change does, it is
 POLA violation for sure. Both consequences: unable to use dhcclient
 without devd (user will need to restart it by hands after each cable
 unplugging event) and removing IP address from interface on cable
 unplugging or other interface down event but before lease is expired.

  If I'm right in understanding this commit, I vote to back it out and
 find better solution, may be, two new options: one to remove IP and
 one to exit on interface down. And default behavior should be OLD
 ONE about IP address in any case and OLD ONE about exit in case when
 dhclient isn't started by devd, but by rc scripts directly.

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Slawa Olhovchenkov]

On Tue, Aug 21, 2012 at 03:45:48PM +0400, Lev Serebryakov wrote:

> Hello, Lev.
> You wrote 21 августа 2012 г., 15:40:35:
>
> GC>> Try reverting r239356 -- if that works, then please let jhb@ know.
> LS>   I'm confused by  this commit, because it seems (from comment alone),
> LS> that  dhclient  will not work without devd anymore (with "synchronous
> LS> dhcp" option in rc.conf).
> LS>   Am I right?
>  Also,  I  don't  like idea of removing IP address from interface when
> cable is unplugged. It was very disturbing behavior of Windows
> machines for years. I've unplug cable to change switch port for only a
> second and all connections are broken, even if one second later
> dhcpclient receive SAME lease! I don't like this. FreeBSD was very
> tolerant to unplugging cable for eons, and I (and not only me) like
> it. If I understand this change properly, it is no more the case :(

Not only cable.
Turn on microwave, lost WiFi connection and lost all open ssh
session (and other network connection).

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[John Baldwin]

On Tuesday, August 21, 2012 7:53:08 am Lev Serebryakov wrote:

> Hello, Garrett.
> You wrote 21 августа 2012 г., 15:40:35:
>
> GC>> Try reverting r239356 -- if that works, then please let jhb@ know.
> LS>   I'm confused by  this commit, because it seems (from comment alone),
> LS> that  dhclient  will not work without devd anymore (with "synchronous
> LS> dhcp" option in rc.conf).
> LS>   Am I right?
>   And if I'm right about understanding what this change does, it is
>  POLA violation for sure. Both consequences: unable to use dhcclient
>  without devd (user will need to restart it by hands after each cable
>  unplugging event) and removing IP address from interface on cable
>  unplugging or other interface down event but before lease is expired.
>
>   If I'm right in understanding this commit, I vote to back it out and
>  find better solution, may be, two new options: one to remove IP and
>  one to exit on interface down. And default behavior should be OLD
>  ONE about IP address in any case and OLD ONE about exit in case when
>  dhclient isn't started by devd, but by rc scripts directly.

Humm.  devd is the more common case, and we explicitly don't use devd to start
dhclient on boot even when devd is enabled (so out of the box dhcp would first
be started by rc, but would be restarted by devd).

Another option is to rework dhclient to work like it does on OpenBSD where it
renews its lease if the link bounces, but to not exit when the link goes down.  
That case would fix the currently broken case that you unplug your cable, take
your laptop over to another network (e.g. take it home if suspend/resume
works), then plug it back in and are still stuck with your old IP.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, John.
You wrote 21 августа 2012 г., 17:34:31:

JB> Humm.  devd is the more common case, and we explicitly don't use devd to start
JB> dhclient on boot even when devd is enabled (so out of the box dhcp would first
JB> be started by rc, but would be restarted by devd).
  It  is  strange,  and,  maybe, changed some time ago, because when I
disable "devd" on my NanoBSD-based router (about year or year and half
ago), I've spent several hours to understand, why dhclient doesn't
start anymore. And I need to add this to rc.conf:

synchronous_dhclient="YES"

JB> Another option is to rework dhclient to work like it does on OpenBSD where it
JB> renews its lease if the link bounces, but to not exit when the link goes down.
  Yes, it looks like proper solution.

JB> That case would fix the currently broken case that you unplug your cable, take
JB> your laptop over to another network (e.g. take it home if suspend/resume
JB> works), then plug it back in and are still stuck with your old IP.
  Yep. But _committed_ solution is very bad. For example, my ISP's
 switch lost link every second day for second or two. I don't want to
 lost all open connections, firewall state, etc, and to restart
 dhclinet by hands, especially, when I'\m not at home anf my
 girlfriend is. in such case. Another good example was provided by
 Slava -- WiFi could disconnect for 10-15 seconds for multiple
 reasons, and dropping of IP and all connections in such case is MAJOR
 headache.

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Ian Lepore]

On Tue, 2012-08-21 at 19:04 +0400, Lev Serebryakov wrote:

> Hello, John.
> You wrote 21 августа 2012 г., 17:34:31:
>
> JB> Humm.  devd is the more common case, and we explicitly don't use devd to start
> JB> dhclient on boot even when devd is enabled (so out of the box dhcp would first
> JB> be started by rc, but would be restarted by devd).
>   It  is  strange,  and,  maybe, changed some time ago, because when I
> disable "devd" on my NanoBSD-based router (about year or year and half
> ago), I've spent several hours to understand, why dhclient doesn't
> start anymore. And I need to add this to rc.conf:
>
> synchronous_dhclient="YES"
>
> JB> Another option is to rework dhclient to work like it does on OpenBSD where it
> JB> renews its lease if the link bounces, but to not exit when the link goes down.
>   Yes, it looks like proper solution.
>
> JB> That case would fix the currently broken case that you unplug your cable, take
> JB> your laptop over to another network (e.g. take it home if suspend/resume
> JB> works), then plug it back in and are still stuck with your old IP.
>   Yep. But _committed_ solution is very bad. For example, my ISP's
>  switch lost link every second day for second or two. I don't want to
>  lost all open connections, firewall state, etc, and to restart
>  dhclinet by hands, especially, when I'\m not at home anf my
>  girlfriend is. in such case. Another good example was provided by
>  Slava -- WiFi could disconnect for 10-15 seconds for multiple
>  reasons, and dropping of IP and all connections in such case is MAJOR
>  headache.
>

I don't understand all this talk that makes it sound like you lose your
existing network connections when dhclient exits.  I don't experience
anything like that at all, and never have.  I just pulled the network
cable on this machine, did "sudo killall dhclient", plugged the network
back in, I still have all my ssh connections to the world in a dozen
open windows and can interact with any of them.  Then I did "sudo
dhclient re0" (simulating devd restarting dhclient on link-up) and it
reacquired a lease for the same IP it had before I killed it, and still
all my open connections are open.

It has worked this way for me for years.  Does it somehow not work this
way for everyone?

-- Ian


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, Ian.
You wrote 21 августа 2012 г., 19:16:03:

IL> It has worked this way for me for years.  Does it somehow not work this
IL> way for everyone?
   Please, read comment to r239356. Starting from this revision
 dhclient exists on interface down and _remiove_ IP address from
 interface. Removal of address from interface will drop all open
 connections, which uses this address.

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Ian Lepore]

On Tue, 2012-08-21 at 19:26 +0400, Lev Serebryakov wrote:

> Hello, Ian.
> You wrote 21 августа 2012 г., 19:16:03:
>
> IL> It has worked this way for me for years.  Does it somehow not work this
> IL> way for everyone?
>    Please, read comment to r239356. Starting from this revision
>  dhclient exists on interface down and _remiove_ IP address from
>  interface. Removal of address from interface will drop all open
>  connections, which uses this address.
>

Aha!  That's where the confusion is happening -- I didn't read the
comment, I read the code.

I don't know what "teardown the configured lease" in that comment means,
but it doesn't mean that the interface loses its current configuration,
or that any existing connections are perturbed.  

If the cable is plugged back into the same network, the interface will
get the same address it last had and existing connections continue to
work, unless the dhcp server recycled that lease to another client while
the cable was unplugged (highly unlikely unless the server/network is
starved for addresses, since the dhcpd design is to avoid recycling
recently-used addresses).

The important point is that if you unplug the cable then plug it into a
different network, now the right thing will happen -- you will acquire
an address on the new network.  That's the reason that this change is an
important bugfix for a long standing (many many years) bug in freebsd's
dhclient.

-- Ian


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[satan]

Garrett Cooper wrote:
GC> On Tue, Aug 21, 2012 at 2:55 AM, Vitalij Satanivskij <[hidden email]> wrote:
GC> > Hi all,
GC> >
GC> > After last update my home machine begin doin some strange things -
GC>
GC> ...
GC>
GC> Try reverting r239356 -- if that works, then please let jhb@ know.
GC> -Garrett

Yes i'm revert it and everything is ok.

Look's like dhclient do down/up sequence -

Aug 21 19:21:00 home kernel: fxp0: link state changed to UP
Aug 21 19:21:01 home kernel: fxp0: link state changed to DOWN
Aug 21 19:21:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 21 19:21:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 21 19:21:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.xx
Aug 21 19:21:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 21 19:21:03 home kernel: fxp0: link state changed to UP

and in r239356 when iface down dhclient exiting then iface become up, dhclient staring, get adress, bring iface down (why?) and exit.

Before r239356 iface just doing down/up without dhclient exit and everything work fine.





_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, Ian.
You wrote 21 августа 2012 г., 19:55:07:

IL> I don't know what "teardown the configured lease" in that comment means,
IL> but it doesn't mean that the interface loses its current configuration,
IL> or that any existing connections are perturbed.
  Sorry, but comment in PR:

  http://www.freebsd.org/cgi/query-pr.cgi?pr=166656

  says:

===================================
>dhclient on exit should also remove the IP address it has set.
Yes, and the patch in the existing PR _should_ do that - it invokes
the failure handler in the same way as the other dhclient failure
modes.
===================================

 I don't understand what exactly "should" means here -- it should, but
it doesn't or it should and it does?

 But in any case, it looks like here is intention to remove IP address, and if it
doesn't done so, it will be ``fixed'' in future -- no
contradictions/objections to this ``desired behavior'' is seen in this
PR.

IL> The important point is that if you unplug the cable then plug it into a
IL> different network, now the right thing will happen -- you will acquire
IL> an address on the new network.  That's the reason that this change is an
IL> important bugfix for a long standing (many many years) bug in freebsd's
IL> dhclient.
  No, I'll be without dhclient at all, if I don't use devd :(. And
 absence of devd is completely legal, and should be supported. It is
 perfectly valid and sensible setup for small devices (think:
 MIPS-based routers, which are started to be supported now), where devd
 could be very costly in both terms of flash size (it is C++
 application and need C++ runtime!) and memory (only devd event on
 such devices are this cable plugging/unplugging -- so using devd
 doesn't add any value for such setups).

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[olli hauer]

On 2012-08-21 13:45, Lev Serebryakov wrote:

> Hello, Lev.
> You wrote 21 августа 2012 г., 15:40:35:
>
> GC>> Try reverting r239356 -- if that works, then please let jhb@ know.
> LS>   I'm confused by  this commit, because it seems (from comment alone),
> LS> that  dhclient  will not work without devd anymore (with "synchronous
> LS> dhcp" option in rc.conf).
> LS>   Am I right?
>  Also,  I  don't  like idea of removing IP address from interface when
> cable is unplugged. It was very disturbing behavior of Windows
> machines for years. I've unplug cable to change switch port for only a
> second and all connections are broken, even if one second later
> dhcpclient receive SAME lease! I don't like this. FreeBSD was very
> tolerant to unplugging cable for eons, and I (and not only me) like
> it. If I understand this change properly, it is no more the case :(
>

Oh, this is certainly exciting for clients in the backbone when a switch
will be reloaded because of firmware upgrade.

This behavior was a reason for me to run MS machines only virtual instead
using fix IP addresses (using ip arp inspection and dhcp snooping on the
whole network so fix IPs are a no-go)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Ian Lepore]

On Tue, 2012-08-21 at 21:01 +0400, Lev Serebryakov wrote:

> IL> The important point is that if you unplug the cable then plug it into a
> IL> different network, now the right thing will happen -- you will acquire
> IL> an address on the new network.  That's the reason that this change is an
> IL> important bugfix for a long standing (many many years) bug in freebsd's
> IL> dhclient.
>   No, I'll be without dhclient at all, if I don't use devd :(. And
>  absence of devd is completely legal, and should be supported. It is
>  perfectly valid and sensible setup for small devices (think:
>  MIPS-based routers, which are started to be supported now), where devd
>  could be very costly in both terms of flash size (it is C++
>  application and need C++ runtime!) and memory (only devd event on
>  such devices are this cable plugging/unplugging -- so using devd
>  doesn't add any value for such setups).
>

I think it's funny how people have this knee-jerk reaction against C++
apps.  The devd executable is not exactly an example of bloatware: 374k
statically linked (so it already includes this "C++ runtime" that you
think is large).    We routinely deploy embedded systems that use apps
written exclusively in C++, on systems that only have 32 or 64mb of ram.
We've been doing so since the days when the biggest compact flash card
you could buy was 64mb.

Perhaps the right solution is to add a dhclient command line option to
operate in the historical buggy mode: it doesn't exit on link status
changes, and fails to work properly if those link status changes are
happening because the physical connection has moved to another network.

If so, I think the default should be to work correctly, and folks
depending on the historical buggy behavior will have to add a parm to
rc.conf.

-- Ian


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, Ian.
You wrote 21 августа 2012 г., 21:36:30:

IL> Perhaps the right solution is to add a dhclient command line option to
IL> operate in the historical buggy mode: it doesn't exit on link status
IL> changes, and fails to work properly if those link status changes are
IL> happening because the physical connection has moved to another network.
  Right  solution was spoken by jhb@ already: dhclient should
 re-request lease on interface down/up cycle. There is no need to exit
 and be started again in any case. It will work ``as expected''
 without any options for everybody.

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, Ian.
You wrote 21 августа 2012 г., 21:36:30:

IL> I think it's funny how people have this knee-jerk reaction against C++
IL> apps.  The devd executable is not exactly an example of bloatware: 374k
IL> statically linked (so it already includes this "C++ runtime" that you
IL> think is large).    We routinely deploy embedded systems that use apps
IL> written exclusively in C++, on systems that only have 32 or 64mb of ram.
IL> We've been doing so since the days when the biggest compact flash card
IL> you could buy was 64mb.
  BTW, typical  MIPS  SoC-based  router has only 16MiB of flash. And,
 yes, FreeBSD doesn't fit well in this size now, but why add another
 mandatory program, only role of which is to monitor network cable and
 re-run the same program every time?

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Slawa Olhovchenkov]

On Tue, Aug 21, 2012 at 09:40:27PM +0400, Lev Serebryakov wrote:

> Hello, Ian.
> You wrote 21 августа 2012 г., 21:36:30:
>
> IL> Perhaps the right solution is to add a dhclient command line option to
> IL> operate in the historical buggy mode: it doesn't exit on link status
> IL> changes, and fails to work properly if those link status changes are
> IL> happening because the physical connection has moved to another network.
>   Right  solution was spoken by jhb@ already: dhclient should
>  re-request lease on interface down/up cycle. There is no need to exit
>  and be started again in any case. It will work ``as expected''
>  without any options for everybody.

Not re-request lease, simple renew.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[dougb]

On 8/21/2012 6:34 AM, John Baldwin wrote:

> Humm.  devd is the more common case, and we explicitly don't use devd to start
> dhclient on boot even when devd is enabled (so out of the box dhcp would first
> be started by rc, but would be restarted by devd).

That sounds reasonable. People who choose not to run devd can be
responsible for restarting dhclient themselves.

> Another option is to rework dhclient to work like it does on OpenBSD where it
> renews its lease if the link bounces, but to not exit when the link goes down.

That would be preferable.

> That case would fix the currently broken case that you unplug your cable, take
> your laptop over to another network (e.g. take it home if suspend/resume
> works), then plug it back in and are still stuck with your old IP.

I do think it's important to fix this case. However I agree with the
chorus of responders that it is more important to maintain our historic
resilience to temporary loss of connectivity.

Doug

--

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
                        -- Edward Everett Hale, (1822 - 1909)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Lev Serebryakov]

Hello, Slawa.
You wrote 21 августа 2012 г., 21:47:46:

SO> Not re-request lease, simple renew.
  Sorry, I'm not very strong in exact terms here.

--
// Black Lion AKA Lev Serebryakov <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"