Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 20/08/2012 21:43, Baptiste Daroussin wrote: Hi all, Since 1.0-rc6 release, everything looks ready for a final release of 1.0, I'll give more details on the release commit bit :) this is planned for 30th august 2012. Congratulations, it's great! :) signature.asc Description: OpenPGP digital signature
Re: BUFSIZ = 1024, still ?
on 21/08/2012 04:59 Scott Long said the following: This gets brought up from time to time, and I honestly thought that I swept most of the problems up a few years ago. The mistake that I made in the mlx driver that was recently corrected was evidence of a previous sweep. If anyone wants to do another sweep, the thing to grep for is any drivers that use MAXPHYS to size their i/o's. For the drivers that do that, you then have to see if they can actually handle an arbitrary number of scatter-gather elements. If they can't then they need to stop using MAXPHYS and start using a constant that applies to the driver. My quick scan shows the following would need to be investigated: sys/dev/ata (legacy ata) /sys/dev/isp /sys/dev/mmcsd /sys/dev/mvs The only other problem is that struct but contains an element sized on MAXPHYS for doing swapper I/O. Increasing MAXPHYS will increase this, and at one point I think that Alan Cox might have wanted to find a better way to hold swap info. Otherwise, increasing MAXPHYS causes no problems and is something that has run in production for quite some time at places like Yahoo and Netflix. I would like to use this opportunity to remind about another abuse in drivers: MAXBSIZE. This constant should be private to buffer cache / FS drivers layer, but some drivers abuse it for things related to physical I/O (mostly [only?] as bus_dma_tag_create parameter). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
dhclient cause up/down cycle after 239356 ?
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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On Tue, Aug 21, 2012 at 2:55 AM, Vitalij Satanivskij sa...@ukr.net 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477 recompiling the VBox kernel module: === Cleaning for virtualbox-ose-kmod-4.1.18_1 === virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2. *** [all] Error code 1 Stop in /usr/ports/emulators/virtualbox-ose-kmod. The port compiled prior to the updates of today. oh signature.asc Description: OpenPGP digital signature
Re: [HEADSUP] geli(4) weak master key generation on -CURRENT
On Mon, 2012-08-20 at 22:24:56 +0100, Simon L. B. Nielsen wrote: Hello, If you are not using geli(4) on -CURRENT (AKA FreeBSD 10) you can safely ignore this mail. If you are, please read on! -CURRENT users of geli(4) should be advised that, a geli(4) device may have weak master key, if the provider is created on -CURRENT system built against source code between r238116 (Jul 4 17:54:17 2012 UTC) and r239184 (non-inclusive, Aug 10 18:43:29 2012 UTC). One can verify if its provider was created with weak keys by running: # geli dump provider | grep version If the version is 7 and the system did not include this fix (r239184) when provider was initialized, then the data has to be backed up, underlying provider overwritten with random data, system upgraded and provider recreated. Thanks to Fabian Keil for reporting the issue, Pawel Jakub Dawidek for fixing it, and Xin Li for drafting this text. PS. This only affects FreeBSD 10 / -CURRENT, and as -CURRENT isn't supported by the FreeBSD Security Team, we are not releasing an advisory, just this heads up. I haven't read commit mails in a very long time, but is there code in place that will issue a warning upon geli attach if version 7 is detected? While -CURRENT is not supported, there might be a lot of disks initialized with version 7 and they'll eventually be upgraded to 10.0-RELEASE (the OS, not necessarily the geli volumes). Thanks Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
Hi Baptise, On Mon, Aug 20, 2012 at 09:43:13PM +0200, Baptiste Daroussin wrote: Since 1.0-rc6 release, everything looks ready for a final release of 1.0, I'll give more details on the release commit bit :) this is planned for 30th august 2012. Current was supposed to switch to pkgng by default today, it has been delayed until the nvidia-driver is fixed with pkgng. Thanksfully kwm@ and danfe@ has been working on this, and the situation should be fixed pretty soon. Please continue testing pkgng and reporting bugs, if you are new comers do not hesitate to ask question about pkgng so that we can improve documentation: The usual links about pkgng: - http://wiki.freebsd.org/pkgng - http://wiki.freebsd.org/PkgPrimer - https://github.com/pkgng/pkgng/blob/master/FAQ.md - http://people.freebsd.org/~bapt/pres-pkgng-bsdcan.pdf - http://www.youtube.com/watch?v=4Hxq7AHZ27I First thank you and all who have worked to make this first release of pkgng. This is a great milestone in FreeBSD history. Supposedly, pkgng will stay opt-in for RELENG_9 and will be the default (opt-out?) on RELENG_10. During the upgrade from the old branch to the new one, how do we ensure users will perform the required step (basically, run pkg2ng) to switch their pkg database to pkgng? Will it be a note in src/UPDATING and as well in the release notes? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildworld c++ internal error
On Mon, August 20, 2012 17:54, Randy Bush wrote: -O allowed it to buildworld! Should be marginally faster compiling too .. good to hear :-) imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 03:26:43PM +0200, Jeremie Le Hen wrote: Hi Baptise, On Mon, Aug 20, 2012 at 09:43:13PM +0200, Baptiste Daroussin wrote: Since 1.0-rc6 release, everything looks ready for a final release of 1.0, I'll give more details on the release commit bit :) this is planned for 30th august 2012. Current was supposed to switch to pkgng by default today, it has been delayed until the nvidia-driver is fixed with pkgng. Thanksfully kwm@ and danfe@ has been working on this, and the situation should be fixed pretty soon. Please continue testing pkgng and reporting bugs, if you are new comers do not hesitate to ask question about pkgng so that we can improve documentation: The usual links about pkgng: - http://wiki.freebsd.org/pkgng - http://wiki.freebsd.org/PkgPrimer - https://github.com/pkgng/pkgng/blob/master/FAQ.md - http://people.freebsd.org/~bapt/pres-pkgng-bsdcan.pdf - http://www.youtube.com/watch?v=4Hxq7AHZ27I First thank you and all who have worked to make this first release of pkgng. This is a great milestone in FreeBSD history. Supposedly, pkgng will stay opt-in for RELENG_9 and will be the default (opt-out?) on RELENG_10. During the upgrade from the old branch to the new one, how do we ensure users will perform the required step (basically, run pkg2ng) to switch their pkg database to pkgng? Will it be a note in src/UPDATING and as well in the release notes? Yes there will be a note in UPDATING, I'm also pondering modifying pkg_* tools to that they show up an advetisement about pkg_install being deprecated. I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. regards, Bapt pgpPgG1EFaQcA.pgp Description: PGP signature
Re: buildworld c++ internal error
On 2012-08-19 16:01, Randy Bush wrote:
...
c++ -O2 -pipe -DIPFIREWALL_NAT -march=pentium
-I/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore -I.
-I/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX
-DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd9.0\ -DDEFAULT_SYSROOT=\\
-fstack-protector -fno-exceptions -c
/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore/Function.cpp -o Function.o
{standard input}: Assembler messages:
{standard input}:36465: Warning: end of file not at end of a line; newline
inserted
{standard input}:36631: Error: unknown pseudo-op: `.lc798'
c++: Internal error: Killed: 9 (program cc1plus)
If you don't need clang on this box, you could add WITHOUT_CLANG to your
src.conf. If you do need clang, you could try building world with it,
since it usually is faster than gcc, and uses less memory. :)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
Garrett Cooper wrote: GC On Tue, Aug 21, 2012 at 2:55 AM, Vitalij Satanivskij sa...@ukr.net 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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? Until pkg becomes mandatory (which can't happen for several years) the pkg_* tools can't be removed altogether. What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. 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) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
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 l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 11:17:36AM -0700, Doug Barton wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? Until pkg becomes mandatory (which can't happen for several years) the pkg_* tools can't be removed altogether. What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. 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) that is what I meant of course, sorry if I badly said it at first Bapt pgpZV3bmiplJB.pgp Description: PGP signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 11:17 AM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? ... What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It already exists -- it's just out of date / crufty: $ make describe pkg_install-20090902|/usr/ports/ports-mgmt/pkg_install|/usr/local|FreeBSD -STABLE version of the package tools|/usr/ports/ports-mgmt/pkg_install/pkg-descr|port...@freebsd.org|ports-mgmt||http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/pkg_install/ It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Agreed. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 11:47 AM, Garrett Cooper wrote: On Tue, Aug 21, 2012 at 11:17 AM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? ... What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It already exists -- it's just out of date / crufty: Right ... I was using move as shorthand for several different ideas, including but not limited to the latest version of the code itself, robust support for the code going forward, the primary supported way of using pkg_*, etc. All of these ideas have been discussed in the past, so I was hoping to avoid having to re-discuss them. :) It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Agreed. Great (and I saw Baptiste's response on this as well). Glad to hear that we're on the same page about something at least. :) -- 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) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 11:47:36AM -0700, Garrett Cooper wrote: On Tue, Aug 21, 2012 at 11:17 AM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? ... What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It already exists -- it's just out of date / crufty: $ make describe pkg_install-20090902|/usr/ports/ports-mgmt/pkg_install|/usr/local|FreeBSD -STABLE version of the package tools|/usr/ports/ports-mgmt/pkg_install/pkg-descr|port...@freebsd.org|ports-mgmt||http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/pkg_install/ It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Agreed. Thanks, -Garrett Let's rephrase the plan: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE 2/ switch 9.2 (the ports tree) to pkgng (but keep pkg_* tools maybe drop them, but that is to be discussed to avoid POLA 3/ do the same for 8 once all of our supported release are fully pkgng aware and all the pkg_* release are EOLed, drop support for pkg_* tools from the ports tree. regards, Bapt pgpereAUAmDEE.pgp Description: PGP signature
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 10:18:15PM +0400, Lev Serebryakov wrote: SO Not re-request lease, simple renew. Sorry, I'm not very strong in exact terms here. dhcp client can sent different requests: DHCPDISCOVER from 0.0.0.0 to 255.255.255.255 DHCPREQUEST from 0.0.0.0 to SERVER_IP (from DHCPOFFER) or DHCPRELEASE DHCPDISCOVER from 0.0.0.0 to 255.255.255.255 DHCPREQUEST from 0.0.0.0 to SERVER_IP or DHCPREQUEST from 0.0.0.0 to 255.255.255.255 or DHCPREQUEST from IP to SERVER_IP and DHCPINFORM for quering additional parametrs after boot, w/o change IP (for example IE request information about proxy auto config) renew address at lease_time/2 usually DHCPREQUEST from IP to SERVER_IP. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. 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) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. regards, Bapt pgpWdDom1E1Zv.pgp Description: PGP signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. -- 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) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Aug 21, 2012, at 6:46 AM, Slawa Olhovchenkov wrote: 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). mosh helps. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Aug 21, 2012, at 11:36 AM, Ian Lepore wrote: 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. C++ isn't the problem. Devd's size wouldn't be any smaller if I'd written it in pure C. People have sent me patches that move it to pure C over time. Yet, when written in C, the binaries are the same size (well, within 10k), and the run-time speed and memory consumption are comparable. Devd was written with the small, embedded system in mind, and was always considered to be on the path to being mandatory (you are free to write your own devd-like program, if you like btw). Haven't looked at the dhclient issues surrounding this tread, but C++ size and bloat of devd is an argument not supported by the objective facts. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Aug 21, 2012, at 11:42 AM, Lev Serebryakov wrote: 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? You'd typically not run dhclient in daemon mode in a SoC, since you don't want to chew up the memory all the time, and you'd likely replace the system dhclient with one that's simpler... But the network notification part of devd would be trivial to reproduce if you wanted in a specialized daemon that would do what's required. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Aug 21, 2012, at 1:51 PM, Doug Barton wrote: On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. If you are fine with removing them if there's robust support, how can you also be suggesting that it is impossible and shouldn't be talked about? Personally, I think we should handle this the same way that other replacement tools have been done, which is close to what Baptiste has proposed. If the new tools are totally awesome, we have replaced old tools. If the new tools are good, but don't cover the older users, we develop along size. If they are lame, but somehow get committed anyway, we take 18 years to replace them with bsdinstall. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 1:08 PM, Warner Losh wrote: On Aug 21, 2012, at 1:51 PM, Doug Barton wrote: On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. If you are fine with removing them if there's robust support, how can you also be suggesting that it is impossible and shouldn't be talked about? Those address different parts of the problem. Making pkg mandatory in 10 is different from where the old pkg_* tools end up. The command line tools are just the tip of the iceberg, there are a lot of interactions behind the scenes. Personally, I think we should handle this the same way that other replacement tools have been done, which is close to what Baptiste has proposed. If the new tools are totally awesome, we have replaced old tools. I don't think we have ever done a complete replacement of major infrastructure in one release. The traditional model has been to deprecate in one release, remove in the next. And in this case, it doesn't matter how awesome the new tools are, they are a MAJOR paradigm shift for how users interact with ports, and we are going to have a lot of users who take years to transition their installed base. No matter how much we may want to move fast on this, it just isn't going to be possible. If the new tools are good, but don't cover the older users, we develop along size. Yes, this is precisely what I'm saying. Sorry if I wasn't clear. -- 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) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
Hello, Warner. You wrote 22 августа 2012 г., 0:02:18: WL Haven't looked at the dhclient issues surrounding this tread, but WL C++ size and bloat of devd is an argument not supported by the objective facts. Ok, lets leave C++ alone, but intended address removal (See PR comments) is POLA violation and, IMHO, serious issue by itself, even without POLA. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
Hello, Warner. You wrote 22 августа 2012 г., 0:04:41: 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? WL You'd typically not run dhclient in daemon mode in a SoC, since WL you don't want to chew up the memory all the time, and you'd WL likely replace the system dhclient with one that's simpler... But My ISP wants lease renewal every 10800 second (3 hours). Do I need to add cron task if I don't want to run dhclient as a daemon on router? WL the network notification part of devd would be trivial to WL reproduce if you wanted in a specialized daemon that would do what's required. IMHO, OpenBSD way, when dhclient renew lease after down/up cycle by itself, is much better. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
Hello, Warner. You wrote 21 августа 2012 г., 23:56:11: WL mosh helps. And what helps in case of on-line backup? Not every network protocol and protocol implementation, unfortunately, supports automatic resume :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tuesday, August 21, 2012 9:34:31 am John Baldwin wrote:
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.
Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient.
I tested that it survives the following:
- Unplugging/replugging does not kill an existing ssh session
- Using ifconfig down/up does not kill an existing ssh session
- Plugging into a different network does cause dhclient to negotiate
a new lease on the new network
I've removed the bits to clear the old configuration if dhclient exits due to
'ifconfig down', and dhclient no longer exits on link down, but instead tracks
the link state and enters the 'reboot' state when the link goes up.
Index: dhcpd.h
===
--- dhcpd.h (revision 239498)
+++ dhcpd.h (working copy)
@@ -208,6 +208,7 @@
int errors;
int dead;
u_int16_tindex;
+ int linkstat;
};
struct timeout {
Index: dhclient.c
===
--- dhclient.c (revision 239498)
+++ dhclient.c (working copy)
@@ -218,6 +218,7 @@
struct sockaddr *sa;
struct iaddr a;
ssize_t n;
+ int linkstat;
n = read(routefd, msg, sizeof(msg));
rtm = (struct rt_msghdr *)msg;
@@ -278,10 +279,14 @@
ifi-name);
goto die;
}
- if (!interface_link_status(ifi-name)) {
- warning(Interface %s is down, dhclient exiting,
- ifi-name);
- goto die;
+ linkstat = interface_link_status(ifi-name);
+ if (linkstat != ifi-linkstat) {
+ debug(%s link state %s - %s, ifi-name,
+ ifi-linkstat ? up : down,
+ linkstat ? up : down);
+ ifi-linkstat = linkstat;
+ if (linkstat)
+ state_reboot(ifi);
}
break;
case RTM_IFANNOUNCE:
@@ -321,8 +326,6 @@
die:
script_init(FAIL, NULL);
- if (ifi-client-active)
- script_write_params(old_, ifi-client-active);
if (ifi-client-alias)
script_write_params(alias_, ifi-client-alias);
script_go();
@@ -437,6 +440,7 @@
}
fprintf(stderr, got link\n);
}
+ ifi-linkstat = 1;
if ((nullfd = open(_PATH_DEVNULL, O_RDWR, 0)) == -1)
error(cannot open %s: %m, _PATH_DEVNULL);
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
On 20.08.12 10:32, Doug Barton wrote: On 08/15/2012 03:18, Alexander Motin wrote: It is quite pointless to speculate without real info like mentioned above KTR_SCHED traces. I'm sorry, you're quite wrong about that. In the cases I mentioned, and in about 2 out of 3 of the cases where users reported problems and I suggested that they try 4BSD, the results were clear. This obviously points out that there is a serious problem with ULE, and if I were the one who was responsible for that code I would be looking at ways of helping users figure out where the problems are. But that's just me. Main thing I've learned about schedulers, things there never work as you expect. There are two many factors are relations to predict behavior in every case. In the web hosting case that I mentioned, I purposely kept every other factor consistent; and changed only s/ULE/4BSD/. The results were both clear and consistent. Can you please prove that with some actual numbers? I seem to recall you posted something not too long ago but i was unable to find that right now. Also can you tell us what you ran and how. I would really like to reproduce this. Thanks, Florian signature.asc Description: OpenPGP digital signature
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, 2012-08-21 at 14:04 -0600, Warner Losh wrote:
On Aug 21, 2012, at 11:42 AM, Lev Serebryakov wrote:
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?
You'd typically not run dhclient in daemon mode in a SoC, since you don't
want to chew up the memory all the time, and you'd likely replace the system
dhclient with one that's simpler... But the network notification part of
devd would be trivial to reproduce if you wanted in a specialized daemon that
would do what's required.
Warner
For example, this script can replace devd as a daemon that restarts
dhclient when any link comes back up...
#!/bin/sh
daemon_loop () {
while true; do
read line
if [ -z ${line##!system=IFNET subsystem=* type=LINK_UP} ] ; then
eval ${line##!}
/sbin/dhclient $subsystem
fi
done
}
cat /dev/devctl | daemon_loop
Of course the right thing to do is invoke the proper rc scripts rather
than dhclient directly... this is just to illustrate how easy it is to
replace devd if your needs are specialized.
-- Ian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 1:15 PM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 1:08 PM, Warner Losh wrote: On Aug 21, 2012, at 1:51 PM, Doug Barton wrote: On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. If you are fine with removing them if there's robust support, how can you also be suggesting that it is impossible and shouldn't be talked about? Those address different parts of the problem. Making pkg mandatory in 10 is different from where the old pkg_* tools end up. The command line tools are just the tip of the iceberg, there are a lot of interactions behind the scenes. Personally, I think we should handle this the same way that other replacement tools have been done, which is close to what Baptiste has proposed. If the new tools are totally awesome, we have replaced old tools. I don't think we have ever done a complete replacement of major infrastructure in one release. The traditional model has been to deprecate in one release, remove in the next. And in this case, it doesn't matter how awesome the new tools are, they are a MAJOR paradigm shift for how users interact with ports, and we are going to have a lot of users who take years to transition their installed base. No matter how much we may want to move fast on this, it just isn't going to be possible. What Doug mentioned (and I don't think was really considered, but is valid) would break people that use pkg_* outside of ports. I know of at least two instances where this would be the case (one case that uses pkg_* directly, and another case that uses libpkg from pkg_* 0-o...). I know it's delaying the inevitable (pkg_* is going to go away), but we shouldn't count our chickens before they've hatched as far as how pkgng needs to be used and how things might change. The optional in 8/9/10, mandatory in 11 proposal seems very sane and it allows people to get things worked out properly without too many headaches. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 01:56:11PM -0600, Warner Losh wrote: On Aug 21, 2012, at 6:46 AM, Slawa Olhovchenkov wrote: 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). mosh helps. No. Not all remote host allow to install mosh. Cisco routers, for example, don't allow to install mosh. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij sa...@ukr.net wrote: Look's like dhclient do down/up sequence - Not intentionally. 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 I can reproduce this behaviour - but only on fxp (i82559 in my case) NICs. My bge (BCM5750) and rl (RTL8139) NICs do not report the spurious DOWN/UP. (I don't normally run DHCP on any fxp interfaces, so I didn't see it during my testing). The problem appears to be the $IFCONFIG $interface inet alias 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up executed by /sbin/dhclient-script during PREINIT. This is making the fxp NIC reset the link (actually, assigning _any_ IP address to an fxp NIC causes it to reset the link). The post r239356 dhclient detects the link going down and exits. Before r239356 iface just doing down/up without dhclient exit and everything work fine. For you, anyway. Failing to detect link down causes problems for me because my dhclient was not seeing my cable-modem resets and therefore failing to reacquire a DHCP lease. -- Peter Jeremy pgptb9EOcZ9Yg.pgp Description: PGP signature
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
Hello, Ian. You wrote 22 августа 2012 г., 1:38:04: IL For example, this script can replace devd as a daemon that restarts IL dhclient when any link comes back up... IL Of course the right thing to do is invoke the proper rc scripts rather IL than dhclient directly... this is just to illustrate how easy it is to IL replace devd if your needs are specialized. [sigh] Everything worked with 8.x without problems. It worked with 9.x and -CURRENT with adding of ``synchronous_dhclient=YES'' into /etc/rc.conf (And it cost me about 2 hours of investigation, why dhclient stops to start after upgrade). Next I'll need to write some script. Is it Ok to you? Yes, I understand problem with laptops, which change wire and wireless networks and need to re-acquire new address. But it should be soleved other way. And jhb@ already posted proper solution, BTW! And, as side note, ``man rc.cof'' says NOTHING about relation of devd and ``synchronous_dhclient'' setting! It says about ``start dhclient(8) synchronously at startup'' without explaining, that without this option and with devd disabled, dhclient WILL NOT START AT ALL! And relations between devd and dhclient are not documented at all in: rc.conf(5), dhclient(8), devd.conf(5) and devd(8). And rc.conf(5) explains `devd_enable' as: Run devd(8) to handle device added, removed or unknown events from the kernel. And doesn't say a word about network link state. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
Hello, John. You wrote 22 августа 2012 г., 1:25:23: JB Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient. JB I tested that it survives the following: JB - Unplugging/replugging does not kill an existing ssh session JB - Using ifconfig down/up does not kill an existing ssh session JB - Plugging into a different network does cause dhclient to negotiate JB a new lease on the new network THANK YOU! -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Wed, Aug 22, 2012 at 02:36:23AM +0400, Lev Serebryakov wrote: Hello, Ian. You wrote 22 августа 2012 г., 1:38:04: IL For example, this script can replace devd as a daemon that restarts IL dhclient when any link comes back up... IL Of course the right thing to do is invoke the proper rc scripts rather IL than dhclient directly... this is just to illustrate how easy it is to IL replace devd if your needs are specialized. [sigh] Everything worked with 8.x without problems. It worked with 9.x and -CURRENT with adding of ``synchronous_dhclient=YES'' into /etc/rc.conf (And it cost me about 2 hours of investigation, why dhclient stops to start after upgrade). Next I'll need to write some script. Is it Ok to you? Yes, I understand problem with laptops, which change wire and wireless networks and need to re-acquire new address. But it should be soleved other way. And jhb@ already posted proper solution, BTW! And, as side note, ``man rc.cof'' says NOTHING about relation of devd and ``synchronous_dhclient'' setting! It says about ``start dhclient(8) synchronously at startup'' without explaining, that without this option and with devd disabled, dhclient WILL NOT START AT ALL! And relations between devd and dhclient are not documented at all in: rc.conf(5), dhclient(8), devd.conf(5) and devd(8). Time ago synchronous_dhclient is waiting for obtain IP by dhcpclient. w/o synchronous_dhclient and ifconfig_bge0=DHCP dhcpclient run in background and don't paused boot while obtaining IP address. On perinterface basis: ifconfig_bge0=SYNCDHCP or ifconfig_bge0=NOSYNCDHCP Background start of dhcpclient currently by devd, on UP event on ethernet interface. This introduction in 6.2. 2006-08-22. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On 2012-Aug-21 17:25:23 -0400, John Baldwin j...@freebsd.org wrote: Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient. I tested that it survives the following: I've also done some limited testing on both bge and fxp NICs and haven't run into any problems. In particular the spurious link resets from fxp don't seem to cause any problems. -- Peter Jeremy pgp5gbqPFkDoz.pgp Description: PGP signature
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 05:25:23PM -0400, John Baldwin wrote:
On Tuesday, August 21, 2012 9:34:31 am John Baldwin wrote:
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.
Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient.
I tested that it survives the following:
- Unplugging/replugging does not kill an existing ssh session
- Using ifconfig down/up does not kill an existing ssh session
- Plugging into a different network does cause dhclient to negotiate
a new lease on the new network
Assign address on interface manualy cause exiting dhcpclient?
I've removed the bits to clear the old configuration if dhclient exits due to
'ifconfig down', and dhclient no longer exits on link down, but instead tracks
the link state and enters the 'reboot' state when the link goes up.
Index: dhcpd.h
===
--- dhcpd.h (revision 239498)
+++ dhcpd.h (working copy)
@@ -208,6 +208,7 @@
int errors;
int dead;
u_int16_tindex;
+ int linkstat;
};
struct timeout {
Index: dhclient.c
===
--- dhclient.c(revision 239498)
+++ dhclient.c(working copy)
@@ -218,6 +218,7 @@
struct sockaddr *sa;
struct iaddr a;
ssize_t n;
+ int linkstat;
n = read(routefd, msg, sizeof(msg));
rtm = (struct rt_msghdr *)msg;
@@ -278,10 +279,14 @@
ifi-name);
goto die;
}
- if (!interface_link_status(ifi-name)) {
- warning(Interface %s is down, dhclient exiting,
- ifi-name);
- goto die;
+ linkstat = interface_link_status(ifi-name);
+ if (linkstat != ifi-linkstat) {
+ debug(%s link state %s - %s, ifi-name,
+ ifi-linkstat ? up : down,
+ linkstat ? up : down);
+ ifi-linkstat = linkstat;
+ if (linkstat)
+ state_reboot(ifi);
}
break;
case RTM_IFANNOUNCE:
@@ -321,8 +326,6 @@
die:
script_init(FAIL, NULL);
- if (ifi-client-active)
- script_write_params(old_, ifi-client-active);
if (ifi-client-alias)
script_write_params(alias_, ifi-client-alias);
script_go();
@@ -437,6 +440,7 @@
}
fprintf(stderr, got link\n);
}
+ ifi-linkstat = 1;
if ((nullfd = open(_PATH_DEVNULL, O_RDWR, 0)) == -1)
error(cannot open %s: %m, _PATH_DEVNULL);
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On Wed, Aug 22, 2012 at 08:27:01AM +1000, Peter Jeremy wrote: On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij sa...@ukr.net wrote: Look's like dhclient do down/up sequence - Not intentionally. 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 I can reproduce this behaviour - but only on fxp (i82559 in my case) NICs. My bge (BCM5750) and rl (RTL8139) NICs do not report the spurious DOWN/UP. (I don't normally run DHCP on any fxp interfaces, so I didn't see it during my testing). The problem appears to be the $IFCONFIG $interface inet alias 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up executed by /sbin/dhclient-script during PREINIT. This is making the fxp NIC reset the link (actually, assigning _any_ IP address to an fxp NIC causes it to reset the link). The post r239356 dhclient detects This comes from the hardware limitation. Assigning addresses will result in programming multicast filter and fxp(4) controllers require full controller reset to reprogram the multicast filter. the link going down and exits. Before r239356 iface just doing down/up without dhclient exit and everything work fine. For you, anyway. Failing to detect link down causes problems for me because my dhclient was not seeing my cable-modem resets and therefore failing to reacquire a DHCP lease. -- Peter Jeremy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, 21 Aug 2012, Doug Barton wrote: I don't think we have ever done a complete replacement of major infrastructure in one release. You mean like sysinstall can be used as an installer on 9 that would do something meaningful with the current infrastructure we provide? -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Aug 21, 2012, at 4:15 PM, Slawa Olhovchenkov wrote: On Tue, Aug 21, 2012 at 01:56:11PM -0600, Warner Losh wrote: On Aug 21, 2012, at 6:46 AM, Slawa Olhovchenkov wrote: 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). mosh helps. No. Not all remote host allow to install mosh. Cisco routers, for example, don't allow to install mosh. Yes. Mosh helps. You can mosh to a different host, then do what you need to do to get to the cisco. Does mosh solve the problem in all cases, no. It just helps. Warner___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Aug 21, 2012, at 5:00 PM, Slawa Olhovchenkov wrote: On Wed, Aug 22, 2012 at 02:36:23AM +0400, Lev Serebryakov wrote: Hello, Ian. You wrote 22 августа 2012 г., 1:38:04: IL For example, this script can replace devd as a daemon that restarts IL dhclient when any link comes back up... IL Of course the right thing to do is invoke the proper rc scripts rather IL than dhclient directly... this is just to illustrate how easy it is to IL replace devd if your needs are specialized. [sigh] Everything worked with 8.x without problems. It worked with 9.x and -CURRENT with adding of ``synchronous_dhclient=YES'' into /etc/rc.conf (And it cost me about 2 hours of investigation, why dhclient stops to start after upgrade). Next I'll need to write some script. Is it Ok to you? Yes, I understand problem with laptops, which change wire and wireless networks and need to re-acquire new address. But it should be soleved other way. And jhb@ already posted proper solution, BTW! And, as side note, ``man rc.cof'' says NOTHING about relation of devd and ``synchronous_dhclient'' setting! It says about ``start dhclient(8) synchronously at startup'' without explaining, that without this option and with devd disabled, dhclient WILL NOT START AT ALL! And relations between devd and dhclient are not documented at all in: rc.conf(5), dhclient(8), devd.conf(5) and devd(8). Time ago synchronous_dhclient is waiting for obtain IP by dhcpclient. w/o synchronous_dhclient and ifconfig_bge0=DHCP dhcpclient run in background and don't paused boot while obtaining IP address. On perinterface basis: ifconfig_bge0=SYNCDHCP or ifconfig_bge0=NOSYNCDHCP Background start of dhcpclient currently by devd, on UP event on ethernet interface. This introduction in 6.2. 2006-08-22. This is why monkeying with default behavior and not documenting changes are both bad ideas. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
