Re: dhclient fails: can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor

2017-02-10 Thread Iblis Lin
On Fri, Feb 10, 2017 at 04:10:41PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 10, 2017 at 05:29:54AM -0800, David Wolfskill wrote:
> > This was head @r313544; previous successful build/smoke test was
> > @r313467 (yesterday).
> > 
> > Here's an excerpt from a typescript I made of some "poking around";
> > subsequent to that, I was able to set the IP address, netmask, and
> > broadcast address on the NIC (wlano), then set the default route, and
> > once that was done, I was able to use the network:
> > 
> > wlan0: flags=8843 metric 0 mtu 1500
> > ether 00:24:d6:7a:03:ce
> > inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 
> > nd6 options=29
> > media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
> > status: associated
> > ssid lmdhw-net channel 1 (2412 MHz 11g ht/20) bssid 
> > 04:18:d6:22:22:1f
> > regdomain FCC country US authmode WPA2/802.11i privacy ON
> > deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
> > protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi
> > -stbc -ldpc wme roaming MANUAL
> > groups: wlan 
> > (12.0-C)[4] pgrep dhclient
> > (12.0-C)[5] dhclient wlan0
> > dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT
> > dhclient: Leaving hostname set to 
> > dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT
> > dhclient: reason was PREINIT; no action taken
> > dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0
> > can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor
> > exiting.
> > (12.0-C)[6] ls -lTio /var/db/dhclient.leases*
> > 883105 --  1 root  wheel  - 4017 Jan  4 09:18:10 2017 
> > /var/db/dhclient.leases.em0
> > 883280 --  1 root  wheel  -  856 Aug 11 04:52:54 2015 
> > /var/db/dhclient.leases.lagg0
> > 883344 --  1 root  wheel  -  Jan 20 21:19:10 2015 
> > /var/db/dhclient.leases.vboxnet0
> > 883108 --  1 root  wheel  - 1993 Feb 10 04:30:13 2017 
> > /var/db/dhclient.leases.wlan0
> > 883079 --  1 root  wheel  - 2013 Jan 19 11:52:07 2017 
> > /var/db/dhclient.leases.wlan1
> > 
> > 
> > Moving /var/db/dhclient.leases.wlan0 aside did not change the behavior.
> > 
> > Stable/11 shows the iwn(4) device as:
> > g1-252(11.0-S)[4] pciconf -lv | grep -A 3 iwn
> > iwn0@pci0:3:0:0:class=0x028000 card=0x13218086 chip=0x42328086 
> > rev=0x00 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'WiFi Link 5100'
> > class  = network
> > g1-252(11.0-S)[5] 
> > 
> > File system for /var is a fairly vanilla UFS2+SU.  I suppose I could have
> > tried ktrace (had I thought of it before switching back to the stable/11
> > slice).
> > 
> 
> Please try this.
> 
> diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c
> index 70cdcdc6f75..1f2cceaf7a6 100644
> --- a/sys/kern/vfs_vnops.c
> +++ b/sys/kern/vfs_vnops.c
> @@ -351,8 +351,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred 
> *cred,
>  
>   while ((fmode & (O_EXLOCK | O_SHLOCK)) != 0) {
>   KASSERT(fp != NULL, ("open with flock requires fp"));
> - if (fp->f_type != DTYPE_VNODE) {
> - error = EBADF;
> + if (fp->f_type != DTYPE_NONE && fp->f_type != DTYPE_VNODE) {
> + error = EOPNOTSUPP;
>   break;
>   }
>   lock_flags = VOP_ISLOCKED(vp);
> diff --git a/sys/sys/file.h b/sys/sys/file.h
> index 353c92f365a..c51f26a41d2 100644
> --- a/sys/sys/file.h
> +++ b/sys/sys/file.h
> @@ -53,6 +53,7 @@ struct vnode;
>  
>  #endif /* _KERNEL */
>  
> +#define  DTYPE_NONE  0   /* not yet initialized */
>  #define  DTYPE_VNODE 1   /* file */
>  #define  DTYPE_SOCKET2   /* communications endpoint */
>  #define  DTYPE_PIPE  3   /* pipe */
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

It works fine for me! :)

-- 
Iblis Lin
林峻頤
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: dhclient fails: can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor

2017-02-10 Thread Hans Petter Selasky

On 02/10/17 15:10, Konstantin Belousov wrote:

On Fri, Feb 10, 2017 at 05:29:54AM -0800, David Wolfskill wrote:

This was head @r313544; previous successful build/smoke test was
@r313467 (yesterday).

Here's an excerpt from a typescript I made of some "poking around";
subsequent to that, I was able to set the IP address, netmask, and
broadcast address on the NIC (wlano), then set the default route, and
once that was done, I was able to use the network:

wlan0: flags=8843 metric 0 mtu 1500
ether 00:24:d6:7a:03:ce
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
nd6 options=29
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
ssid lmdhw-net channel 1 (2412 MHz 11g ht/20) bssid 04:18:d6:22:22:1f
regdomain FCC country US authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi
-stbc -ldpc wme roaming MANUAL
groups: wlan
(12.0-C)[4] pgrep dhclient
(12.0-C)[5] dhclient wlan0
dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT
dhclient: Leaving hostname set to
dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT
dhclient: reason was PREINIT; no action taken
dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0
can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor
exiting.
(12.0-C)[6] ls -lTio /var/db/dhclient.leases*
883105 --  1 root  wheel  - 4017 Jan  4 09:18:10 2017 
/var/db/dhclient.leases.em0
883280 --  1 root  wheel  -  856 Aug 11 04:52:54 2015 
/var/db/dhclient.leases.lagg0
883344 --  1 root  wheel  -  Jan 20 21:19:10 2015 
/var/db/dhclient.leases.vboxnet0
883108 --  1 root  wheel  - 1993 Feb 10 04:30:13 2017 
/var/db/dhclient.leases.wlan0
883079 --  1 root  wheel  - 2013 Jan 19 11:52:07 2017 
/var/db/dhclient.leases.wlan1


Moving /var/db/dhclient.leases.wlan0 aside did not change the behavior.

Stable/11 shows the iwn(4) device as:
g1-252(11.0-S)[4] pciconf -lv | grep -A 3 iwn
iwn0@pci0:3:0:0:class=0x028000 card=0x13218086 chip=0x42328086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'WiFi Link 5100'
class  = network
g1-252(11.0-S)[5]

File system for /var is a fairly vanilla UFS2+SU.  I suppose I could have
tried ktrace (had I thought of it before switching back to the stable/11
slice).





Hi Konstantin,

I hit the exact same issue with some rack servers and can confirm the 
patch below fixes this issue.


--HPS


Please try this.

diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c
index 70cdcdc6f75..1f2cceaf7a6 100644
--- a/sys/kern/vfs_vnops.c
+++ b/sys/kern/vfs_vnops.c
@@ -351,8 +351,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred 
*cred,

while ((fmode & (O_EXLOCK | O_SHLOCK)) != 0) {
KASSERT(fp != NULL, ("open with flock requires fp"));
-   if (fp->f_type != DTYPE_VNODE) {
-   error = EBADF;
+   if (fp->f_type != DTYPE_NONE && fp->f_type != DTYPE_VNODE) {
+   error = EOPNOTSUPP;
break;
}
lock_flags = VOP_ISLOCKED(vp);
diff --git a/sys/sys/file.h b/sys/sys/file.h
index 353c92f365a..c51f26a41d2 100644
--- a/sys/sys/file.h
+++ b/sys/sys/file.h
@@ -53,6 +53,7 @@ struct vnode;

 #endif /* _KERNEL */

+#defineDTYPE_NONE  0   /* not yet initialized */
 #defineDTYPE_VNODE 1   /* file */
 #defineDTYPE_SOCKET2   /* communications endpoint */
 #defineDTYPE_PIPE  3   /* pipe */
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: dhclient fails: can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor

2017-02-10 Thread David Wolfskill
On Fri, Feb 10, 2017 at 04:10:41PM +0200, Konstantin Belousov wrote:
> ...
> Please try this.
> 
> diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c
> index 70cdcdc6f75..1f2cceaf7a6 100644
> --- a/sys/kern/vfs_vnops.c
> +++ b/sys/kern/vfs_vnops.c
> @@ -351,8 +351,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred 
> *cred,
>  
>   while ((fmode & (O_EXLOCK | O_SHLOCK)) != 0) {
>   KASSERT(fp != NULL, ("open with flock requires fp"));
> - if (fp->f_type != DTYPE_VNODE) {
> - error = EBADF;
> + if (fp->f_type != DTYPE_NONE && fp->f_type != DTYPE_VNODE) {
> + error = EOPNOTSUPP;
>   break;
>   }
>   lock_flags = VOP_ISLOCKED(vp);
> diff --git a/sys/sys/file.h b/sys/sys/file.h
> index 353c92f365a..c51f26a41d2 100644
> --- a/sys/sys/file.h
> +++ b/sys/sys/file.h
> @@ -53,6 +53,7 @@ struct vnode;
>  
>  #endif /* _KERNEL */
>  
> +#define  DTYPE_NONE  0   /* not yet initialized */
>  #define  DTYPE_VNODE 1   /* file */
>  #define  DTYPE_SOCKET2   /* communications endpoint */
>  #define  DTYPE_PIPE  3   /* pipe */


That seems to have done it -- thank you! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


Re: dhclient fails: can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor

2017-02-10 Thread Konstantin Belousov
On Fri, Feb 10, 2017 at 05:29:54AM -0800, David Wolfskill wrote:
> This was head @r313544; previous successful build/smoke test was
> @r313467 (yesterday).
> 
> Here's an excerpt from a typescript I made of some "poking around";
> subsequent to that, I was able to set the IP address, netmask, and
> broadcast address on the NIC (wlano), then set the default route, and
> once that was done, I was able to use the network:
> 
> wlan0: flags=8843 metric 0 mtu 1500
> ether 00:24:d6:7a:03:ce
> inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 
> nd6 options=29
> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
> status: associated
> ssid lmdhw-net channel 1 (2412 MHz 11g ht/20) bssid 04:18:d6:22:22:1f
> regdomain FCC country US authmode WPA2/802.11i privacy ON
> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi
> -stbc -ldpc wme roaming MANUAL
> groups: wlan 
> (12.0-C)[4] pgrep dhclient
> (12.0-C)[5] dhclient wlan0
> dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT
> dhclient: Leaving hostname set to 
> dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT
> dhclient: reason was PREINIT; no action taken
> dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0
> can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor
> exiting.
> (12.0-C)[6] ls -lTio /var/db/dhclient.leases*
> 883105 --  1 root  wheel  - 4017 Jan  4 09:18:10 2017 
> /var/db/dhclient.leases.em0
> 883280 --  1 root  wheel  -  856 Aug 11 04:52:54 2015 
> /var/db/dhclient.leases.lagg0
> 883344 --  1 root  wheel  -  Jan 20 21:19:10 2015 
> /var/db/dhclient.leases.vboxnet0
> 883108 --  1 root  wheel  - 1993 Feb 10 04:30:13 2017 
> /var/db/dhclient.leases.wlan0
> 883079 --  1 root  wheel  - 2013 Jan 19 11:52:07 2017 
> /var/db/dhclient.leases.wlan1
> 
> 
> Moving /var/db/dhclient.leases.wlan0 aside did not change the behavior.
> 
> Stable/11 shows the iwn(4) device as:
> g1-252(11.0-S)[4] pciconf -lv | grep -A 3 iwn
> iwn0@pci0:3:0:0:class=0x028000 card=0x13218086 chip=0x42328086 
> rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'WiFi Link 5100'
> class  = network
> g1-252(11.0-S)[5] 
> 
> File system for /var is a fairly vanilla UFS2+SU.  I suppose I could have
> tried ktrace (had I thought of it before switching back to the stable/11
> slice).
> 

Please try this.

diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c
index 70cdcdc6f75..1f2cceaf7a6 100644
--- a/sys/kern/vfs_vnops.c
+++ b/sys/kern/vfs_vnops.c
@@ -351,8 +351,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred 
*cred,
 
while ((fmode & (O_EXLOCK | O_SHLOCK)) != 0) {
KASSERT(fp != NULL, ("open with flock requires fp"));
-   if (fp->f_type != DTYPE_VNODE) {
-   error = EBADF;
+   if (fp->f_type != DTYPE_NONE && fp->f_type != DTYPE_VNODE) {
+   error = EOPNOTSUPP;
break;
}
lock_flags = VOP_ISLOCKED(vp);
diff --git a/sys/sys/file.h b/sys/sys/file.h
index 353c92f365a..c51f26a41d2 100644
--- a/sys/sys/file.h
+++ b/sys/sys/file.h
@@ -53,6 +53,7 @@ struct vnode;
 
 #endif /* _KERNEL */
 
+#defineDTYPE_NONE  0   /* not yet initialized */
 #defineDTYPE_VNODE 1   /* file */
 #defineDTYPE_SOCKET2   /* communications endpoint */
 #defineDTYPE_PIPE  3   /* pipe */
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: dhclient sucks cpu usage...

2014-06-10 Thread Alexander V. Chernikov

On 10.06.2014 07:03, Bryan Venteicher wrote:

Hi,

- Original Message -

So, after finding out that nc has a stupidly small buffer size (2k
even though there is space for 16k), I was still not getting as good
as performance using nc between machines, so I decided to generate some
flame graphs to try to identify issues...  (Thanks to who included a
full set of modules, including dtraceall on memstick!)

So, the first one is:
https://www.funkthat.com/~jmg/em.stack.svg

As I was browsing around, the em_handle_que was consuming quite a bit
of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
me that the taskqueue for em was consuming about 50% cpu...  Also pretty
high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
or anything, but I think dhclient uses bpf to be able to inject packets
and listen in on them, so I kill off dhclient, and instantly, the taskqueue
thread for em drops down to 40% CPU... (transfer rate only marginally
improves, if it does)

I decide to run another flame graph w/o dhclient running:
https://www.funkthat.com/~jmg/em.stack.nodhclient.svg

and now _rxeof drops from 17.22% to 11.94%, pretty significant...

So, if you care about performance, don't run dhclient...


Yes, I've noticed the same issue. It can absolutely kill performance
in a VM guest. It is much more pronounced on only some of my systems,
and I hadn't tracked it down yet. I wonder if this is fallout from
the callout work, or if there was some bpf change.

I've been using the kludgey workaround patch below.

Hm, pretty interesting.
dhclient should setup proper filter (and it looks like it does so:
13:10 [0] m@ptichko s netstat -B
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
 1224em0 -ifs--l  41225922 011 0 0 dhclient
)
see match count.
And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for 
each consumer on interface).

It should not introduce significant performance penalties.



diff --git a/sys/net/bpf.c b/sys/net/bpf.c
index cb3ed27..9751986 100644
--- a/sys/net/bpf.c
+++ b/sys/net/bpf.c
@@ -2013,9 +2013,11 @@ bpf_gettime(struct bintime *bt, int tstype, struct mbuf 
*m)
return (BPF_TSTAMP_EXTERN);
}
}
+#if 0
if (quality == BPF_TSTAMP_NORMAL)
binuptime(bt);
else
+#endif

bpf_getttime() is called IFF packet filter matches some traffic.
Can you show your netstat -B output ?

getbinuptime(bt);
  
  	return (quality);




--
   John-Mark Gurney Voice: +1 415 225 5579

  All that I will do, has been done, All that I have, has not.
___
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-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-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 sucks cpu usage...

2014-06-10 Thread John-Mark Gurney
Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 13:17 +0400:
 On 10.06.2014 07:03, Bryan Venteicher wrote:
 Hi,
 
 - Original Message -
 So, after finding out that nc has a stupidly small buffer size (2k
 even though there is space for 16k), I was still not getting as good
 as performance using nc between machines, so I decided to generate some
 flame graphs to try to identify issues...  (Thanks to who included a
 full set of modules, including dtraceall on memstick!)
 
 So, the first one is:
 https://www.funkthat.com/~jmg/em.stack.svg
 
 As I was browsing around, the em_handle_que was consuming quite a bit
 of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
 me that the taskqueue for em was consuming about 50% cpu...  Also pretty
 high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
 consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
 or anything, but I think dhclient uses bpf to be able to inject packets
 and listen in on them, so I kill off dhclient, and instantly, the 
 taskqueue
 thread for em drops down to 40% CPU... (transfer rate only marginally
 improves, if it does)
 
 I decide to run another flame graph w/o dhclient running:
 https://www.funkthat.com/~jmg/em.stack.nodhclient.svg
 
 and now _rxeof drops from 17.22% to 11.94%, pretty significant...
 
 So, if you care about performance, don't run dhclient...
 
 Yes, I've noticed the same issue. It can absolutely kill performance
 in a VM guest. It is much more pronounced on only some of my systems,
 and I hadn't tracked it down yet. I wonder if this is fallout from
 the callout work, or if there was some bpf change.
 
 I've been using the kludgey workaround patch below.
 Hm, pretty interesting.
 dhclient should setup proper filter (and it looks like it does so:
 13:10 [0] m@ptichko s netstat -B
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  1224em0 -ifs--l  41225922 011 0 0 dhclient
 )
 see match count.
 And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for 
 each consumer on interface).
 It should not introduce significant performance penalties.

Don't forget that it has to process the returning ack's... So, you're
looking around 10k+ pps that you have to handle and pass through the
filter...  That's a lot of packets to process...

Just for a bit more double check, instead of using the HD as a
source, I used /dev/zero...   I ran a netstat -w 1 -I em0 when
running the test, and I was getting ~50.7MiB/s w/ dhclient running and
then I killed dhclient and it instantly jumped up to ~57.1MiB/s.. So I
launched dhclient again, and it dropped back to ~50MiB/s...

and some of this slowness is due to nc using small buffers which I will
fix shortly..

And with witness disabled it goes from 58MiB/s to 65.7MiB/s..  In
both cases, that's a 13% performance improvement by running w/o
dhclient...

This is using the latest memstick image, r266655 on a (Lenovo T61):
FreeBSD 11.0-CURRENT #0 r266655: Sun May 25 18:55:02 UTC 2014
r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
WARNING: WITNESS option enabled, expect reduced performance.
CPU: Intel(R) Core(TM)2 Duo CPU T7300  @ 2.00GHz (1995.05-MHz K8-class CPU)
  Origin=GenuineIntel  Id=0x6fb  Family=0x6  Model=0xf  Stepping=11
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant, performance statistics
real memory  = 2147483648 (2048 MB)
avail memory = 2014019584 (1920 MB)

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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 sucks cpu usage...

2014-06-10 Thread Alexander V. Chernikov

On 10.06.2014 20:24, John-Mark Gurney wrote:

Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 13:17 +0400:

On 10.06.2014 07:03, Bryan Venteicher wrote:

Hi,

- Original Message -

So, after finding out that nc has a stupidly small buffer size (2k
even though there is space for 16k), I was still not getting as good
as performance using nc between machines, so I decided to generate some
flame graphs to try to identify issues...  (Thanks to who included a
full set of modules, including dtraceall on memstick!)

So, the first one is:
https://www.funkthat.com/~jmg/em.stack.svg

As I was browsing around, the em_handle_que was consuming quite a bit
of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
me that the taskqueue for em was consuming about 50% cpu...  Also pretty
high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
or anything, but I think dhclient uses bpf to be able to inject packets
and listen in on them, so I kill off dhclient, and instantly, the
taskqueue
thread for em drops down to 40% CPU... (transfer rate only marginally
improves, if it does)

I decide to run another flame graph w/o dhclient running:
https://www.funkthat.com/~jmg/em.stack.nodhclient.svg

and now _rxeof drops from 17.22% to 11.94%, pretty significant...

So, if you care about performance, don't run dhclient...


Yes, I've noticed the same issue. It can absolutely kill performance
in a VM guest. It is much more pronounced on only some of my systems,
and I hadn't tracked it down yet. I wonder if this is fallout from
the callout work, or if there was some bpf change.

I've been using the kludgey workaround patch below.

Hm, pretty interesting.
dhclient should setup proper filter (and it looks like it does so:
13:10 [0] m@ptichko s netstat -B
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  1224em0 -ifs--l  41225922 011 0 0 dhclient
)
see match count.
And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
each consumer on interface).
It should not introduce significant performance penalties.

Don't forget that it has to process the returning ack's... So, you're
Well, it can be still captured with the proper filter like ip  udp  
port 67 or port 68.
We're using tcpdump on high packet ratios (1M) and it does not 
influence process _much_.
We should probably convert its rwlock to rmlock and use per-cpu counters 
for statistics, but that's a different story.

looking around 10k+ pps that you have to handle and pass through the
filter...  That's a lot of packets to process...

Just for a bit more double check, instead of using the HD as a
source, I used /dev/zero...   I ran a netstat -w 1 -I em0 when
running the test, and I was getting ~50.7MiB/s w/ dhclient running and
then I killed dhclient and it instantly jumped up to ~57.1MiB/s.. So I
launched dhclient again, and it dropped back to ~50MiB/s...
dhclient uses different BPF sockets for reading and writing (and it 
moves write socket to privileged child process via fork().
The problem we're facing with is the fact that dhclient does not set 
_any_ read filter on write socket:

21:27 [0] zfscurr0# netstat -B
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
 1529em0 --fs--l 86774 86769 86784  4044  3180 dhclient
--- ^ --
 1526em0 -ifs--l 86789 0 1 0 0 dhclient

so all traffic is pushed down introducing contention on BPF descriptor 
mutex.


(That's why I've asked for netstat -B output.)

Please try an attached patch to fix this. This is not the right way to 
fix this, we'd better change BPF behavior not to attach to interface 
readers for write-only consumers.
This have been partially implemented as net.bpf.optimize_writers hack, 
but it does not work for all direct BPF consumers (which are not using 
pcap(3) API).




and some of this slowness is due to nc using small buffers which I will
fix shortly..

And with witness disabled it goes from 58MiB/s to 65.7MiB/s..  In
both cases, that's a 13% performance improvement by running w/o
dhclient...

This is using the latest memstick image, r266655 on a (Lenovo T61):
FreeBSD 11.0-CURRENT #0 r266655: Sun May 25 18:55:02 UTC 2014
 r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
WARNING: WITNESS option enabled, expect reduced performance.
CPU: Intel(R) Core(TM)2 Duo CPU T7300  @ 2.00GHz (1995.05-MHz K8-class CPU)
   Origin=GenuineIntel  Id=0x6fb  Family=0x6  Model=0xf  Stepping=11
   
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
   Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
   AMD 

Re: dhclient sucks cpu usage...

2014-06-10 Thread Bryan Venteicher


- Original Message -
 On 10.06.2014 07:03, Bryan Venteicher wrote:
  Hi,
 
  - Original Message -
  So, after finding out that nc has a stupidly small buffer size (2k
  even though there is space for 16k), I was still not getting as good
  as performance using nc between machines, so I decided to generate some
  flame graphs to try to identify issues...  (Thanks to who included a
  full set of modules, including dtraceall on memstick!)
 
  So, the first one is:
  https://www.funkthat.com/~jmg/em.stack.svg
 
  As I was browsing around, the em_handle_que was consuming quite a bit
  of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
  me that the taskqueue for em was consuming about 50% cpu...  Also pretty
  high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
  consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
  or anything, but I think dhclient uses bpf to be able to inject packets
  and listen in on them, so I kill off dhclient, and instantly, the
  taskqueue
  thread for em drops down to 40% CPU... (transfer rate only marginally
  improves, if it does)
 
  I decide to run another flame graph w/o dhclient running:
  https://www.funkthat.com/~jmg/em.stack.nodhclient.svg
 
  and now _rxeof drops from 17.22% to 11.94%, pretty significant...
 
  So, if you care about performance, don't run dhclient...
 
  Yes, I've noticed the same issue. It can absolutely kill performance
  in a VM guest. It is much more pronounced on only some of my systems,
  and I hadn't tracked it down yet. I wonder if this is fallout from
  the callout work, or if there was some bpf change.
 
  I've been using the kludgey workaround patch below.
 Hm, pretty interesting.
 dhclient should setup proper filter (and it looks like it does so:
 13:10 [0] m@ptichko s netstat -B
Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
   1224em0 -ifs--l  41225922 011 0 0 dhclient
 )
 see match count.
 And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
 each consumer on interface).
 It should not introduce significant performance penalties.
 


It will be a bit before I'm able to capture that. Here's a Flamegraph from
earlier in the year showing an absurd amount of time spent in bpf_mtap():

http://people.freebsd.org/~bryanv/vtnet/vtnet-bpf-10.svg


 
  diff --git a/sys/net/bpf.c b/sys/net/bpf.c
  index cb3ed27..9751986 100644
  --- a/sys/net/bpf.c
  +++ b/sys/net/bpf.c
  @@ -2013,9 +2013,11 @@ bpf_gettime(struct bintime *bt, int tstype, struct
  mbuf *m)
  return (BPF_TSTAMP_EXTERN);
  }
  }
  +#if 0
  if (quality == BPF_TSTAMP_NORMAL)
  binuptime(bt);
  else
  +#endif
 bpf_getttime() is called IFF packet filter matches some traffic.
 Can you show your netstat -B output ?
  getbinuptime(bt);

  return (quality);
 
 
  --
 John-Mark GurneyVoice: +1 415 225 5579
 
All that I will do, has been done, All that I have, has not.
  ___
  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-...@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-net
  To unsubscribe, send any mail to freebsd-net-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 sucks cpu usage...

2014-06-10 Thread Alexander V. Chernikov

On 10.06.2014 22:11, Bryan Venteicher wrote:


- Original Message -

On 10.06.2014 07:03, Bryan Venteicher wrote:

Hi,

- Original Message -

So, after finding out that nc has a stupidly small buffer size (2k
even though there is space for 16k), I was still not getting as good
as performance using nc between machines, so I decided to generate some
flame graphs to try to identify issues...  (Thanks to who included a
full set of modules, including dtraceall on memstick!)

So, the first one is:
https://www.funkthat.com/~jmg/em.stack.svg

As I was browsing around, the em_handle_que was consuming quite a bit
of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
me that the taskqueue for em was consuming about 50% cpu...  Also pretty
high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
or anything, but I think dhclient uses bpf to be able to inject packets
and listen in on them, so I kill off dhclient, and instantly, the
taskqueue
thread for em drops down to 40% CPU... (transfer rate only marginally
improves, if it does)

I decide to run another flame graph w/o dhclient running:
https://www.funkthat.com/~jmg/em.stack.nodhclient.svg

and now _rxeof drops from 17.22% to 11.94%, pretty significant...

So, if you care about performance, don't run dhclient...


Yes, I've noticed the same issue. It can absolutely kill performance
in a VM guest. It is much more pronounced on only some of my systems,
and I hadn't tracked it down yet. I wonder if this is fallout from
the callout work, or if there was some bpf change.

I've been using the kludgey workaround patch below.

Hm, pretty interesting.
dhclient should setup proper filter (and it looks like it does so:
13:10 [0] m@ptichko s netstat -B
Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
   1224em0 -ifs--l  41225922 011 0 0 dhclient
)
see match count.
And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
each consumer on interface).
It should not introduce significant performance penalties.



It will be a bit before I'm able to capture that. Here's a Flamegraph from
earlier in the year showing an absurd amount of time spent in bpf_mtap():

Can you briefly describe test setup?
(Actually I'm interested in overall pps rate, bpf filter used and match 
ratio).


For example, for some random box at $work:
22:17 [0] m@sas1-fw1 netstat -I vlan802 -w1
input  (vlan802)   output
   packets  errs idrops  bytespackets  errs  bytes colls
430418 0 0  337712454 396282 0  333207773 0
CPU:  0.4% user,  0.0% nice,  1.2% system, 15.9% interrupt, 82.5% idle

2:17 [0] sas1-fw1# tcpdump -i vlan802 -lnps0 icmp and host X.X.X.X
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan802, link-type EN10MB (Ethernet), capture size 65535 bytes
22:17:14.866085 IP X.X.X.X  Y.Y.Y.Y: ICMP echo request, id 6730, seq 1, 
length 64


22:17 [0] m@sas1-fw1 s netstat -B 2/dev/null | grep tcpdump
98520 vlan802 ---s---  27979422 040 0 0 tcpdump

CPU:  0.9% user,  0.0% nice,  2.7% system, 17.6% interrupt, 78.8% idle
(Actually the load is floating due to bursty traffic in 14-20% rate but 
I can't see much difference with tcpdump turned on/off).




http://people.freebsd.org/~bryanv/vtnet/vtnet-bpf-10.svg



diff --git a/sys/net/bpf.c b/sys/net/bpf.c
index cb3ed27..9751986 100644
--- a/sys/net/bpf.c
+++ b/sys/net/bpf.c
@@ -2013,9 +2013,11 @@ bpf_gettime(struct bintime *bt, int tstype, struct
mbuf *m)
return (BPF_TSTAMP_EXTERN);
}
}
+#if 0
if (quality == BPF_TSTAMP_NORMAL)
binuptime(bt);
else
+#endif

bpf_getttime() is called IFF packet filter matches some traffic.
Can you show your netstat -B output ?

getbinuptime(bt);
   
   	return (quality);




--
John-Mark GurneyVoice: +1 415 225 5579

   All that I will do, has been done, All that I have, has not.
___
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-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-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 sucks cpu usage...

2014-06-10 Thread John-Mark Gurney
Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 22:21 +0400:
 On 10.06.2014 22:11, Bryan Venteicher wrote:
 
 - Original Message -
 On 10.06.2014 07:03, Bryan Venteicher wrote:
 Hi,
 
 - Original Message -
 So, after finding out that nc has a stupidly small buffer size (2k
 even though there is space for 16k), I was still not getting as good
 as performance using nc between machines, so I decided to generate some
 flame graphs to try to identify issues...  (Thanks to who included a
 full set of modules, including dtraceall on memstick!)
 
 So, the first one is:
 https://www.funkthat.com/~jmg/em.stack.svg
 
 As I was browsing around, the em_handle_que was consuming quite a bit
 of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
 me that the taskqueue for em was consuming about 50% cpu...  Also pretty
 high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
 consuming ~3.18% (under ether_nh_input)..  I know I'm not running 
 tcpdump
 or anything, but I think dhclient uses bpf to be able to inject packets
 and listen in on them, so I kill off dhclient, and instantly, the
 taskqueue
 thread for em drops down to 40% CPU... (transfer rate only marginally
 improves, if it does)
 
 I decide to run another flame graph w/o dhclient running:
 https://www.funkthat.com/~jmg/em.stack.nodhclient.svg
 
 and now _rxeof drops from 17.22% to 11.94%, pretty significant...
 
 So, if you care about performance, don't run dhclient...
 
 Yes, I've noticed the same issue. It can absolutely kill performance
 in a VM guest. It is much more pronounced on only some of my systems,
 and I hadn't tracked it down yet. I wonder if this is fallout from
 the callout work, or if there was some bpf change.
 
 I've been using the kludgey workaround patch below.
 Hm, pretty interesting.
 dhclient should setup proper filter (and it looks like it does so:
 13:10 [0] m@ptichko s netstat -B
 Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
1224em0 -ifs--l  41225922 011 0 0 dhclient
 )
 see match count.
 And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
 each consumer on interface).
 It should not introduce significant performance penalties.
 
 
 It will be a bit before I'm able to capture that. Here's a Flamegraph from
 earlier in the year showing an absurd amount of time spent in bpf_mtap():
 Can you briefly describe test setup?

For mine, one machine is sink:
nc -l 2387  /dev/null

The machine w/ dhclient is source:
nc carbon 2387  /dev/zero

 (Actually I'm interested in overall pps rate, bpf filter used and match 
 ratio).

the overal rate is ~26k pps both in and out (so total ~52kpps)...

So, netstat -B; sleep 5; netstat -B gives:
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  919em0 --fs--l   6275907   6275938   6275961  4060  2236 dhclient
  937em0 -ifs--l   6275992 0 1 0 0 dhclient
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  919em0 --fs--l   6539717   6539752   6539775  4060  2236 dhclient
  937em0 -ifs--l   6539806 0 1 0 0 dhclient

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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 sucks cpu usage...

2014-06-10 Thread John-Mark Gurney
Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 21:33 +0400:
 On 10.06.2014 20:24, John-Mark Gurney wrote:
 Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 13:17 
 +0400:
 On 10.06.2014 07:03, Bryan Venteicher wrote:
 Hi,
 
 - Original Message -
 So, after finding out that nc has a stupidly small buffer size (2k
 even though there is space for 16k), I was still not getting as good
 as performance using nc between machines, so I decided to generate some
 flame graphs to try to identify issues...  (Thanks to who included a
 full set of modules, including dtraceall on memstick!)
 
 So, the first one is:
 https://www.funkthat.com/~jmg/em.stack.svg
 
 As I was browsing around, the em_handle_que was consuming quite a bit
 of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
 me that the taskqueue for em was consuming about 50% cpu...  Also pretty
 high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
 consuming ~3.18% (under ether_nh_input)..  I know I'm not running 
 tcpdump
 or anything, but I think dhclient uses bpf to be able to inject packets
 and listen in on them, so I kill off dhclient, and instantly, the
 taskqueue
 thread for em drops down to 40% CPU... (transfer rate only marginally
 improves, if it does)
 
 I decide to run another flame graph w/o dhclient running:
 https://www.funkthat.com/~jmg/em.stack.nodhclient.svg
 
 and now _rxeof drops from 17.22% to 11.94%, pretty significant...
 
 So, if you care about performance, don't run dhclient...
 
 Yes, I've noticed the same issue. It can absolutely kill performance
 in a VM guest. It is much more pronounced on only some of my systems,
 and I hadn't tracked it down yet. I wonder if this is fallout from
 the callout work, or if there was some bpf change.
 
 I've been using the kludgey workaround patch below.
 Hm, pretty interesting.
 dhclient should setup proper filter (and it looks like it does so:
 13:10 [0] m@ptichko s netstat -B
Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
   1224em0 -ifs--l  41225922 011 0 0 dhclient
 )
 see match count.
 And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
 each consumer on interface).
 It should not introduce significant performance penalties.
 Don't forget that it has to process the returning ack's... So, you're
 Well, it can be still captured with the proper filter like ip  udp  
 port 67 or port 68.
 We're using tcpdump on high packet ratios (1M) and it does not 
 influence process _much_.
 We should probably convert its rwlock to rmlock and use per-cpu counters 
 for statistics, but that's a different story.
 looking around 10k+ pps that you have to handle and pass through the
 filter...  That's a lot of packets to process...
 
 Just for a bit more double check, instead of using the HD as a
 source, I used /dev/zero...   I ran a netstat -w 1 -I em0 when
 running the test, and I was getting ~50.7MiB/s w/ dhclient running and
 then I killed dhclient and it instantly jumped up to ~57.1MiB/s.. So I
 launched dhclient again, and it dropped back to ~50MiB/s...
 dhclient uses different BPF sockets for reading and writing (and it 
 moves write socket to privileged child process via fork().
 The problem we're facing with is the fact that dhclient does not set 
 _any_ read filter on write socket:
 21:27 [0] zfscurr0# netstat -B
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  1529em0 --fs--l 86774 86769 86784  4044  3180 dhclient
 --- ^ --
  1526em0 -ifs--l 86789 0 1 0 0 dhclient
 
 so all traffic is pushed down introducing contention on BPF descriptor 
 mutex.
 
 (That's why I've asked for netstat -B output.)
 
 Please try an attached patch to fix this. This is not the right way to 
 fix this, we'd better change BPF behavior not to attach to interface 
 readers for write-only consumers.
 This have been partially implemented as net.bpf.optimize_writers hack, 
 but it does not work for all direct BPF consumers (which are not using 
 pcap(3) API).

Ok, looks like this patch helps the issue...

netstat -B; sleep 5; netstat -B:
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  958em0 --fs--l   3881435  3868  2236 dhclient
  976em0 -ifs--l   3880014 0 1 0 0 dhclient
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  958em0 --fs--l   41785251435  3868  2236 dhclient
  976em0 -ifs--l   4178539 0 1 0 0 dhclient

and now the rate only drops from ~66MiB/s to ~63MiB/s when dhclient is
running...  Still a significant drop (5%), but better than before...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.

Re: dhclient sucks cpu usage...

2014-06-10 Thread Alexander V. Chernikov
On 10.06.2014 22:56, John-Mark Gurney wrote:
 Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 21:33 +0400:
 On 10.06.2014 20:24, John-Mark Gurney wrote:
 Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 13:17 
 +0400:
 On 10.06.2014 07:03, Bryan Venteicher wrote:
 Hi,

 - Original Message -
 So, after finding out that nc has a stupidly small buffer size (2k
 even though there is space for 16k), I was still not getting as good
 as performance using nc between machines, so I decided to generate some
 flame graphs to try to identify issues...  (Thanks to who included a
 full set of modules, including dtraceall on memstick!)

 So, the first one is:
 https://www.funkthat.com/~jmg/em.stack.svg

 As I was browsing around, the em_handle_que was consuming quite a bit
 of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
 me that the taskqueue for em was consuming about 50% cpu...  Also pretty
 high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
 consuming ~3.18% (under ether_nh_input)..  I know I'm not running 
 tcpdump
 or anything, but I think dhclient uses bpf to be able to inject packets
 and listen in on them, so I kill off dhclient, and instantly, the
 taskqueue
 thread for em drops down to 40% CPU... (transfer rate only marginally
 improves, if it does)

 I decide to run another flame graph w/o dhclient running:
 https://www.funkthat.com/~jmg/em.stack.nodhclient.svg

 and now _rxeof drops from 17.22% to 11.94%, pretty significant...

 So, if you care about performance, don't run dhclient...

 Yes, I've noticed the same issue. It can absolutely kill performance
 in a VM guest. It is much more pronounced on only some of my systems,
 and I hadn't tracked it down yet. I wonder if this is fallout from
 the callout work, or if there was some bpf change.

 I've been using the kludgey workaround patch below.
 Hm, pretty interesting.
 dhclient should setup proper filter (and it looks like it does so:
 13:10 [0] m@ptichko s netstat -B
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  1224em0 -ifs--l  41225922 011 0 0 dhclient
 )
 see match count.
 And BPF itself adds the cost of read rwlock (+ bgp_filter() calls for
 each consumer on interface).
 It should not introduce significant performance penalties.
 Don't forget that it has to process the returning ack's... So, you're
 Well, it can be still captured with the proper filter like ip  udp  
 port 67 or port 68.
 We're using tcpdump on high packet ratios (1M) and it does not 
 influence process _much_.
 We should probably convert its rwlock to rmlock and use per-cpu counters 
 for statistics, but that's a different story.
 looking around 10k+ pps that you have to handle and pass through the
 filter...  That's a lot of packets to process...

 Just for a bit more double check, instead of using the HD as a
 source, I used /dev/zero...   I ran a netstat -w 1 -I em0 when
 running the test, and I was getting ~50.7MiB/s w/ dhclient running and
 then I killed dhclient and it instantly jumped up to ~57.1MiB/s.. So I
 launched dhclient again, and it dropped back to ~50MiB/s...
 dhclient uses different BPF sockets for reading and writing (and it 
 moves write socket to privileged child process via fork().
 The problem we're facing with is the fact that dhclient does not set 
 _any_ read filter on write socket:
 21:27 [0] zfscurr0# netstat -B
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  1529em0 --fs--l 86774 86769 86784  4044  3180 dhclient
 --- ^ --
  1526em0 -ifs--l 86789 0 1 0 0 dhclient

 so all traffic is pushed down introducing contention on BPF descriptor 
 mutex.

 (That's why I've asked for netstat -B output.)

 Please try an attached patch to fix this. This is not the right way to 
 fix this, we'd better change BPF behavior not to attach to interface 
 readers for write-only consumers.
 This have been partially implemented as net.bpf.optimize_writers hack, 
 but it does not work for all direct BPF consumers (which are not using 
 pcap(3) API).
 
 Ok, looks like this patch helps the issue...
 
 netstat -B; sleep 5; netstat -B:
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
   958em0 --fs--l   3881435  3868  2236 dhclient
   976em0 -ifs--l   3880014 0 1 0 0 dhclient
   Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
   958em0 --fs--l   41785251435  3868  2236 dhclient
   976em0 -ifs--l   4178539 0 1 0 0 dhclient
 
 and now the rate only drops from ~66MiB/s to ~63MiB/s when dhclient is
 running...  Still a significant drop (5%), but better than before...
Interesting.
Can you provide some traces (pmc or dtrace ones)?

I'm unsure if this will help, but it's 

Re: dhclient sucks cpu usage...

2014-06-09 Thread Bryan Venteicher
Hi,

- Original Message -
 So, after finding out that nc has a stupidly small buffer size (2k
 even though there is space for 16k), I was still not getting as good
 as performance using nc between machines, so I decided to generate some
 flame graphs to try to identify issues...  (Thanks to who included a
 full set of modules, including dtraceall on memstick!)
 
 So, the first one is:
 https://www.funkthat.com/~jmg/em.stack.svg
 
 As I was browsing around, the em_handle_que was consuming quite a bit
 of cpu usage for only doing ~50MB/sec over gige..  Running top -SH shows
 me that the taskqueue for em was consuming about 50% cpu...  Also pretty
 high for only 50MB/sec...  Looking closer, you'll see that bpf_mtap is
 consuming ~3.18% (under ether_nh_input)..  I know I'm not running tcpdump
 or anything, but I think dhclient uses bpf to be able to inject packets
 and listen in on them, so I kill off dhclient, and instantly, the taskqueue
 thread for em drops down to 40% CPU... (transfer rate only marginally
 improves, if it does)
 
 I decide to run another flame graph w/o dhclient running:
 https://www.funkthat.com/~jmg/em.stack.nodhclient.svg
 
 and now _rxeof drops from 17.22% to 11.94%, pretty significant...
 
 So, if you care about performance, don't run dhclient...
 

Yes, I've noticed the same issue. It can absolutely kill performance
in a VM guest. It is much more pronounced on only some of my systems,
and I hadn't tracked it down yet. I wonder if this is fallout from
the callout work, or if there was some bpf change.

I've been using the kludgey workaround patch below.

diff --git a/sys/net/bpf.c b/sys/net/bpf.c
index cb3ed27..9751986 100644
--- a/sys/net/bpf.c
+++ b/sys/net/bpf.c
@@ -2013,9 +2013,11 @@ bpf_gettime(struct bintime *bt, int tstype, struct mbuf 
*m)
return (BPF_TSTAMP_EXTERN);
}
}
+#if 0
if (quality == BPF_TSTAMP_NORMAL)
binuptime(bt);
else
+#endif
getbinuptime(bt);
 
return (quality);


 --
   John-Mark GurneyVoice: +1 415 225 5579
 
  All that I will do, has been done, All that I have, has not.
 ___
 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 can't limit bpf descriptor?

2013-12-15 Thread Pawel Jakub Dawidek
On Sat, Dec 14, 2013 at 12:12:23PM -0800, Tim Kientzle wrote:
 Opened up an old VM from a month or so ago (r257910) and dhclient won’t start.
 
 Specifically, dhclient complains (when run by root):
  “can’t limit bpf descriptor: Bad address”
 and then immediately exits.
 
 What does this mean?   I don’t know anything about the capabilities
 framework and certainly haven’t configured it in any way.

Maybe your userland and kernel are out of sync? There was
backward-incompatible change in Capsicum that could result in error like
that (capability rights are now passed as a pointer to a structure and
not uint64_t bitfield).

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com


pgpOTGPPh0ZvY.pgp
Description: PGP signature


Re: dhclient can't limit bpf descriptor?

2013-12-14 Thread Darren Pilgrim

On 12/14/2013 12:12 PM, Tim Kientzle wrote:

Opened up an old VM from a month or so ago (r257910) and dhclient won’t start.

Specifically, dhclient complains (when run by root):
  “can’t limit bpf descriptor: Bad address”
and then immediately exits.


Are you running a custom kernel without the Capsicum options?


___
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 can't limit bpf descriptor?

2013-12-14 Thread Tim Kientzle

On Dec 14, 2013, at 3:16 PM, Darren Pilgrim list_free...@bluerosetech.com 
wrote:

 On 12/14/2013 12:12 PM, Tim Kientzle wrote:
 Opened up an old VM from a month or so ago (r257910) and dhclient won’t 
 start.
 
 Specifically, dhclient complains (when run by root):
  “can’t limit bpf descriptor: Bad address”
 and then immediately exits.
 
 Are you running a custom kernel without the Capsicum options?

Nope, it’s an unmodified GENERIC kernel.

Tim

___
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 failure with Realtek 8111E Ethernet on new MSI motherboard

2013-11-08 Thread Thomas Mueller
For a future test of any updates to re driver, it might be best if I comment 
out device re in kernel config and test the update by building the module.

I never built just a single module before, not sure if I would do it the 
correct way.

Simply make in /usr/src/sys/modules/re
and then make install or copy the resulting module files?

Maybe check the kernel source in NetBSD-current source tree?

I am not sure how to configure an Ethernet connection without DHCP or even if 
it would work.

Tom

___
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 failure with Realtek 8111E Ethernet on new MSI motherboard

2013-11-08 Thread Thomas Mueller
from Daniel Nebdal:

 Ethernet without DHCP is fairly doable.
 Assuming that the network is 192.168.0.x , that .100 is free, and your
 router has .1 :
 
 ifconfig re0 192.168.0.100/24
 route add default 192.168.0.1
 
 As for DNS, I'd suggest checking on another machine what servers you get
 from DHCP. For each one, add a line like
 nameserver 8.8.8.8
 to /etc/resolv.conf .

I think I'll try something like that: good to know how.

On Slackware Linux I did, as best I remember:

ifconfig eth0 192.168.1.254 netmask 255.255.255.0
route add default 192.168.1.1 dev eth0
route add default gw 192.168.1.254 dev eth0

So it looks like I only need two lines in FreeBSD or NetBSD.

Subsequently, after running several live CDs and seeing how easy it was with 
DHCP, I switched to DHCP on one Slackware upgrade.

I could copy from /etc/resolv.conf on other computer where re is good with 
Realtek 8111E Ethernet, or I could copy from NetBSD-current amd64 
/etc/resolv.conf.

If I fail with manual setup on FreeBSD, as is likely because of bug in re 
driver, I could try with NetBSD just to verify that my ifconfig and route 
commands are correct, or I could try with NetBSD first to see if I have the 
correct commands.

When I was with BellSouth, then ATT Fastaccess DSL, DSL modem-router IP address 
was 192.168.1.254 .

Tom

___
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 failure with Realtek 8111E Ethernet on new MSI motherboard

2013-11-07 Thread Yonghyeon PYUN
On Thu, Nov 07, 2013 at 02:25:18AM +, Thomas Mueller wrote:
 I tried the patch on 9.2-STABLE, rebuilt the kernel and modules, installed to 
 the correct place on USB stick, 
 /media/zip0/boot/kernelre
 USB stick was mounted on /media/zip0 when I did this.
 
 Then I umounted, took the USB stick to new computer with MSI Z77 MPOWER 
 motherboard.
 
 I booted that USB stick, escaped to loader prompt, unload and
 boot /boot/kernelre/kernel
 
 got the same error when running dhclient re0.
 

Hmm, then I have no idea at this moment. :-(
If I manage to find any clue, I'll let you know.
Thanks a lot for testing!

 Now I also have to update NetBSD-current and then build a Linux installation.
 
 Linux may offer a better chance of configuring wireless adapters.
 
 I was hoping a fix to the re(4) bug could make it for FreeBSD 10.0-RELEASE 
 but am not betting on it.
 
 
 Tom
 
___
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 failure with Realtek 8111E Ethernet on new MSI motherboard

2013-11-06 Thread Thomas Mueller
I tried the patch on 9.2-STABLE, rebuilt the kernel and modules, installed to 
the correct place on USB stick, 
/media/zip0/boot/kernelre
USB stick was mounted on /media/zip0 when I did this.

Then I umounted, took the USB stick to new computer with MSI Z77 MPOWER 
motherboard.

I booted that USB stick, escaped to loader prompt, unload and
boot /boot/kernelre/kernel

got the same error when running dhclient re0.

Now I also have to update NetBSD-current and then build a Linux installation.

Linux may offer a better chance of configuring wireless adapters.

I was hoping a fix to the re(4) bug could make it for FreeBSD 10.0-RELEASE but 
am not betting on it.


Tom

___
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 failure with Realtek 8111E Ethernet on new MSI motherboard

2013-11-05 Thread Yonghyeon PYUN
On Wed, Nov 06, 2013 at 02:36:07AM +, Thomas Mueller wrote:
 from Yonghyeon PYUN:
 
Thomas, would you try attached patch on your system?


[-- Attachment #2: re.8168evl.diff --]
[-- Type: text/x-diff, Encoding: 7bit, Size: 3.6K --]
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename=re.8168evl.diff

Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c  (revision 257422)
+++ sys/dev/re/if_re.c  (working copy)
@@ -295,6 +295,8 @@
 static int re_miibus_writereg  (device_t, int, int, int);
 static void re_miibus_statchg  (device_t);

+static void re_eri_write   (struct rl_softc *, bus_size_t, uint32_t, 
 int);
+
 static void re_set_jumbo   (struct rl_softc *, int);
 static void re_set_rxmode  (struct rl_softc *);
 static void re_reset   (struct rl_softc *);
@:10,32s/^/@ -641,6 +643,32 @@
 }
 (snip)
 
 Which version/branch of FreeBSD is this for?  
 

I guess the diff would apply to CURRENT and any stable.

 9.2_STABLE, 10-stable or 11-head?
 
 Does it require a specific svn revision?
 

No.

 I just updated FreeBSD-current on new MSI motherboard (svn revision 257695).
 
 dhclient re0 still gives same error.
 

That's expected behavior since there is no code to activate the
workaround at this moment.  Given that you have CURRENT at this
moment, apply the diff and let me know  how it goes.

 Now I have to update FreeBSD-current amd64 on same computer.
 
 I go through this in the hope of being able to configure wifi with Hiro 50191 
 USB-stick-type WLAN adapter, driver rsu.
 
 So far, can't see wifi network.  I see what more I need to do, or maybe no 
 wifi signal?
 

Sorry, I'm dumb on wireless drivers so have nothing to comment. :-(

 Tom
 
___
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: send_packet: No buffer space available

2013-11-01 Thread hiren panchasara
On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz g...@unixarea.de wrote:


 Hello,

 Since I have updated my netbook to r255948 I see from time to time in
 the console the message:

 Nov  1 16:20:28 tiny-r255948 dhclient[696]: send_packet: No buffer space 
 available

Yes, this is a knownish issue which doesn't _seem_ to cause any other
side-effects but its getting annoying now. I also see a lot of them
lately.

I do not think this has been tracked down yet.

Cheers,
Hiren
___
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: send_packet: No buffer space available

2013-11-01 Thread Adrian Chadd
On 1 November 2013 08:45, hiren panchasara hiren.panchas...@gmail.com wrote:
 On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz g...@unixarea.de wrote:


 Hello,

 Since I have updated my netbook to r255948 I see from time to time in
 the console the message:

 Nov  1 16:20:28 tiny-r255948 dhclient[696]: send_packet: No buffer space 
 available

 Yes, this is a knownish issue which doesn't _seem_ to cause any other
 side-effects but its getting annoying now. I also see a lot of them
 lately.

 I do not think this has been tracked down yet.


Well, the first thing to establish is whether it's occuring in
net80211 or the driver. I _think_ it's a net80211 problem, where
dhclient is sending a frame to an interface that isn't yet ready. It's
yet another race condition that I must've uncovered when I made the
switch to if_transmit() in net80211.

Yes, I'd love it if someone looked into it for me. :)



-adrian
___
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 ?

2012-08-23 Thread John Baldwin
On Wednesday, August 22, 2012 9:35:34 pm Peter Jeremy wrote:
 BTW to jhb: Can you check your mailer's list configuration.  You
 appear to be adding freebsd-current@freebsd.org and leaving
 curr...@freebsd.org in the Cc list.

It's a feature of kmail that the kmail developers refuse to provide
an option to disable.  (It's due to the List-ID for our lists being
freebsd-foo@, but the common usage of the lists being foo@.  I
usually remove the foo@ when replying, but sometimes miss it.)

-- 
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: dhclient cause up/down cycle after 239356 ?

2012-08-23 Thread John Baldwin
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 events if they occur with 5 seconds of the link down event.  The 5 is
 hardcoded which is kind of yuck.
 
 I'm also a bit concerned about this for similar reasons to adrian@.
 We need to distinguish between short link outages caused by (eg) a
 switch admin reconfiguring the switch (which needs the lease to be
 re-checked) and those caused by broken NICs which report link status
 changes when they are touched.  Maybe an alternative is to just ignore
 link flaps when they occur within a few seconds of a script_go().
 (And/or make the ignore timeout configurable).
 
 Apart from fxp(4), does anyone know how many NICs are similarly
 broken?
 
 Does anyone know why this issue doesn't bite OpenBSD?  Does it have
 a work-around to avoid resetting the link, not report link status
 changes or just no-one has noticed the issue?

To be clear, I don't like this hack.  If there is a way to fix this in
the driver (e.g. not report the link state changes during a reset) that
would be far preferable.

-- 
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: dhclient cause up/down cycle after 239356 ?

2012-08-22 Thread Vitalij Satanivskij
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 dhclient: New Routers (fxp0): xx.xx.xx.1
Aug 22 20:06:50 home kernel: fxp0: link state changed to UP
Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:06:55 home kernel: fxp0: link state changed to UP
Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:03 home kernel: fxp0: link state changed to UP
Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:09 home kernel: fxp0: link state changed to UP
Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:15 home kernel: fxp0: link state changed to UP


ifconfig show that iface doesn't loose ip adress but, link realy loosed (for 
example 10 from icmp pachets cannot reach destination)

Yes, my problem easy fixed by changed ethernet card to em, but there are meny 
motherboard with integrated ether's...


YongHyeon PYUN wrote:
YP On Wed, Aug 22, 2012 at 08:27:01AM +1000, Peter Jeremy wrote:
YP  On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij sa...@ukr.net wrote:
YP  Look's like dhclient do down/up sequence -
YP  
YP  Not intentionally.
YP  
YP  Aug 21 19:21:00 home kernel: fxp0: link state changed to UP
YP  Aug 21 19:21:01 home kernel: fxp0: link state changed to DOWN
YP  Aug 21 19:21:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
YP  Aug 21 19:21:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
YP  Aug 21 19:21:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.xx
YP  Aug 21 19:21:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
YP  Aug 21 19:21:03 home kernel: fxp0: link state changed to UP
YP  
YP  I can reproduce this behaviour - but only on fxp (i82559 in my case)
YP  NICs.  My bge (BCM5750) and rl (RTL8139) NICs do not report the
YP  spurious DOWN/UP.  (I don't normally run DHCP on any fxp interfaces,
YP  so I didn't see it during my testing).
YP  
YP  The problem appears to be the 
YP$IFCONFIG $interface inet alias 0.0.0.0 netmask 255.0.0.0 broadcast 
255.255.255.255 up
YP  executed by /sbin/dhclient-script during PREINIT.  This is making the
YP  fxp NIC reset the link (actually, assigning _any_ IP address to an fxp
YP  NIC causes it to reset the link).  The post r239356 dhclient detects
YP 
YP This comes from the hardware limitation. Assigning addresses will
YP result in programming multicast filter and fxp(4) controllers
YP require full controller reset to reprogram the multicast filter.
YP 
YP  the link going down and exits.
YP  
YP  Before r239356 iface just doing down/up without dhclient exit and
YP  everything work fine.
YP  
YP  For you, anyway.  Failing to detect link down causes problems for me
YP  because my dhclient was not seeing my cable-modem resets and therefore
YP  failing to reacquire a DHCP lease.
YP  
YP  -- 
YP  Peter Jeremy
YP 
YP 
YP ___
YP freebsd-current@freebsd.org mailing list
YP http://lists.freebsd.org/mailman/listinfo/freebsd-current
YP 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 ?

2012-08-22 Thread John Baldwin
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: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:06:48 home dhclient: New Routers (fxp0): xx.xx.xx.1
 Aug 22 20:06:50 home kernel: fxp0: link state changed to UP
 Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
 Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN
 Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
 Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx
 Aug 22 20:06:55 home kernel: fxp0: link state changed to UP
 Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
 Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN
 Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
 Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
 Aug 22 20:07:03 home kernel: fxp0: link state changed to UP
 Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
 Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN
 Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
 Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx
 Aug 22 20:07:09 home kernel: fxp0: link state changed to UP
 Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
 Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN
 Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
 Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx
 Aug 22 20:07:15 home kernel: fxp0: link state changed to UP

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
hardcoded which is kind of yuck.

Index: dhcpd.h
===
--- dhcpd.h (revision 239564)
+++ dhcpd.h (working copy)
@@ -209,6 +209,7 @@
int  dead;
u_int16_tindex;
int  linkstat;
+   time_t   linktime;
 };
 
 struct timeout {
Index: dhclient.c
===
--- dhclient.c  (revision 239564)
+++ dhclient.c  (working copy)
@@ -285,8 +285,14 @@
ifi-linkstat ? up : down,
linkstat ? up : down);
ifi-linkstat = linkstat;
-   if (linkstat)
+
+   /*
+* XXX: Hardcoded 5 second grace window on
+* link flaps.
+*/
+   if (linkstat  (cur_time - ifi-linktime) = 5)
state_reboot(ifi);
+   ifi-linktime = cur_time;
}
break;
case RTM_IFANNOUNCE:
@@ -441,6 +447,7 @@
fprintf(stderr,  got link\n);
}
ifi-linkstat = 1;
+   ifi-linktime = cur_time;
 
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: dhclient cause up/down cycle after 239356 ?

2012-08-22 Thread Adrian Chadd
Ew. Be careful. Your admin may decide to change the VLAN you're on
(for example.) You definitely want to renegotiate your link state
then.



Adrian

On 22 August 2012 12:35, John Baldwin j...@freebsd.org wrote:
 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: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:06:48 home dhclient: New Routers (fxp0): xx.xx.xx.1
 Aug 22 20:06:50 home kernel: fxp0: link state changed to UP
 Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
 Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN
 Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
 Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx
 Aug 22 20:06:55 home kernel: fxp0: link state changed to UP
 Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
 Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN
 Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
 Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
 Aug 22 20:07:03 home kernel: fxp0: link state changed to UP
 Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
 Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN
 Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
 Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx
 Aug 22 20:07:09 home kernel: fxp0: link state changed to UP
 Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
 Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN
 Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
 Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
 Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx
 Aug 22 20:07:15 home kernel: fxp0: link state changed to UP

 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
 hardcoded which is kind of yuck.

 Index: dhcpd.h
 ===
 --- dhcpd.h (revision 239564)
 +++ dhcpd.h (working copy)
 @@ -209,6 +209,7 @@
 int  dead;
 u_int16_tindex;
 int  linkstat;
 +   time_t   linktime;
  };

  struct timeout {
 Index: dhclient.c
 ===
 --- dhclient.c  (revision 239564)
 +++ dhclient.c  (working copy)
 @@ -285,8 +285,14 @@
 ifi-linkstat ? up : down,
 linkstat ? up : down);
 ifi-linkstat = linkstat;
 -   if (linkstat)
 +
 +   /*
 +* XXX: Hardcoded 5 second grace window on
 +* link flaps.
 +*/
 +   if (linkstat  (cur_time - ifi-linktime) = 5)
 state_reboot(ifi);
 +   ifi-linktime = cur_time;
 }
 break;
 case RTM_IFANNOUNCE:
 @@ -441,6 +447,7 @@
 fprintf(stderr,  got link\n);
 }
 ifi-linkstat = 1;
 +   ifi-linktime = cur_time;

 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 ?

2012-08-22 Thread Peter Jeremy
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
hardcoded which is kind of yuck.

I'm also a bit concerned about this for similar reasons to adrian@.
We need to distinguish between short link outages caused by (eg) a
switch admin reconfiguring the switch (which needs the lease to be
re-checked) and those caused by broken NICs which report link status
changes when they are touched.  Maybe an alternative is to just ignore
link flaps when they occur within a few seconds of a script_go().
(And/or make the ignore timeout configurable).

Apart from fxp(4), does anyone know how many NICs are similarly
broken?

Does anyone know why this issue doesn't bite OpenBSD?  Does it have
a work-around to avoid resetting the link, not report link status
changes or just no-one has noticed the issue?

BTW to jhb: Can you check your mailer's list configuration.  You
appear to be adding freebsd-current@freebsd.org and leaving
curr...@freebsd.org in the Cc list.

-- 
Peter Jeremy


pgp9SoqeQglFI.pgp
Description: PGP signature


Re: dhclient cause up/down cycle after 239356 ?

2012-08-22 Thread Warner Losh

On Aug 22, 2012, at 7:35 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 events if they occur with 5 seconds of the link down event.  The 5 is
 hardcoded which is kind of yuck.
 
 I'm also a bit concerned about this for similar reasons to adrian@.
 We need to distinguish between short link outages caused by (eg) a
 switch admin reconfiguring the switch (which needs the lease to be
 re-checked) and those caused by broken NICs which report link status
 changes when they are touched.  Maybe an alternative is to just ignore
 link flaps when they occur within a few seconds of a script_go().
 (And/or make the ignore timeout configurable).
 
 Apart from fxp(4), does anyone know how many NICs are similarly
 broken?
 
 Does anyone know why this issue doesn't bite OpenBSD?  Does it have
 a work-around to avoid resetting the link, not report link status
 changes or just no-one has noticed the issue?

Speaking of fxp(4), can't it defer reporting link status changes during the 
reset 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
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: dhclient cause up/down cycle after 239356 ?

2012-08-22 Thread YongHyeon PYUN
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 events if they occur with 5 seconds of the link down event.  The 5 is
 hardcoded which is kind of yuck.
 
 I'm also a bit concerned about this for similar reasons to adrian@.
 We need to distinguish between short link outages caused by (eg) a
 switch admin reconfiguring the switch (which needs the lease to be
 re-checked) and those caused by broken NICs which report link status
 changes when they are touched.  Maybe an alternative is to just ignore
 link flaps when they occur within a few seconds of a script_go().
 (And/or make the ignore timeout configurable).
 
 Apart from fxp(4), does anyone know how many NICs are similarly
 broken?

FreeBSD used to blindly call driver's if_init() in ether_ioctl()
whenever an IP address is assigned to interface.  This results in
calling foo_init in a driver such that controller/link reset
happens after IP address assignment.  I tried to fix many ethernet
drivers in tree to ignore redundant foo_init() call by checking
whether this foo_init() call is the very first time initialization
of interface. Both NetBSD/OpenBSD seems to not call if_init() if
the driver is already running. Because some controllers(e.g.
fxp(4)) may require full controller reset to make multicast work,
I couldn't follow their approach. I still don't know what other
drivers except fxp(4) require full controller reset.  There are too
many old ethernet drivers I don't have access.
Another reason why fxp(4) requires redundant controller reset is
flow control support of the driver. Due to hardware limitation, MAC
configuration for negotiated link's flow control parameters also
requires controller reset.

 
 Does anyone know why this issue doesn't bite OpenBSD?  Does it have

I guess OpenBSD's fxp(4) has to reset controller to update
multicast filter but it does not support flow control for fxp(4)
yet so OpenBSD may see less number of link flips than that of
FreeBSD.

 a work-around to avoid resetting the link, not report link status
 changes or just no-one has noticed the issue?
 
 BTW to jhb: Can you check your mailer's list configuration.  You
 appear to be adding freebsd-current@freebsd.org and leaving
 curr...@freebsd.org in the Cc list.
 
 -- 
 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: dhclient cause up/down cycle after 239356 ?

2012-08-21 Thread Garrett Cooper
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


Re: dhclient cause up/down cycle after 239356 ?

2012-08-21 Thread Vitalij Satanivskij

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: dhclient cause up/down cycle after 239356 ?

2012-08-21 Thread Peter Jeremy
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: dhclient cause up/down cycle after 239356 ?

2012-08-21 Thread YongHyeon PYUN
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: dhclient em0: not found rev r230054

2012-01-17 Thread Gleb Smirnoff
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 root@freebsd:/usr/obj/usr/head/sys/GENERIC
O i386
O 
O [root@freebsd ~]# cat /var/log/messages | grep em0 | tail -n 6
O Jan 13 14:41:11 freebsd kernel: em0: Intel(R) PRO/1000 Network
O Connection 7.3.2 port 0x1820-0x183f mem
O 0xf030-0xf031,0xf0325000-0xf0325fff irq 23 at device 25.0 on
O pci0
O Jan 13 14:41:11 freebsd kernel: em0: Using an MSI interrupt
O Jan 13 14:41:11 freebsd kernel: em0: Ethernet address: 00:19:99:40:76:ee
O Jan 13 14:41:12 freebsd kernel: em0: link state changed to UP
O Jan 13 14:41:58 freebsd dhclient[1734]: em0: not found
O 
O [root@freebsd ~]# dhclient em0
O ifconfig: ioctl (SIOCAIFADDR): File exists
O em0: not found
O exiting.
O 
O Do you know how can I fix this problem?

Did you upgrade your world together with the kernel?

Can you show:

#ident /sbin/dhclient-script

-- 
Totus tuus, Glebius.
___
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 em0: not found rev r230054

2012-01-17 Thread Doug Barton
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 it haven't appeared
yet.

After you do this upgrade together it'll be safe to resume using the
normal 2-stage upgrade method.


Doug

-- 

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
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 em0: not found rev r230054

2012-01-17 Thread David Wolfskill
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@freebsd:/usr/obj/usr/head/sys/GENERIC
 i386
 
 [root@freebsd ~]# cat /var/log/messages | grep em0 | tail -n 6
 Jan 13 14:41:11 freebsd kernel: em0: Intel(R) PRO/1000 Network
 Connection 7.3.2 port 0x1820-0x183f mem
 0xf030-0xf031,0xf0325000-0xf0325fff irq 23 at device 25.0 on
 pci0
 Jan 13 14:41:11 freebsd kernel: em0: Using an MSI interrupt
 Jan 13 14:41:11 freebsd kernel: em0: Ethernet address: 00:19:99:40:76:ee
 Jan 13 14:41:12 freebsd kernel: em0: link state changed to UP
 Jan 13 14:41:58 freebsd dhclient[1734]: em0: not found
 ...

I'm not seeing the above.  I don't often have occasion to use em0
while running CURRENT, but today I do, running current at r230212M
(building CURRENT at r230063):

d134(10.0-C)[4] uname -a
FreeBSD d134.dwolf.example.net. 10.0-CURRENT FreeBSD 10.0-CURRENT #445 230212M: 
Mon Jan 16 05:31:35 PST 2012 
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386
d134(10.0-C)[5] grep -Jw em0 /var/run/dmesg.boot 
em0: Intel(R) PRO/1000 Network Connection 7.3.2 port 0xefe0-0xefff mem 
0xf6fe-0xf6ff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0
em0: Using an MSI interrupt
em0: Ethernet address: 00:24:e8:9c:11:0f
d134(10.0-C)[6] grep -Jw em0 /var/log/messages.0.bz2 | tail -12
Jan 17 10:54:39 localhost dhclient: New Broadcast Address (em0): 192.168.7.255
Jan 17 10:54:39 localhost dhclient: New Routers (em0): 192.168.7.1
Jan 17 10:57:10 localhost kernel: em0: Intel(R) PRO/1000 Network Connection 
7.3.2 port 0xefe0-0xefff mem 0xf6fe-0xf6ff,0xf6fdb000-0xf6fdbfff irq 
22 at device 25.0 on pci0
Jan 17 10:57:10 localhost kernel: em0: Using an MSI interrupt
Jan 17 10:57:10 localhost kernel: em0: Ethernet address: 00:24:e8:9c:11:0f
Jan 17 10:57:14 localhost kernel: em0: link state changed to DOWN
Jan 17 10:57:16 localhost kernel: em0: link state changed to UP
Jan 17 10:57:16 localhost dhclient: New Hostname (em0): 
Jan 17 10:57:16 localhost dhclient: New IP Address (em0): 192.168.7.134
Jan 17 10:57:16 localhost dhclient: New Subnet Mask (em0): 255.255.255.0
Jan 17 10:57:16 localhost dhclient: New Broadcast Address (em0): 192.168.7.255
Jan 17 10:57:16 localhost dhclient: New Routers (em0): 192.168.7.1
d134(10.0-C)[7] 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpKfGtoZf6Tr.pgp
Description: PGP signature


Re: dhclient/ipfw conflict on boot

2003-09-25 Thread Conrad J. Sabatier
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 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 
 unable to communicate with my ISP's DHCP server.
 
 This should be a quick and easy fix, right?  :-)
 
 Well, my approach to a quick and easy fix is Don't do that.
 
 For my laptop, I set up an ipfw specification that, on boot, only
 permitted DHCP traffic.
 
 Then in /etc/dhclient-exit-hooks, once I've got a lease, I invoke a
 different script that flushes the old rules and creates a new set, based
 on such things as my new IP address and the address of the DHCP server.
 
 Also in /etc/dhclient-exit-hooks, if it's invoked when dhclient is
 exiting (leaving the network), the script re-invokes the default ipfw
 script.

Interesting.  I'll have to setup something like that here.

I was hoping that maybe it was because I had been forcing the ipfw module to 
load from /boot/loader.conf.  But disabling that didn't help.  :-(

-- 
Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/ipfw conflict on boot

2003-09-24 Thread David Wolfskill
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 
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 
unable to communicate with my ISP's DHCP server.

This should be a quick and easy fix, right?  :-)

Well, my approach to a quick and easy fix is Don't do that.

For my laptop, I set up an ipfw specification that, on boot, only
permitted DHCP traffic.

Then in /etc/dhclient-exit-hooks, once I've got a lease, I invoke a
different script that flushes the old rules and creates a new set, based
on such things as my new IP address and the address of the DHCP server.

Also in /etc/dhclient-exit-hooks, if it's invoked when dhclient is
exiting (leaving the network), the script re-invokes the default ipfw
script.

Peace,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
If you want true virus-protection for your PC, install a non-Microsoft OS
on it.  Plausible candidates include FreeBSD, Linux, NetBSD, OpenBSD, and
Solaris (in alphabetical order).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient bug

2003-09-09 Thread Martin Blapp

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 isc-dhcp people?


This is a FreeBSD bug, I'll fix it later today.

Martin

Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP  ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-14 Thread Martin Blapp

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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-14 Thread Matthew N. Dodd
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  28 Jul 2003 13:25:04 -  1.27
+++ dhclient.c  9 Aug 2003 13:07:16 -
@@ -3221,13 +3221,11 @@
if (ifmr.ifm_status  IFM_ACTIVE)
return (1);
}
+   return (0);
}

-   return (0);
-#else /* ifdef __FreeBSD__ */
-
-   return (1);
 #endif /* Other OSs */
+   return (1);
 }

 #ifdef __FreeBSD__
%%%


-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-14 Thread Matthew N. Dodd
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 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
doesn't support reporting media status then we shouldn't do anything with
the status word.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Dhclient fix for systems with media settings

2003-08-14 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Martin Blapp [EMAIL PROTECTED] writes:
:  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 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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-14 Thread Martin Blapp

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);
}
}
+   /*
+* If dhclient.conf contains media settings, we cannot
+* abort if the interface is not set to active mode.
+*/
+   if (ip - havemedia  ip - client - state != S_BOUND)
+   return (HAVELINK);
+   } else {
+   /*
+* IFM_AVALID is not set. We cannot check
+* the link state. Assume HAVELINK.
+*/
+   return (HAVELINK);
}
-
-   /*
-* If dhclient.conf contains media settings, we cannot
-* abort if the interface is not set to active mode.
-*/
-   if (ip - havemedia  ip - client - state != S_BOUND)
-   return (HAVELINK);
-
/*
 * We really have no link.
 */
return (NOLINK);
+
 #else /* ifdef __FreeBSD__ */

/*
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-14 Thread Martin Blapp

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
diff -u -r1.30 dhclient.c
--- client/dhclient.c   7 Aug 2003 14:58:46 -   1.30
+++ client/dhclient.c   9 Aug 2003 16:20:22 -
@@ -3288,19 +3288,21 @@
return (HAVELINK);
}
}
-   }

-   /*
-* If dhclient.conf contains media settings, we cannot
-* abort if the interface is not set to active mode.
-*/
-   if (ip - havemedia  ip - client - state != S_BOUND)
-   return (HAVELINK);
+   /*
+* If dhclient.conf contains media settings, we cannot
+* abort if the interface is not set to active mode.
+*/
+   if (ip - havemedia  ip - client - state != S_BOUND)
+   return (HAVELINK);

-   /*
-* We really have no link.
-*/
-   return (NOLINK);
+   /*
+* We really have no link.
+*/
+   return (NOLINK);
+   }
+
+   return (HAVELINK);
 #else /* ifdef __FreeBSD__ */

/*
@@ -3310,6 +3312,7 @@
return (HAVELINK);
 #endif /* Other OSs */
 }
+

 #ifdef __FreeBSD__
 void

Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP  ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-14 Thread Matthew N. Dodd
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

Try this (cut  paste):
%%%
Index: if_xl.c
===
RCS file: /cvs/src/sys/pci/if_xl.c,v
retrieving revision 1.150
diff -u -u -r1.150 if_xl.c
--- if_xl.c 27 Jul 2003 13:56:03 -  1.150
+++ if_xl.c 4 Aug 2003 15:46:36 -
@@ -3031,6 +3031,10 @@
icfg = XL_ICFG_CONNECTOR_BITS;

ifmr-ifm_active = IFM_ETHER;
+   ifmr-ifm_status = IFM_AVALID;
+
+   if (!(CSR_READ_2(sc, XL_W4_MEDIA_STATUS)  XL_MEDIASTAT_CARRIER))
+   ifmr-ifm_status |= IFM_ACTIVE;

switch(icfg) {
case XL_XCVR_10BT:
%%%

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Dhclient fix for systems with media settings

2003-08-14 Thread Eirik Oeverby
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: device timeout
wi0: bad alloc 573 != 2a2, cur 0 nxt 0
wi0: device timeout

and

wi0: timeout in wi_seek to fc02/0
wi0: timeout in wi_seek to fc03/0

Pulling the card and re-inserting it + restarting dhclient will give me
a network link again for another few minutes, then the same story
happens again.

I have never seen this problem when using a static IP - my uptime is
currently well over a week and I haven't had to reconfigure once.

Hope this helps.

Best regards,
/Eirik


On Tue, 05 Aug 2003 08:56:38 -0600 (MDT)
M. Warner Losh [EMAIL PROTECTED] wrote:

 In message: [EMAIL PROTECTED]
 Martin Blapp [EMAIL PROTECTED] writes:
 :  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 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
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 [EMAIL PROTECTED]




pgp0.pgp
Description: PGP signature


Re: dhclient problem with xl0

2003-08-14 Thread Martin Blapp

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://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-14 Thread Craig Rodrigues
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 the kernel, powered down, rebooted, and things seem
to work better.

Before Matthew's patch, ifconfig xl0 would never print out
status:

Now, ifconfig xl0, *always* prints out:
status: no carrier

even if I do have carrier.

If I run dhclient (without your patch, but with debugging), I get:

===
Internet Software Consortium DHCP Client V3.0.1rc1
Copyright 1995-2002 Internet Software Consortium
All rights reserved
For info, please visit http://www.isc.org/products/DHCP

Listening on BPF/xl0/00:60:97:72:ad:f0
Sending on   BPF/xl0/00:60:97:72:ad:f0
Sending on   Socket/fallback
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: No Link on interface
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: No Link on interface
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: No Link on interface
===


Now, if I add the following lines to /etc/dhclient.conf (I've never
had to modify this file before):
 
interface xl0 {
   media autoselect;
}

I then get the following from dhclient:
===

Script started on Sat Aug  9 13:11:42 2003
Internet Software Consortium DHCP Client V3.0.1rc11
Copyright 1995-2002 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

Listening on BPF/xl0/00:60:97:72:ad:f0
Sending on   BPF/xl0/00:60:97:72:ad:f0
Sending on   Socket/fallback
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: Trying media settings on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 156736 seconds.
xl0: Polling interface state
xl0: client state of 5
xl0: link = 1
xl0: Lost Link on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 149325 seconds.
xl0: Polling interface state
xl0: client state of 5
xl0: link = 1
xl0: Lost Link on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 158190 seconds.
xl0: Polling interface state
xl0: client state of 5
xl0: link = 1
xl0: Lost Link on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 144066 seconds.
xl0: Polling interface state
xl0: client state of 5
xl0: link = 1
xl0: Lost Link on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 156702 seconds.
===


Note, now that I am online, if I do ifconfig xl0, I get the following:

xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
inet6 fe80::260:97ff:fe72:adf0%xl0 prefixlen 64 scopeid 0x2 
inet 66.31.45.197 netmask 0xf800 broadcast 255.255.255.255
ether 00:60:97:72:ad:f0
media: Ethernet 10baseT/UTP (10baseT/UTP half-duplex)
status: no carrier


So it looks like maybe there is a problem with the xl driver?
(Note I am running with Matthew Dodd's patch).

It would be nice to get this to work so that I don't have to
edit /etc/dhclient.conf, since I never had to do it before.

-- 
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-14 Thread Martin Blapp

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 unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Dhclient fix for systems with media settings

2003-08-11 Thread Eirik Oeverby
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 for the efforts =)

/Eirik

On Tue, 5 Aug 2003 10:45:18 +0200 (CEST)
Martin Blapp [EMAIL PROTECTED] wrote:

 
 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, and also adapt the patch
 to the ISC style, so it can be submitted again.
 
 --- src/contrib/isc-dhcp/includes/dhcpd.h.origMon Aug  4 23:57:06 2003
 +++ src/contrib/isc-dhcp/includes/dhcpd.h Mon Aug  4 23:57:37 2003
 @@ -782,6 +782,7 @@
   char name [IFNAMSIZ];   /* Its name... */
   int linkstatus; /* Link status */
   int ieee802;/* True if media is ieee802 */
 + int mediaflag;  /* True if dhclient.conf has media settings */
   int index;  /* Its index. */
   int rfdesc; /* Its read file descriptor. */
   int wfdesc; /* Its write file descriptor, if
 --- src/contrib/isc-dhcp/client/dhclient.c.orig   Tue Aug  5 00:42:37 2003
 +++ src/contrib/isc-dhcp/client/dhclient.cTue Aug  5 10:01:17 2003
 @@ -257,7 +257,9 @@
   log_fatal (%s: interface name too long (max %ld),
  argv [i], (long)strlen (argv [i]));
   strlcpy (tmp - name, argv [i], IFNAMSIZ);
 - set_ieee802(tmp);
 +#ifdef __FreeBSD__
 + set_ieee80211(tmp);
 +#endif
   tmp-linkstatus = interface_active(tmp);
   if (interfaces) {
   interface_reference (tmp - next,
 @@ -412,7 +414,16 @@
INTERFACE_AUTOMATIC)) !=
INTERFACE_REQUESTED))
   continue;
 - set_ieee802(ip);
 +#ifdef __FreeBSD__
 + set_ieee80211(ip);
 +#endif
 +#ifdef ENABLE_POLLING_MODE
 + if (ip - client - config - media != NULL)
 + ip-mediaflag = 1;
 + else
 + ip-mediaflag = 0;
 +#endif /* ifdef ENABLE_POLLING_MODE */
 +
   script_init (ip - client,
PREINIT, (struct string_list *)0);
   if (ip - client - alias)
 @@ -1385,9 +1396,6 @@
   int interval;
   int increase = 1;
 
 - if (interface_active(client - interface) == 0)
 - return;
 -
   /* Figure out how long it's been since we started transmitting.
   */ interval = cur_time - client - first_sending;
 
 @@ -1427,6 +1435,9 @@
   }
   }
 
 + if (interface_active(client - interface) == 0)
 + return;
 +
   /* If we're supposed to increase the interval, do so.  If it's
  currently zero (i.e., we haven't sent any packets yet), set
  it to one; otherwise, add to it a random number between
 @@ -3215,14 +3226,29 @@
   if (ifmr.ifm_status  IFM_AVALID) {
   if (ip-ieee802) {
   if ((IFM_TYPE(ifmr.ifm_active) == IFM_IEEE80211) 
 -  (ifmr.ifm_status  IFM_ACTIVE))
 +  (ifmr.ifm_status  IFM_ACTIVE)) {
 + if (ip-mediaflag 
 + ip - client - state != S_BOUND)
 + return (2);
   return (1);
 + }
   } else {
 - if (ifmr.ifm_status  IFM_ACTIVE)
 + if (ifmr.ifm_status  IFM_ACTIVE) {
 + if (ip-mediaflag 
 + ip - client - state != S_BOUND)
 + return (2);
   return (1);
 + }
   }
   }
 
 + /*
 +  * If dhclient.conf contains media settings, we cannot
 +  * abort if the interface is not set to active mode.
 +  */
 + if (ip-mediaflag  ip - client - state != S_BOUND)
 + return (1);
 +
   return (0);
  #else /* ifdef __FreeBSD__ */
 
 @@ -3231,7 +3257,7 @@
  }
 
  #ifdef __FreeBSD__
 -set_ieee802 (struct interface_info *ip) {
 +set_ieee80211 (struct interface_info *ip) {
 
   struct ieee80211req ireq;
   u_int8_tdata[32];
 @@ -3267,12 +3293,20 @@
  #endif /* __FreeBSD__ */
 
  #ifdef ENABLE_POLLING_MODE
 +/* Go to background after some time */
 +void state_background (cpp)
 

Re: dhclient problem with xl0

2003-08-10 Thread Matthew N. Dodd
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 the link status for cards
with builtin non-MII PHYs.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-10 Thread Martin Blapp

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
 doesn't support reporting media status then we shouldn't do anything with
 the status word.

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.

Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-10 Thread Martin Blapp

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 status for cards
 with builtin non-MII PHYs.

Ok. Thank you very much !

Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-09 Thread Matthew N. Dodd
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 | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient problem with xl0

2003-08-09 Thread Craig Rodrigues
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 a interface define in /etc/dhclient.conf
 wit the possible media.

Hmmm, I am not sure about this, since if I use the old dhclient
binary, it works fine without problems.  Here is the output
if 'ifconfig xl0':


xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
inet6 fe80::260:97ff:fe72:adf0%xl0 prefixlen 64 scopeid 0x2 
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
ether 00:60:97:72:ad:f0
media: Ethernet 10baseT/UTP (10baseT/UTP half-duplex)

-- 
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Dhclient fix for systems with media settings

2003-08-06 Thread Martin Blapp

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 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.

Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Martin Blapp

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 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 help to compile dhclient with -DDEBUG and see if you get more information.

Martin

Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP  ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Matthew N. Dodd
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 media settings.

As I've explained in private email using the ifm_status word to determine
if the interface is up and running is incorrect.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Larry Rosenman


--On Monday, August 04, 2003 10:09:34 -0500 Larry Rosenman [EMAIL PROTECTED] 
wrote:



--On Monday, August 04, 2003 16:42:08 +0200 Martin Blapp [EMAIL PROTECTED]
wrote:
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 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 help to compile dhclient with -DDEBUG and see if you get
more information.
I'll have to get more information.  I stopped/restarted dhclient with the
-d -v, and it didn't echo the medium lines on the reinsert/restart.
It did echo the right medium line on the plain restart.  script attached.

I'll have to check it when I switch locations tonite.

What else can I get meantime?
re-sent with file inline, since freebsd.org has gotten so anal about 
attachments:

Script started on Mon Aug  4 10:04:35 2003
lerlaptop-red# dhclient
?[Klerlaptop-red# ps ax|grep dhc

 716  ??  Ss 0:00.19 dhclient wi0
1374  v0  S+ 0:00.01 script dhclient.script
lerlaptop-red# kill 716
lerlaptop-red# dhclient -d -v wi0

Internet Software Consortium DHCP Client V3.0.1rc11
Copyright 1995-2002 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Listening on BPF/wi0/00:06:25:18:1a:37
Sending on   BPF/wi0/00:06:25:18:1a:37
Sending on   Socket/fallback
Trying medium 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

lerlaptop-red# ifconfig

rl0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
ether 00:e0:00:7e:d0:45
media: Ethernet autoselect (10baseT/UTP)
status: no carrier
fwe0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
ether 02:00:0e:70:a8:72
ch 1 dma -1
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet6 fe80::206:25ff:fe18:1a37%wi0 prefixlen 64 scopeid 0x4
inet 207.136.3.72 netmask 0xff00 broadcast 207.136.3.255
ether 00:06:25:18:1a:37
media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
status: associated
ssid rednet 1:rednet
stationname FreeBSD WaveLAN/IEEE node
channel 9 authmode OPEN powersavemode OFF powersavesleep 100
wepmode OFF weptxkey 1
lerlaptop-red# if]]??[K??[K??[K??[Kkillall dhclient
No matching processes were found
lerlaptop-red# if
if: Too few arguments.
lerlaptop-red# ifcofig??[K??[K??[Kni??[Kfig
rl0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
ether 00:e0:00:7e:d0:45
media: Ethernet autoselect (10baseT/UTP)
status: no carrier
fwe0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
ether 02:00:0e:70:a8:72
ch 1 dma -1
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
lerlaptop-red# ifconfig
rl0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
ether 00:e0:00:7e:d0:45
media: Ethernet autoselect (10baseT/UTP)
status: no carrier
fwe0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
ether 02:00:0e:70:a8:72
ch 1 dma -1
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
wi0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
ether 00:06:25:18:1a:37
media: IEEE 802.11 Wireless Ethernet autoselect (none)
ssid 
stationname FreeBSD WaveLAN/IEEE node
channel -1 authmode OPEN powersavemode OFF powersavesleep 100
wepmode OFF weptxkey 1
lerlaptop-red# dhclient -d -v wi0
Internet Software Consortium DHCP Client V3.0.1rc11
Copyright 1995-2002 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Listening on BPF/wi0/00:06:25:18:1a:37
Sending on   BPF/wi0/00:06:25:18:1a:37
Sending on   Socket/fallback
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPACK from 207.136.3.254
bound to 207.136.3.72 -- renewal in 7348 seconds.
^Z
Suspended
lerlaptop-red# bg
[1]dhclient -d -v wi0 
lerlaptop-red# ^D??exit
Script done on Mon Aug  4 10:06:26 2003



Martin

Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]

Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Larry Rosenman


--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.

dhclient.c:send_discover() bails out if interface_active() is false BEFORE
iterating all the possible media settings.
As I've explained in private email using the ifm_status word to determine
if the interface is up and running is incorrect.
Martin/Matthew,
   If you want me to test some code, I'm more than willing.  Having this 
broken is
annoying.

LER



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Martin Blapp

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 done like bevor.

It only returns 0, if

if (ifmr.ifm_status  IFM_AVALID) is not true.

Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Martin Blapp

hi,

 Listening on BPF/wi0/00:06:25:18:1a:37
 Sending on   BPF/wi0/00:06:25:18:1a:37
 Sending on   Socket/fallback
 Trying medium 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 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 and I'm sure
you'll see the same behaviour there.

See

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=161994+0+current/freebsd-current

Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Larry Rosenman


--On Monday, August 04, 2003 17:45:49 +0200 Martin Blapp [EMAIL PROTECTED] wrote:

hi,

Listening on BPF/wi0/00:06:25:18:1a:37
Sending on   BPF/wi0/00:06:25:18:1a:37
Sending on   Socket/fallback
Trying medium 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 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 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.

I STRONGLY disagree.


See

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=161994+0+current/freebsd-cur
rent
Martin


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Larry Rosenman


--On Monday, August 04, 2003 10:48:59 -0500 Larry Rosenman [EMAIL PROTECTED] 
wrote:



--On Monday, August 04, 2003 17:45:49 +0200 Martin Blapp [EMAIL PROTECTED]
wrote:
hi,

Listening on BPF/wi0/00:06:25:18:1a:37
Sending on   BPF/wi0/00:06:25:18:1a:37
Sending on   Socket/fallback
Trying medium 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 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 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.

I STRONGLY disagree.


See

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=161994+0+current/freebsd-cur
rent
Martin


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Martin Blapp

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 the first time you try, right ? What exactly
does not work then ? Renewing the lease, or just changeing the network ?

Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Larry Rosenman


--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 nite/this am.
oh, and 4.6-4.8 as well.
Ok,

You told me that it is working the first time you try, right ? What
exactly does not work then ? Renewing the lease, or just changeing the
network ?
Changing which network I'm on.  I.E. when I moved from my house ('LERCTR 
NETWORK') to
my office ('rednet'/'IA-01'), it didn't even TRY the rednet/IA-01 SSID's.

This USED TO WORK seamlessly prior to today's -CURRENT (from ~2 weeks ago 
-CURRENT).


Martin


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Martin Blapp

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. The problem is that you aren't associated
at the beginning, because the first wep-key is wrong. Before every key
was tried and one did match.

I do now know where the problem is.

I'll have a fix ASAP.

Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Larry Rosenman


--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 and vice versa.
SOMETHING seriously changed here.
Ahh ! I see now the change. The problem is that you aren't associated
at the beginning, because the first wep-key is wrong. Before every key
was tried and one did match.
I do now know where the problem is.
Actually I don't use WEP, but the SSID has the same effect in this case.

I'll have a fix ASAP.
Cool! :-)


Martin


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Martin Blapp

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
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT?

2003-08-04 Thread Martin Blapp

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 some work, but it should fix your case.
I'll fix the remaining issues tomorrow.

Martin

--- src/contrib/isc-dhcp/includes/dhcpd.h.orig  Mon Aug  4 23:57:06 2003
+++ src/contrib/isc-dhcp/includes/dhcpd.h   Mon Aug  4 23:57:37 2003
@@ -782,6 +782,7 @@
char name [IFNAMSIZ];   /* Its name... */
int linkstatus; /* Link status */
int ieee802;/* True if media is ieee802 */
+   int mediaflag;  /* True if dhclient.conf has media settings */
int index;  /* Its index. */
int rfdesc; /* Its read file descriptor. */
int wfdesc; /* Its write file descriptor, if
--- src/contrib/isc-dhcp/client/dhclient.c.orig Mon Jul 28 15:25:04 2003
+++ src/contrib/isc-dhcp/client/dhclient.c  Mon Aug  4 23:56:04 2003
@@ -413,6 +413,11 @@
 INTERFACE_REQUESTED))
continue;
set_ieee802(ip);
+   if (ip - client - config - media != NULL)
+   ip-mediaflag = 1;
+   else
+   ip-mediaflag = 0;
+
script_init (ip - client,
 PREINIT, (struct string_list *)0);
if (ip - client - alias)
@@ -1385,9 +1390,6 @@
int interval;
int increase = 1;

-   if (interface_active(client - interface) == 0)
-   return;
-
/* Figure out how long it's been since we started transmitting. */
interval = cur_time - client - first_sending;

@@ -1427,6 +1429,9 @@
}
}

+   if (interface_active(client - interface) == 0)
+   return;
+
/* If we're supposed to increase the interval, do so.  If it's
   currently zero (i.e., we haven't sent any packets yet), set
   it to one; otherwise, add to it a random number between
@@ -3222,6 +3227,13 @@
return (1);
}
}
+
+   /*
+* If dhclient.conf contains media settings, we cannot
+* abort if the interface is not set to active mode.
+*/
+   if (ip-mediaflag)
+   return (1);

return (0);
 #else /* ifdef __FreeBSD__ */

Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP  ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient/dhclient.conf change in -CURRENT? (fwd)

2003-08-04 Thread Larry Rosenman
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.  I did run it with -d -v and
got the following
Script started on Mon Aug  4 20:13:21 2003
lerlaptop# dhclient -d -v wi0
Internet Software Consortium DHCP Client V3.0.1rc11
Copyright 1995-2002 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Listening on BPF/wi0/00:06:25:18:1a:37
Sending on   BPF/wi0/00:06:25:18:1a:37
Sending on   Socket/fallback
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPREQUEST on wi0 to 255.255.255.255 port 67
Trying medium wepmode off ssid 'rednet' wepkey 1:- wepkey 2:- wepkey 3:-
wepkey 4:-  1 DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 6
Trying medium wepmode off ssid 'IA-01' wepkey 1:- wepkey 2:- wepkey 3:-
wepkey 4:- 0 DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 6
Trying medium wepmode off ssid 'LERCTR NETWORK' wepkey 1:- wepkey 2:-
wepkey 3:- wepkey 4:- 0 DHCPDISCOVER on wi0 to 255.255.255.255 port 67
interval 6
DHCPREQUEST on wi0 to 255.255.255.255 port 67
Trying medium 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
Trying medium wepmode off ssid 'IA-01' wepkey 1:- wepkey 2:- wepkey 3:-
wepkey 4:- 0 DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 3
Trying medium wepmode off ssid 'LERCTR NETWORK' wepkey 1:- wepkey 2:-
wepkey 3:- wepkey 4:- 0 DHCPDISCOVER on wi0 to 255.255.255.255 port 67
interval 3
DHCPREQUEST on wi0 to 255.255.255.255 port 67
Trying medium wepmode off ssid 'rednet' wepkey 1:- wepkey 2:- wepkey 3:-
wepkey 4:-  1 DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 9
DHCPREQUEST on wi0 to 255.255.255.255 port 67
Trying medium wepmode off ssid 'IA-01' wepkey 1:- wepkey 2:- wepkey 3:-
wepkey 4:- 0 DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 9
Trying medium wepmode off ssid 'LERCTR NETWORK' wepkey 1:- wepkey 2:-
wepkey 3:- wepkey 4:- 0 DHCPDISCOVER on wi0 to 255.255.255.255 port 67
interval 3
DHCPOFFER from 207.158.72.11
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPACK from 207.158.72.11
bound to 207.158.72.14 -- renewal in 1087437530 seconds.
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPACK from 207.158.72.11
^Z
Suspended
lerlaptop# bg
[1]dhclient -d -v wi0 
lerlaptop# ^D??exit
Script done on Mon Aug  4 20:15:28 2003

--On Tuesday, August 05, 2003 00:52:25 +0200 Martin Blapp [EMAIL PROTECTED] wrote:

Hi Larry,

And here is a more correct version. It still has some issues.

The sleep interval for dhclient after we lost a successful
link is too big.
Can you live with this solution ?

Martin

--- src/contrib/isc-dhcp/includes/dhcpd.h.orig  Mon Aug  4 23:57:06 2003
+++ src/contrib/isc-dhcp/includes/dhcpd.h   Mon Aug  4 23:57:37 2003
@@ -782,6 +782,7 @@
char name [IFNAMSIZ];   /* Its name... */
int linkstatus; /* Link status */
int ieee802;/* True if media is ieee802 */
+   int mediaflag;  /* True if dhclient.conf has media settings */
int index;  /* Its index. */
int rfdesc; /* Its read file descriptor. */
int wfdesc; /* Its write file descriptor, if
--- src/contrib/isc-dhcp/client/dhclient.c.orig Tue Aug  5 00:42:37 2003
+++ src/contrib/isc-dhcp/client/dhclient.c  Tue Aug  5 00:45:05 2003
@@ -257,7 +257,9 @@
log_fatal (%s: interface name too long (max %ld),
   argv [i], (long)strlen (argv [i]));
strlcpy (tmp - name, argv [i], IFNAMSIZ);
-   set_ieee802(tmp);
+#ifdef __FreeBSD__
+   set_ieee80211(tmp);
+#endif
tmp-linkstatus = interface_active(tmp);
if (interfaces) {
interface_reference (tmp - next,
@@ -412,7 +414,14 @@
 INTERFACE_AUTOMATIC)) !=
 INTERFACE_REQUESTED))
continue;
-   set_ieee802(ip);
+#ifdef __FreeBSD__
+   set_ieee80211(ip);
+#endif
+   if (ip - client - config - media != NULL)
+   ip-mediaflag = 1;
+   else
+   ip-mediaflag = 0;
+
script_init (ip - client,
 PREINIT, (struct string_list *)0);
if (ip - client - alias)
@@ -1385,9 +1394,6 @@
int interval;
int increase = 1;
-   if (interface_active(client - interface) == 0)
-   return

Re: dhclient script in rc.d doesn't use ${dhcp_program}(conf/53007)

2003-06-07 Thread Mike Makonnen
On Sat, 7 Jun 2003 03:18:18 -0600
John Nielsen [EMAIL PROTECTED] wrote:

 I just submitted a PR for a bug I noticed in the dhclient script.  Namely, 
 it ignores the setting of dhcp_program from rc.conf.  A one-line fix did 
 the trick for me, although there may be ramifications I'm not aware of.
 

hmm it looks like the bug is actually our name for the program. In the new rc
system there is glue code that automagically overides the command. But in order
for it to work the variable has to be named a certain way in rc.conf. In this
case the variable name is dhcp_program, but what it should really be is
dhclient_program.

This is another variable we're going to have to deprecate.
Thanks for reporting this!

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9
[EMAIL PROTECTED]| FreeBSD - The Power To Serve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dhclient in background?

2003-01-10 Thread Daniel O'Connor
On Fri, 2003-01-10 at 21:16, Dario Freni wrote:
 Hi everybody. I'm a developer of the FreeSBIE project (just another
 FreeBSD-on-a-live-cd project).
 As default network configuration, we've reasonally chosen a dhcp
 configuration, which is great on a dhcp network, but ugly when it has to
 wait for timeout.
 I also had the same problem with my mobile-pc, when it's not attached to
 my LAN.
 We could modify rc.network by adding a  to the dhclient row, but we are
 looking for a more efficient way.
 Can an optional flag be added (configurable in rc.conf)?

You could use the timeout option in dhclient.conf..

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient in background?

2003-01-10 Thread Ceri Davies
On Fri, Jan 10, 2003 at 11:13:34PM +1030, Daniel O'Connor wrote:
 On Fri, 2003-01-10 at 21:16, Dario Freni wrote:
  Hi everybody. I'm a developer of the FreeSBIE project (just another
  FreeBSD-on-a-live-cd project).
  As default network configuration, we've reasonally chosen a dhcp
  configuration, which is great on a dhcp network, but ugly when it has to
  wait for timeout.
  I also had the same problem with my mobile-pc, when it's not attached to
  my LAN.
  We could modify rc.network by adding a  to the dhclient row, but we are
  looking for a more efficient way.
  Can an optional flag be added (configurable in rc.conf)?
 
 You could use the timeout option in dhclient.conf..

I tried to send this privately, but got a bounce:

From man dhclient:

   The client can also be instructed to become a daemon imme-
   diately,  rather  than waiting until it has acquired an IP
   address.   This can be done by supplying the -nw flag.

Oh, this belongs on -questions, by the way.

Ceri
-- 
Demise before dishonor!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient in background?

2003-01-10 Thread Dario Freni
Reply to both and in ML

  You could use the timeout option in dhclient.conf..

IMHO it's a risk.
 
 From man dhclient:
 
The client can also be instructed to become a daemon imme-
diately,  rather  than waiting until it has acquired an IP
address.   This can be done by supplying the -nw flag.

Read -n explanation. We've just tried -nw and it didn't setup the
network interface

 Oh, this belongs on -questions, by the way.

No, mine was a request for feature, not (only) a support question.

Bye,
Dario

-- 
Dario Freni [EMAIL PROTECTED]
SaturNero @ IRCNet, Azzurra IRC Network
GPG Public key at http://www.saturnero.net/saturnero.asc



msg49944/pgp0.pgp
Description: PGP signature


Re: dhclient in background?

2003-01-10 Thread Ceri Davies
On Fri, Jan 10, 2003 at 03:03:57PM +0100, Dario Freni wrote:
 Reply to both and in ML
 
   You could use the timeout option in dhclient.conf..
 
 IMHO it's a risk.
  
  From man dhclient:
  
 The client can also be instructed to become a daemon imme-
 diately,  rather  than waiting until it has acquired an IP
 address.   This can be done by supplying the -nw flag.
 
 Read -n explanation. We've just tried -nw and it didn't setup the
 network interface

-n -w != -nw

  Oh, this belongs on -questions, by the way.
 
 No, mine was a request for feature, not (only) a support question.

Probably belongs on an ISC list then ;)

Ceri
-- 
From the mines of the greataxe I come!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient

2001-12-15 Thread PaZt

Sounds more like a non-reachable dhcp server

On Thu, 13 Dec 2001, Edwin Culp wrote:

 Is anyone using dhclient successfully with Current of the last week or so?
 I don't use it all the time but I have been trying for the last couple of
 days without success.  
 
 It accesses the server and changes the interface ip to 0.0.0.0 netmask
 255.255.255.255.
 
 Thanks,
 
 ce
 
 
 
 ---
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient

2001-12-14 Thread Robert Watson


On Thu, 13 Dec 2001, Edwin Culp wrote:

 Is anyone using dhclient successfully with Current of the last week or
 so?  I don't use it all the time but I have been trying for the last
 couple of days without success.
 
 It accesses the server and changes the interface ip to 0.0.0.0 netmask
 255.255.255.255. 

My -CURRENT dhclient is working just fine on several boxes from Dec 11,
12, and 13.  And I guess also 14, given the time :-).  As pointed out,
0.0.0.0 is what dhclient will set the interface IP address to when it
doesn't have a valid lease currently, and needs to look for one.  If it
fails to quickly find a lease, it keeps trying, but you actually get a
window to see this address on your interface, whereas if it runs quickly,
you often won't.

Using a packet sniffer can be invaluable in debugging DHCP problems: 
tcpdump udp port dhcpc or udp port dhcps is useful, but even better is
ethereal's ability to decode the DHCP packet in detail, display options
cleanly, etc.  You might want to try looking to make sure that you're
getting a response, and if you are, whether it looks adequate :-).

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient

2001-12-14 Thread Edwin Culp

Robert,

I got it working by adding a dhclient configuration file rather than using
the empty file that I have always used.  I'm not sure why but it works:-)
I'll break out ethereal a little later and see if I can figure it out.

Thanks,

ed

Quoting Robert Watson [EMAIL PROTECTED]:

 
 On Thu, 13 Dec 2001, Edwin Culp wrote:
 
  Is anyone using dhclient successfully with Current of the last week or
  so?  I don't use it all the time but I have been trying for the last
  couple of days without success.
  
  It accesses the server and changes the interface ip to 0.0.0.0 netmask
  255.255.255.255. 
 
 My -CURRENT dhclient is working just fine on several boxes from Dec 11,
 12, and 13.  And I guess also 14, given the time :-).  As pointed out,
 0.0.0.0 is what dhclient will set the interface IP address to when it
 doesn't have a valid lease currently, and needs to look for one.  If it
 fails to quickly find a lease, it keeps trying, but you actually get a
 window to see this address on your interface, whereas if it runs quickly,
 you often won't.
 
 Using a packet sniffer can be invaluable in debugging DHCP problems: 
 tcpdump udp port dhcpc or udp port dhcps is useful, but even better is
 ethereal's ability to decode the DHCP packet in detail, display options
 cleanly, etc.  You might want to try looking to make sure that you're
 getting a response, and if you are, whether it looks adequate :-).
 
 Robert N M Watson FreeBSD Core Team, TrustedBSD Project
 [EMAIL PROTECTED]  NAI Labs, Safeport Network Services
 
 
 
 




---

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient

2001-12-13 Thread Emiel Kollof

* Edwin Culp ([EMAIL PROTECTED]) wrote:
 Is anyone using dhclient successfully with Current of the last week or so?
 I don't use it all the time but I have been trying for the last couple of
 days without success.  
 
 It accesses the server and changes the interface ip to 0.0.0.0 netmask
 255.255.255.255.

No problems here, I just made world and kernel yesterday night (or this
morining, depends on how you put it :) after a bout of cvsupping.

FreeBSD tiamat.ipv6.hackerheaven.org 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Thu Dec 13 
04:08:33 CET 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TIAMAT  i386

dhclient works and acks fine for me.

Cheers,
Emiel
-- 
Are you a turtle?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient

2001-12-13 Thread David Wolfskill

Date: Thu, 13 Dec 2001 06:15:32 -0800
From: Edwin Culp [EMAIL PROTECTED]

Is anyone using dhclient successfully with Current of the last week or so?

Sure; hadn't noticed any problems with it.

I don't use it all the time but I have been trying for the last couple of
days without success.  

It accesses the server and changes the interface ip to 0.0.0.0 netmask
255.255.255.255.

Odd.  Looks like symptom of a failure to get a lease (to me, though I'm
not an expert in DHCP).  Do you have available IP addresses to hand out?
Are you sure the NIC is operating properly?  (E.g., can you put it in
promiscuous mode  see traffic on the net, via tcpdump or ethereal?)

(I've been tracking both -STABLE  -CURRENT daily(*), both on my laptop
(which is a DHCP client) and my build machine (which isn't) for several
months now)

* OK; modulo the occasional breakage.  But that's been pretty rare --
  even in -CURRENT, for me.

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient

2001-12-13 Thread Edwin Culp

Emiel,

Thanks a lot for the feedback.  I have to look further.

Hmmm...  Maybe it is my dhcp server but the problem originated with the
excite@home service change to attbi.com and their dhcp.  Neither work:-(

ed

Quoting Emiel Kollof [EMAIL PROTECTED]:

 * Edwin Culp ([EMAIL PROTECTED]) wrote:
  Is anyone using dhclient successfully with Current of the last week or
 so?
  I don't use it all the time but I have been trying for the last couple of
  days without success.  
  
  It accesses the server and changes the interface ip to 0.0.0.0 netmask
  255.255.255.255.
 
 No problems here, I just made world and kernel yesterday night (or this
 morining, depends on how you put it :) after a bout of cvsupping.
 
 FreeBSD tiamat.ipv6.hackerheaven.org 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Thu
 Dec 13 04:08:33 CET 2001
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TIAMAT  i386
 
 dhclient works and acks fine for me.
 
 Cheers,
 Emiel
 -- 
 Are you a turtle?
 




---

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient

2001-12-13 Thread Edwin Culp

Thanks, David.  I'm going to have to go through the whole troubleshooting
process.  Both the server and the client, my laptop, are running current and
to make it worse I did a portupgrade -Rria on both since I used dhcp the 
last time.  At least I know that it should work:-)

Thanks, again.

ed

Quoting David Wolfskill [EMAIL PROTECTED]:

 Date: Thu, 13 Dec 2001 06:15:32 -0800
 From: Edwin Culp [EMAIL PROTECTED]
 
 Is anyone using dhclient successfully with Current of the last week or so?
 
 Sure; hadn't noticed any problems with it.
 
 I don't use it all the time but I have been trying for the last couple of
 days without success.  
 
 It accesses the server and changes the interface ip to 0.0.0.0 netmask
 255.255.255.255.
 
 Odd.  Looks like symptom of a failure to get a lease (to me, though I'm
 not an expert in DHCP).  Do you have available IP addresses to hand out?
 Are you sure the NIC is operating properly?  (E.g., can you put it in
 promiscuous mode  see traffic on the net, via tcpdump or ethereal?)
 
 (I've been tracking both -STABLE  -CURRENT daily(*), both on my laptop
 (which is a DHCP client) and my build machine (which isn't) for several
 months now)
 
 * OK; modulo the occasional breakage.  But that's been pretty rare --
   even in -CURRENT, for me.
 
 Cheers,
 david
 -- 
 David H. Wolfskill[EMAIL PROTECTED]
 I believe it would be irresponsible (and thus, unethical) for me to advise,
 recommend, or support the use of any product that is or depends on any
 Microsoft product for any purpose other than personal amusement.
 




---

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient busted for -current?

2001-12-12 Thread Edwin Culp

This may explain my problem with the excite@home/attbi.com change over.
According to them it is pure dhcp.  Since it has always just worked when
I needed it, I haven't really tested.

ed

Quoting Warner Losh [EMAIL PROTECTED]:

 In message [EMAIL PROTECTED] Pierre Y.
 Dampure writes:
 : Are you asking for specific options (my dhclient.conf is empty)? are you
 using a reservation?
 
 I'm 100% sure it worked before the upgrade. :-(.
 
 Warner
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 




---

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient busted for -current?

2001-12-11 Thread Warner Losh

In message [EMAIL PROTECTED] Pierre Y. Dampure 
writes:
: Are you asking for specific options (my dhclient.conf is empty)? are you using a 
:reservation?

I'm 100% sure it worked before the upgrade. :-(.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient busted for -current?

2001-12-08 Thread Pierre Y. Dampure

On Sat, 8 Dec 2001 02:07:22 -0500, Jeremy Parker [EMAIL PROTECTED] wrote:

 I have also experienced this issue, caused me a lot of trouble.  The only 
 workaround I have figured out, is to bring up the interface with an IP 
 address, then start dhclient and it seems to work.
 
 This is a very recent problem for me as well.
 

Running -current from Thursday evening on a Latitude CPx with a 3Com 3C575, dhclient 
to a FreeBSD 4.4-stable server, no issues.

Are you asking for specific options (my dhclient.conf is empty)? are you using a 
reservation?

Best Regards,

PYD

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient busted for -current?

2001-12-07 Thread Jeremy Parker

I have also experienced this issue, caused me a lot of trouble.  The only 
workaround I have figured out, is to bring up the interface with an IP 
address, then start dhclient and it seems to work.

This is a very recent problem for me as well.

Jeremy

Warner Losh([EMAIL PROTECTED])@Fri, Dec 07, 2001 at 07:16:43PM -0700:
 
 % ifconfig -a
 ...
 wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 ...
   status: associated
   ssid X
 
 % dhclient wi0
 dhclient: wi0: not found
 dhclient: exiting
 
 Has anybody else seen this?  I've seen this on two machines now,
 including one from yesterday.
 
 Warner
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient fails on -current

2001-09-11 Thread David O'Brien

On Tue, Sep 11, 2001 at 01:28:12PM -0500, Michael Harnois wrote:
 For the last five days or so, dhclient from isc-dhcp2 has not worked
 with -current on my machine. It reports dc0: not found. Some others
 reported a similar problem with postfix which was cured by
 recompiling. The same solution does not work with dhclient.

Why are you using the client from isc-dhcp2 when that is the same client
in the base system?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: dhclient fails on -current

2001-09-11 Thread Michael Harnois

On Tue, 11 Sep 2001 13:05:57 -0700, David O'Brien [EMAIL PROTECTED] said:

 Why are you using the client from isc-dhcp2 when that is the
 same client in the base system?

In fact, having looked at my rc.conf now, I am using the one from the
base system.

-- 
Michael D. Harnois   bilocational bivocational
Pastor, Redeemer Lutheran ChurchWashburn, Iowa
1L, UST School of Law   Minneapolis, Minnesota
 Make everything as simple as possible, but not simpler. -- Einstein

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message