On Wednesday, August 22, 2012 9:35:34 pm Peter Jeremy wrote:
On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote:
Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of
gross (and OpenBSD doesn't do this). For now this change basically ignores
link up
ok next round :)
dhclient updated to Revision 239564
with fxp :
Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:48 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:48 home
On Wednesday, August 22, 2012 1:28:22 pm Vitalij Satanivskij wrote:
ok next round :)
dhclient updated to Revision 239564
with fxp :
Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:48 home
:)
dhclient updated to Revision 239564
with fxp :
Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:48 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:48 home dhclient: New
On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote:
Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of
gross (and OpenBSD doesn't do this). For now this change basically ignores
link up events if they occur with 5 seconds of the link down event. The 5 is
sequence it must perform? Wouldn't it be better to fix the broken
driver(s) to behave better than to add a twisty maze of hacks to dhclient?
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
On Thu, Aug 23, 2012 at 11:35:34AM +1000, Peter Jeremy wrote:
On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote:
Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of
gross (and OpenBSD doesn't do this). For now this change basically ignores
link up
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
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
___
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
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
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
Hello!
After updating to FreeBSD 10.0-CURRENT #0 r230054, I can't do anymore
dhclient on em0.
[root@freebsd ~]# uname -a
FreeBSD freebsd 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230054: Fri Jan
13 14:29:36 EET 2012 root@freebsd:/usr/obj/usr/head/sys/GENERIC
i386
[root@freebsd ~]# cat /var/log
On Tue, Jan 17, 2012 at 01:57:48PM +0200, Octavian Rinciog wrote:
O Hello!
O
O After updating to FreeBSD 10.0-CURRENT #0 r230054, I can't do anymore
O dhclient on em0.
O
O [root@freebsd ~]# uname -a
O FreeBSD freebsd 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230054: Fri Jan
O 13 14:29:36 EET 2012
On 01/17/2012 03:57, Octavian Rinciog wrote:
Jan 13 14:41:58 freebsd dhclient[1734]: em0: not found
You need to update your world and kernel together. The ability to run
new kernel on an old world (as is the usual upgrade method) was broken a
little while ago, and the compatibility shims to fix
On Tue, Jan 17, 2012 at 01:57:48PM +0200, Octavian Rinciog wrote:
Hello!
After updating to FreeBSD 10.0-CURRENT #0 r230054, I can't do anymore
dhclient on em0.
[root@freebsd ~]# uname -a
FreeBSD freebsd 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230054: Fri Jan
13 14:29:36 EET 2012 root
will
D come up?
Yes, older infconfig will work in head r228571 || head r228768.
I just tried with r228122 and got the same result. dhclient errors out
with can't find em0 although 'ifconfig em0' does produce results.
Which is due to getifaddrs() most likely; please go back and read up
the ifconfig changes that when I reboot my network will
D come up?
Yes, older infconfig will work in head r228571 || head r228768.
I just tried with r228122 and got the same result. dhclient errors out
with can't find em0 although 'ifconfig em0' does produce results.
Which is due to getifaddrs
On 12/21/2011 23:20, Gleb Smirnoff wrote:
I'm afraid, if we would try to document every kernel-userland API/ABI
change in head/ in the UPDATING, then the file will grow extremely quickly,
and still many issues will be forgotten to be added there.
That doesn't mean we shouldn't do our best to
in head r228571 || head r228768.
I just tried with r228122 and got the same result. dhclient errors out
with can't find em0 although 'ifconfig em0' does produce results.
I'm also not sure what you meant by head r228768 above, since we're
only up to r228824 in total so far. Maybe your time machine
D I just tried with r228122 and got the same result. dhclient errors out
D with can't find em0 although 'ifconfig em0' does produce results.
The dhclient issue you faced isn't related to my new CARP commit either
my SIOCAIFADDR work. I'm sorry that we flooded your email thread with
the discussion
will work in head r228571 || head r228768.
D
D I just tried with r228122 and got the same result. dhclient errors out
D with can't find em0 although 'ifconfig em0' does produce results.
The dhclient issue you faced isn't related to my new CARP commit either
my SIOCAIFADDR work. I'm sorry
need to
back r228571 out.
The in_control() and in6_control() are getting more and more hairy :(
I'd eager to remove the shim in the 11.x timeline.
Since subject mentions dhclient, I must notice that the dhclient-script
always relied on a bug in in_control(). The bug was fixed here:
http
and more hairy :(
I'd eager to remove the shim in the 11.x timeline.
Since subject mentions dhclient, I must notice that the dhclient-script
always relied on a bug in in_control(). The bug was fixed here:
http://svnweb.freebsd.org/base?view=revisionamp;revision=228313
Later the dhclient
dhclient, I must notice that the dhclient-script
always relied on a bug in in_control(). The bug was fixed here:
http://svnweb.freebsd.org/base?view=revisionamp;revision=228313
Later the dhclient-script was fixed:
http://svnweb.freebsd.org/base?view=revisionamp;revision=228463
Right, I saw those
On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote:
Considering r228571: we need to specify vhid as additional address
attribute in atomic manner, via one ioctl(). Address can't be first
configured, and then made redundant, that would lead it to being
static for a short period,
, but it sounds to me like you've addressed them. In any
D case, my original concern was limited to Do we need an UPDATING entry? :)
r228571 put an updating entry.
D Since subject mentions dhclient, I must notice that the dhclient-script
D always relied on a bug in in_control(). The bug was fixed
On 12/19/2011 05:24, Dimitry Andric wrote:
On 2011-12-19 10:17, Doug Barton wrote:
I updated to r228700 from 228122 and dhclient exits immediately saying
that em0 doesn't exist. However ifconfig seems to disagree:
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
1500
On 2011-12-20 09:38, Doug Barton wrote:
...
I tried replacing both ifconfig and dhclient with the versions that were
built along with the new kernel, and that didn't work.
Looking at the changes in r228571, it seems they also affect libc, so
installing that is probably also needed. Since all
On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote:
On 2011-12-20 09:38, Doug Barton wrote:
...
I tried replacing both ifconfig and dhclient with the versions that were
built along with the new kernel, and that didn't work.
Looking at the changes in r228571, it seems they also
On 20. Dec 2011, at 16:51 , Brooks Davis wrote:
On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote:
On 2011-12-20 09:38, Doug Barton wrote:
...
I tried replacing both ifconfig and dhclient with the versions that were
built along with the new kernel, and that didn't work
dhclient to not recognize any interfaces. I'm not 100% sure though...
D
D I tried replacing both ifconfig and dhclient with the versions that were
D built along with the new kernel, and that didn't work.
This shouldn't happen. If you did 'make buildworld buildkernel', then
your world in objdir would
Brooks,
On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote:
B We almost certainly need to back r228571 out. This is not an acceptable
B upgrade path that would be acceptable historically. Specially, we have
B effectively promised users that an X.Y world will work on an X+1.0
B
T An assumption that we are not allowed to change ABI for our own tools
T strongly discourages bringing in new features :(
P.S. Quoting documentation: The old world might not run correctly on the new
kernel, so you must install the new world immediately upon installing the new
kernel.
On Tue, Dec 20, 2011 at 06:48:40PM +, Bjoern A. Zeeb wrote:
On 20. Dec 2011, at 16:51 , Brooks Davis wrote:
On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote:
On 2011-12-20 09:38, Doug Barton wrote:
...
I tried replacing both ifconfig and dhclient with the versions
On Tue, Dec 20, 2011 at 01:30:34PM -0600, Brooks Davis wrote:
B I also worry about the problem that once you've installed world there is
B no easy way back.
When working on the patch for last months I did numerous 'make installkernel
installworld' switching between a patched sources and
On 20. Dec 2011, at 19:35 , Gleb Smirnoff wrote:
On Tue, Dec 20, 2011 at 01:30:34PM -0600, Brooks Davis wrote:
B I also worry about the problem that once you've installed world there is
B no easy way back.
When working on the patch for last months I did numerous 'make installkernel
is caused by the changes in r228571, which cause old ifconfig and
D dhclient to not recognize any interfaces. I'm not 100% sure though...
D
D I tried replacing both ifconfig and dhclient with the versions that were
D built along with the new kernel, and that didn't work.
This shouldn't happen
On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote:
Brooks,
On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote:
B We almost certainly need to back r228571 out. This is not an acceptable
B upgrade path that would be acceptable historically. Specially, we have
B
I updated to r228700 from 228122 and dhclient exits immediately saying
that em0 doesn't exist. However ifconfig seems to disagree:
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO
On 2011-12-19 10:17, Doug Barton wrote:
I updated to r228700 from 228122 and dhclient exits immediately saying
that em0 doesn't exist. However ifconfig seems to disagree:
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=4219bRXCSUM,TXCSUM,VLAN_MTU
On Dec 19, 2011, at 5:24 AM, Dimitry Andric d...@freebsd.org wrote:
On 2011-12-19 10:17, Doug Barton wrote:
I updated to r228700 from 228122 and dhclient exits immediately saying
that em0 doesn't exist. However ifconfig seems to disagree:
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX
On 2011-12-19 17:36, Garrett Cooper wrote:
On Dec 19, 2011, at 5:24 AM, Dimitry Andricd...@freebsd.org wrote:
On 2011-12-19 10:17, Doug Barton wrote:
I updated to r228700 from 228122 and dhclient exits immediately saying
that em0 doesn't exist. However ifconfig seems to disagree:
...
I saw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12.11.2011 21:01, Andrey V. Elsukov wrote:
I have several questions after a quick view of your patch: 1.
AFAIR, our dhclient was doing changes in the system configuration
via dhclient-script, but i don't see that your changes touched it.
Yes, I
opened about this:
http://www.freebsd.org/cgi/query-pr.cgi?pr=151940
With this patch applied and a DHCP server configured to publish this
option, dhclient(8) will add a line similar to the following one:
search example.org. foobar.com.
In the example, this indicates that the name www should
a PR opened about this:
http://www.freebsd.org/cgi/query-pr.cgi?pr=151940
With this patch applied and a DHCP server configured to publish this
option, dhclient(8) will add a line similar to the following one:
search example.org. foobar.com.
In the example, this indicates that the name www
On Wed, Sep 24, 2003 at 05:51:56AM -0700, David Wolfskill wrote:
From: Conrad J. Sabatier [EMAIL PROTECTED]
Subject: dhclient/ipfw conflict on boot
I just ran into this today after upgrading. It seems that dhclient is
unable to initialize properly at boot time, due to the prior
Date: Wed, 24 Sep 2003 00:58:12 -0500
From: Conrad J. Sabatier [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: dhclient/ipfw conflict on boot
I just ran into this today after upgrading. It seems that dhclient is
unable to initialize properly at boot time, due to the prior initialization
I just ran into this today after upgrading. It seems that dhclient is
unable to initialize properly at boot time, due to the prior initialization
of ipfw2 (default to deny policy). As all traffic is denied until my
firewall ruleset gets loaded (not until just after dhclient fails), it's
from man 8 dhclient:
The -1 flag cause dhclient to try once to get a lease. If it
fails, dhclient exits with exit code two.
with a missing dhcpserver or non-existent interface, this works.
however, it does not when i unplug the ethernet cable. in that case, i get
back true
Hi,
with a missing dhcpserver or non-existent interface, this works.
however, it does not when i unplug the ethernet cable. in that case, i get
back true after the timeout, not 2.
can someone verify this? is it a bug that must be fixed from the freebsd
side or should a bug report to the
Hi
I just noticed that dhclient takes 'ages' to write it's pidfile.
Shell-constructs similar to this
dhclient -q -1 -pf /etc/dhclient.pid fxp0
[ -e /etc/dhclient.pid ] kill -9 `cat /etc/dhclient.pid`
do not work because dhclient is too slow in writing its pid file.
is this the expected
Just an FYI:
I've noticed some bugginess in dhclient or route under 5.1-RELEASE.
It seems to be tied to route handling somehow.
For example, last night I shut down my wi0 interface and
brought up my fxp0 interface using dhclient. For some reason,
ANYTHING that had to access the network would
Hi,
Unfortunately this system hasn't worked for me. As it is I have a script
Have you tested it and included theses commands in rc.resume and rc.suspend ?
which lives in rc.d which starts up dhclient with the appropriate
wireless options. Unfortunately after each suspend and resume
Hi,
Here is the output of dhclient -v -d xl0
I I checked. Dhclient still initializes the
interface and brings it up itself. So there
is only one possibility:
You don't have a working link. Maybe it helps
if you add a interface define in /etc/dhclient.conf
wit the possible media.
Martin
On Sat, 9 Aug 2003, Martin Blapp wrote:
Isn't there a way to see that the card doesn't support reporting
media status ? If the card does report this, I could add code
to dhclient and all would be fine.
Yes; check the media status word for IFM_AVALID.
(whitespace damaged)
%%%
--- dhclient.c
On Sat, 9 Aug 2003, Martin Blapp wrote:
dhclient is still relying on behavior from the kernel that isn't
guaranteed.
I know. But I'd consider that as a kernel bug, not dhclient fault.
Would it help the set the card into promisc. mode anyway, even
if we don't have link ?
Except that you've
to
: unplug/replug the card and re-start dhclient to get connectivity again..
:
: Unless the lease time was ~30 minutes and you've changed networks, I doubt it.
:
: This sounds like a if_wi driver problem. Warner should be able to tell you
: more.
I still don't have a clear problem statement.
Warner
Argl, of course the patch was wrong. Ok, this should work
now ...
--- contrib/isc-dhcp/client/dhclient.c.orig Thu Aug 7 16:58:46 2003
+++ contrib/isc-dhcp/client/dhclient.c Sat Aug 9 21:47:14 2003
@@ -3288,19 +3288,24 @@
return (HAVELINK);
In message: [EMAIL PROTECTED]
Mark Sergeant [EMAIL PROTECTED] writes:
: wi0: Lucent Firmware: Station (6.14.1)
There are some known issues with lucent cards and the new wi driver.
A work around would be to upgrade firmware to the latest available.
This problem is poorly understood, so
dhclient and restarting manually works though.
Have you tested it and included theses commands in rc.resume and rc.suspend ?
which lives in rc.d which starts up dhclient with the appropriate
wireless options. Unfortunately after each suspend and resume this is
what I have to use
Hi,
Adapted to the newst source-version, the patch will look like
this. After I got home, I'll test it.
Martin
Index: client/dhclient.c
===
RCS file: /home/ncvs/src/contrib/isc-dhcp/client/dhclient.c,v
retrieving revision 1.30
.
Martin
--- etc/pccard_etherTue Aug 12 14:14:13 2003
+++ etc/pccard_etherTue Aug 12 14:43:31 2003
@@ -8,48 +8,55 @@
#
stop_dhcp() {
+ # If dhclient is already running, record
+ # it's interfaces.
+ if [ -x /usr/bin/grep ]; then
+ eval _active_list=\`/bin
On Sat, 9 Aug 2003, Craig Rodrigues wrote:
I just did a cvsup of -CURRENT and rebuilt the world.
dhclient doesn't seem to work for me any more.
It looks like a problem with dhclient, and not the
kernel, because an older version of dhclient works fine.
Here is the output of dhclient -v -d xl0
Unfortunately this system hasn't worked for me. As it is I have a script
which lives in rc.d which starts up dhclient with the appropriate
wireless options. Unfortunately after each suspend and resume this is
what I have to use.
If anyone comes up with a solution to this it'd be much appreciated
Hi,
Then I shall provide what I possibly can.
When using dhclient to configure my wi-driven lucent card (latest
firmware), it will work for a while (varying number of minutes - up to
30 or so) and then stop working, while spitting out messages like:
wi0: bad alloc 55c != 2a2, cur 0 nxt 0
wi0
Hi,
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: No Link on interface
Erm. What does 'ifconfig xl0' show you ? For dhclient
it looks like you have no link.
Martin
___
[EMAIL PROTECTED] mailing list
http
On Sat, Aug 09, 2003 at 06:21:43PM +0200, Martin Blapp wrote:
Hi,
Adapted to the newst source-version, the patch will look like
this. After I got home, I'll test it.
OK, this is weird. I did not use your change to dhclient.
However, I did use Matthew Dodd's change to if_xl.c.
I rebuilt
Have you done a ifconfig xl0 0.0.0.0 up before ?
xl0: No Link on interface
I think I'll have to support this, if the interface is
not initialized.
Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
I've got a toshiba portege 4000 with inbuilt wi0 wireless card. On
resume dhclient kicks off straight away which then breaks as the card
isn't loaded as yet. Is there anyway to specify a sleep value for
dhclient on resume from suspend ? I'm running current from today, I
should note I'm also seeing
Hi,
I've got a toshiba portege 4000 with inbuilt wi0 wireless card. On
resume dhclient kicks off straight away which then breaks as the card
You mean dhclient gets killed ? One way could be to kill dhclient when you
sleep. Afterwords, devd should restart it, right ? Unfortunatly I cannot
test
Hi,
Is this going to cure the cases where using DHCP results in my network
link going dead about ~30 minutes after getting a lease? At that point
it starts spitting out timeout errors and stuff, and i have to
unplug/replug the card and re-start dhclient to get connectivity again..
Thanks
On Sat, 9 Aug 2003, Martin Blapp wrote:
You don't have a working link. Maybe it helps if you add a interface
define in /etc/dhclient.conf wit the possible media.
dhclient is still relying on behavior from the kernel that isn't
guaranteed.
I posted a patch to if_xl.c that should correct
Hi,
Except that you've added code to dhclient that makes poor assumptions
about the ifmedia status word. Its optional; for hardware that you can
detect media status it can be used to display the status. For other
hardware, we shouldn't have to lie about media status; if the hardware
Hi,
dhclient is still relying on behavior from the kernel that isn't
guaranteed.
I know. But I'd consider that as a kernel bug, not dhclient fault.
Would it help the set the card into promisc. mode anyway, even
if we don't have link ?
I posted a patch to if_xl.c that should correct the link
I have now fixed the remaining issues.
Comments are welcome.
Martin
--
Simplify the pccard dhcp handling a lot. There are now
many configurations which have a NIC on board, and
pccard slots. If a dhclient is running on the internal
nic
On Sat, 9 Aug 2003, Matthew N. Dodd wrote:
Try this (cut paste):
The patch I posted was incorrect as I forgot to do a register window
select before reading media status.
ftp://ftp.jurai.net/users/winter/patches/xl_media.patch
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E |
On Sat, Aug 09, 2003 at 12:28:45PM +0200, Martin Blapp wrote:
Hi,
Here is the output of dhclient -v -d xl0
I I checked. Dhclient still initializes the
interface and brings it up itself. So there
is only one possibility:
You don't have a working link. Maybe it helps
if you add
Hi,
I just did a cvsup of -CURRENT and rebuilt the world.
dhclient doesn't seem to work for me any more.
It looks like a problem with dhclient, and not the
kernel, because an older version of dhclient works fine.
Here is the output of dhclient -v -d xl0
Hi,
Is this going to cure the cases where using DHCP results in my network
link going dead about ~30 minutes after getting a lease? At that point
it starts spitting out timeout errors and stuff, and i have to
unplug/replug the card and re-start dhclient to get connectivity again..
Unless
Hi all,
If you used wi(4) or en(4) wavelan cards and you had problems with dhclient,
you should try this patch, which treats interfaces with media settings
differently.
http://people.freebsd.org/~mbr/patches/dhclient-interfacepolling-fixup.diff
I'll produce a more clean patch this evening
Was there a change in the behaviour of dhclient and the dhclient.conf file?
I have the following dhclient.conf file that USED TO WORK to find the right
SSID
depending on where I am. It now doesn't.
# $FreeBSD: src/etc/dhclient.conf,v 1.3 2001/10/27 03:14:37 rwatson Exp $
#
# This file
Hi,
I have the following dhclient.conf file that USED TO WORK to find the right
SSID depending on where I am. It now doesn't.
Yes, there have been some changes. The most important was the interface polling
addition, but that should not make any difference here.
Can you start dhclient
On Mon, 4 Aug 2003, Martin Blapp wrote:
Yes, there have been some changes. The most important was the interface
polling addition, but that should not make any difference here.
Read the code.
dhclient.c:send_discover() bails out if interface_active() is false BEFORE
iterating all the possible
.
Yes, there have been some changes. The most important was the interface
polling addition, but that should not make any difference here.
Can you start dhclient with -d -v and see what it's doing ? And can you
try the same with a old dhclient and see if the behaviour is different ?
It could also
--On Monday, August 04, 2003 11:08:21 -0400 Matthew N. Dodd
[EMAIL PROTECTED] wrote:
On Mon, 4 Aug 2003, Martin Blapp wrote:
Yes, there have been some changes. The most important was the interface
polling addition, but that should not make any difference here.
Read the code.
Hi,
polling addition, but that should not make any difference here.
Read the code.
dhclient.c:send_discover() bails out if interface_active() is false BEFORE
iterating all the possible media settings.
interface_active() doesn't bail out. It returns 1, which means ok, and all
should be
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPACK from 207.136.3.254
bound to 207.136.3.72 -- renewal in 7726 seconds.
^C
Dhclient is definitly NOT the problem here. As mentioned in another thread,
there are some problems with the wi driver.
Please look if you can get a 2-3 month old dhclient
on wi0 to 255.255.255.255 port 67 interval 8
DHCPOFFER from 207.136.3.254
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPACK from 207.136.3.254
bound to 207.136.3.72 -- renewal in 7726 seconds.
^C
Dhclient is definitly NOT the problem here. As mentioned in another
thread, there are some problems
wepmode off ssid 'rednet' wepkey 1:- wepkey 2:- wepkey
3:- wepkey 4:- 1
DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 8
DHCPOFFER from 207.136.3.254
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPACK from 207.136.3.254
bound to 207.136.3.72 -- renewal in 7726 seconds.
^C
Dhclient
Hi,
Please look if you can get a 2-3 month old dhclient and I'm sure
you'll see the same behaviour there.
Negative. It was working with the WI driver from 5.0 through 5.1-CURRENT
until my make world last nite/this am.
oh, and 4.6-4.8 as well.
Ok,
You told me that it is working
--On Monday, August 04, 2003 18:22:04 +0200 Martin Blapp [EMAIL PROTECTED] wrote:
Hi,
Please look if you can get a 2-3 month old dhclient and I'm sure
you'll see the same behaviour there.
Negative. It was working with the WI driver from 5.0 through
5.1-CURRENT until my make world last
Hi,
How could dhclient see then that you were in a new network ? Do you mean
which dhclient was running changing networks ? Or kill dhclient and
restart it ?
reboot. I.E. I shutdown between home and office and vice versa.
SOMETHING seriously changed here.
Ahh ! I see now the change
--On Monday, August 04, 2003 20:19:05 +0200 Martin Blapp [EMAIL PROTECTED] wrote:
Hi,
How could dhclient see then that you were in a new network ? Do you
mean which dhclient was running changing networks ? Or kill dhclient
and restart it ?
reboot. I.E. I shutdown between home and office
Hi,
dhclient.c:send_discover() bails out if interface_active() is false BEFORE
iterating all the possible media settings.
Ok, problem understood now. I'm working on a fix.
Martin
___
[EMAIL PROTECTED] mailing list
Hi Larry,
This patch should fix the issues. It is not perfect, because
polling here is a bit complicated. Maybe it does the right
thing, but I think dhclient should at least check if one of the
conditions is suddenly right (we are associated, or we really
have link).
So this needs definitly
Forwarding to the list...
Forwarded Message
Date: Monday, August 04, 2003 20:18:28 -0500
From: Larry Rosenman [EMAIL PROTECTED]
To: Martin Blapp [EMAIL PROTECTED]
Cc:
Subject: Re: dhclient/dhclient.conf change in -CURRENT?
It did NOT do the right thing at boot
Tony Finch wrote:
Terry Lambert [EMAIL PROTECTED] wrote:
I can't wait for IPv6 stateless autoconfiguration plus SLPv2 so
we can get rid of all this DHCP crap once and for all. 8-(.
SLPv2 is used to find the gateway and DNS server, and after that,
everything magically works.
I thought that
Hi,
Odd:
%%%
# cat /etc/sleep_dhclient
#!/bin/sh
omshell /dev/null EOF
connect
new control
open
set state = 3
update
close
EOF
# cat /etc/wakeup_dhclient
#!/bin/sh
omshell /dev/null EOF
connect
new control
open
set state = 4
update
close
EOF
%%%
This was working
On Wed, Jul 30, 2003 at 08:52:19AM +0200, Martin Blapp wrote:
But the interface adding does still not work. Maybe a different
syntax than this ?
connect
new interface
open
set rl0 = up;
update
close
I think you want this syntax (although I still couldn't get it to work):
connect
new
101 - 200 of 249 matches
Mail list logo
