Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Cy Schubert]

Pull request #787. I can look at it.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0


In message , "Naman 
Sood
" writes:
> Hi,
>
> wpa_supplicant-devel unfortunately did not fix my problem. However, applying 
> this patch did: https://github.com/freebsd/freebsd-src/commit/b393d862dc78a99
> 203455b01e685fb2108e51b05.
>
> Thanks,
> Naman.
> (they/them)
>
> On Sat, Jul 1, 2023, at 00:14, Cy Schubert wrote:
> > On Fri, 30 Jun 2023 10:56:54 -0700
> > Cy Schubert  wrote:
> > 
> > > Can you try wpa_supplicant-devel? It was updated last week. The -devel po
> rt tracks the latest WPA development. 
> > > 
> > > 
> > 
> > Now that I'm back at home, looking at hostap (our upstream w1.fi) commit
> > logs, there have been a few OpenSSL 3.0 patches applied to wpa since
> > wpa_supplicant/hostapd 2.10 was imported into FreeBSD base (on Jan 18,
> > 2022). Try the wpa_supplicant-devel port, it's current to the latest
> > upstream w1.fi commit. If it fixes your problem, I will import it into
> > FreeBSD base as well
> > 
> > I backport a few patches applied to base back into both ports next week.
> > 
> > 
> > -- 
> > Cheers,
> > Cy Schubert 
> > FreeBSD UNIX: Web:  https://FreeBSD.org 
> >  d.org/>
> > NTP:   Web:  https://nwtime.org
> > 
> > e^(i*pi)+1=0
> > 
> > 

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Naman Sood]

Hi,

wpa_supplicant-devel unfortunately did not fix my problem. However, applying 
this patch did: 
https://github.com/freebsd/freebsd-src/commit/b393d862dc78a99203455b01e685fb2108e51b05.

Thanks,
Naman.
(they/them)

On Sat, Jul 1, 2023, at 00:14, Cy Schubert wrote:
> On Fri, 30 Jun 2023 10:56:54 -0700
> Cy Schubert  wrote:
> 
> > Can you try wpa_supplicant-devel? It was updated last week. The -devel port 
> > tracks the latest WPA development. 
> > 
> > 
> 
> Now that I'm back at home, looking at hostap (our upstream w1.fi) commit
> logs, there have been a few OpenSSL 3.0 patches applied to wpa since
> wpa_supplicant/hostapd 2.10 was imported into FreeBSD base (on Jan 18,
> 2022). Try the wpa_supplicant-devel port, it's current to the latest
> upstream w1.fi commit. If it fixes your problem, I will import it into
> FreeBSD base as well
> 
> I backport a few patches applied to base back into both ports next week.
> 
> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org 
> 
> NTP:   Web:  https://nwtime.org
> 
> e^(i*pi)+1=0
> 
> 

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Cy Schubert]

On Fri, 30 Jun 2023 10:56:54 -0700
Cy Schubert  wrote:

> Can you try wpa_supplicant-devel? It was updated last week. The -devel port 
> tracks the latest WPA development. 
> 
> 

Now that I'm back at home, looking at hostap (our upstream w1.fi) commit
logs, there have been a few OpenSSL 3.0 patches applied to wpa since
wpa_supplicant/hostapd 2.10 was imported into FreeBSD base (on Jan 18,
2022). Try the wpa_supplicant-devel port, it's current to the latest
upstream w1.fi commit. If it fixes your problem, I will import it into
FreeBSD base as well

I backport a few patches applied to base back into both ports next week.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Cy Schubert]

Can you try wpa_supplicant-devel? It was updated last week. The -devel port 
tracks the latest WPA development. 


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:Web:  https://FreeBSD.org
NTP: Web:  https://nwtime.org
e^(i*pi)+1=0

Pardon the typos. Small keyboard in use.

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Naman Sood]

Hi,

I just tried using security/wpa_supplicant, that does not help - exactly the 
same logs as before.

PS: I hope this attaches to the right thread, I didn't get an email for your 
response and had to craft a special link to hopefully get the In-Reply-To mail 
header to set. O_o

Thanks,
Naman.
(they/them)

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Marek Zarychta]

W dniu 28.06.2023 o 18:54, Naman Sood pisze:

Hi,

After doing a system update to the newest CURRENT, dhclient is not able to 
obtain an IP address for itself over an eduroam WPA2-Enterprise PEAP network. 
Connecting to open and WPA2-Personal networks works fine. I'm using the rtwn 
network driver. Here's some relevant bits from all.log (I got this by killing 
dhclient, restarting netif, then running dhclient again manually on wlan0):

Jun 28 12:32:52 neon sudo[3656]:nsood : TTY=pts/1 ; PWD=/usr/home/nsood ; 
USER=root ; 
ENV=PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/nsood/binCOMMAND=/usr/bin/env
 dhclient wlan0
Jun 28 12:32:52 neon dhclient[3660]: DHCPREQUEST on wlan0 to 255.255.255.255 
port 67
Jun 28 12:32:52 neon dhclient[3660]: send_packet: No buffer space available
Jun 28 12:32:52 neon kernel: Jun 28 12:32:52 neon dhclient[3660]: send_packet: 
No buffer space available
Jun 28 12:32:59 neon dhclient[3660]: DHCPREQUEST on wlan0 to 255.255.255.255 
port 67
Jun 28 12:32:59 neon dhclient[3660]: send_packet: No buffer space available
Jun 28 12:33:00 neon /usr/sbin/cron[3665]: (operator) CMD 
(/usr/libexec/save-entropy)
Jun 28 12:33:13 neon dhclient[3660]: DHCPDISCOVER on wlan0 to 255.255.255.255 
port 67 interval 3
Jun 28 12:33:13 neon dhclient[3660]: send_packet: No buffer space available
Jun 28 12:33:16 neon dhclient[3660]: DHCPDISCOVER on wlan0 to 255.255.255.255 
port 67 interval 6
Jun 28 12:33:16 neon dhclient[3660]: send_packet: No buffer space available
Jun 28 12:33:22 neon dhclient[3660]: DHCPDISCOVER on wlan0 to 255.255.255.255 
port 67 interval 14
Jun 28 12:33:22 neon dhclient[3660]: send_packet: No buffer space available
Jun 28 12:33:36 neon dhclient[3660]: DHCPDISCOVER on wlan0 to 255.255.255.255 
port 67 interval 21
Jun 28 12:33:36 neon dhclient[3660]: send_packet: No buffer space available
Jun 28 12:33:36 neon kernel: Jun 28 12:33:36 neon syslogd: last message 
repeated 5 times
Jun 28 12:33:39 neon wpa_supplicant[3494]: wlan0: CTRL-EVENT-EAP-FAILURE EAP 
authentication failed
Jun 28 12:33:41 neon wpa_supplicant[3494]: wlan0: Authentication with 
84:f1:47:d6:48:20 timed out.
Jun 28 12:33:41 neon wpa_supplicant[3494]: wlan0: CTRL-EVENT-DISCONNECTED 
bssid=84:f1:47:d6:48:20 reason=3 locally_generated=1
Jun 28 12:33:41 neon wpa_supplicant[3494]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 
ssid="eduroam" auth_failures=1 duration=10 reason=AUTH_FAILED
Jun 28 12:33:41 neon wpa_supplicant[3494]: BSSID 84:f1:47:d6:48:20 ignore list 
count incremented to 2, ignoring for 10 seconds
Jun 28 12:33:41 neon wpa_supplicant[3494]: wlan0: CTRL-EVENT-DSCP-POLICY 
clear_all
Jun 28 12:33:41 neon kernel: wlan0: link state changed to DOWN
Jun 28 12:33:41 neon dhclient[3660]: wlan0 link state up -> down

After this wlan0 came back up and successfully negotiated an IP from a 
lower-priority WPA2-Personal network.

I also saw this a bit further up in all.log when it tried to connect to eduroam 
automatically:

Jun 28 12:44:24 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-SSID-REENABLED id=0 
ssid="eduroam"
Jun 28 12:44:24 neon wpa_supplicant[1517]: wlan0: Trying to associate with 
84:f1:47:d6:48:20 (SSID='eduroam' freq=2437 MHz)
Jun 28 12:44:25 neon kernel: wlan0: link state changed to UP
Jun 28 12:44:25 neon dhclient[1951]: wlan0 link state down -> up
Jun 28 12:44:25 neon dhclient[1951]: DHCPREQUEST on wlan0 to 255.255.255.255 
port 67
Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: Associated with 
84:f1:47:d6:48:20
Jun 28 12:44:25 neon dhclient[1951]: send_packet: No buffer space available
Jun 28 12:44:25 neon kernel: Jun 28 12:44:25 neon dhclient[1951]: send_packet: 
No buffer space available
Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-STARTED EAP 
authentication started
Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: 
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
Jun 28 12:44:25 neon wpa_supplicant[1517]: tls_connection_set_params: Clearing 
pending SSL error: error:12800067:DSO support routines::could not load the 
shared library
Jun 28 12:44:25 neon wpa_supplicant[1517]: tls_connection_set_params: Clearing 
pending SSL error: error:07880025:common libcrypto routines::reason(524325)
Jun 28 12:44:25 neon wpa_supplicant[1517]: tls_connection_set_params: Clearing 
pending SSL error: error:0308010C:digital envelope routines::unsupported
Jun 28 12:44:25 neon wpa_supplicant[1517]: tls_connection_set_params: Clearing 
pending SSL error: error:0386:digital envelope routines::initialization 
error
Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-METHOD EAP 
vendor 0 method 25 (PEAP) selected
Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-CERT 
depth=2 subject='/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign' 
hash=[redacted]
Jun 28 12:44:25 neon syslogd: last message repeated 1 times
Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-CERT 
depth=1 subject='/C=BE/O=GlobalSign nv-sa/CN=GlobalS

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Graham Perrin]

On 29/06/2023 09:07, Graham Perrin wrote:


… I just realised my discrepancy above, 1400092 1400090.




… I'll installworld then review.


Sorry, review is delayed.

(I remembered and repeated the cause of the discrepancy, an installworld 
failure 
; 
and I can not yet build the most recent src.)




OpenPGP_signature
Description: OpenPGP digital signature

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Graham Perrin]

On 28/06/2023 17:54, Naman Sood wrote:

After doing a system update to the newest CURRENT, dhclient is not able to 
obtain an IP address for itself over an eduroam WPA2-Enterprise PEAP network. …


No problem with eduroam here,

% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n263799-f81be7a8318b-dirty: Mon Jun 26 22:09:58 BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1400092 1400090

%


I'm using the rtwn network driver. …


iwn(4) here.



… makes me think the change might be related to the recent OpenSSL migration? …


I wonder.

I just realised my discrepancy above, 1400092 1400090. It's unlike me to 
forget an installworld, oops.


 
was the OpenSSL 3.0 update bump from 1400091 to 1400092.


I'll installworld then review.



OpenPGP_signature
Description: OpenPGP digital signature

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

[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

[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

[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

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

[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   41785

Re: dhclient sucks cpu usage...

[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

Re: dhclient sucks cpu usage...

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

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

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

[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=0xbfebfbff
   Features2=0xe3bd
   AMD Features=0x20100800
   AMD Features2=0x1
   TSC: P-state invariant, performance statistics
real memory  = 2147483648 (2048 MB)
avail memory = 2014019584 (1920 MB)



Index: sbin/dhclien

Re: dhclient sucks cpu usage...

[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=0xbfebfbff
  Features2=0xe3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  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...

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

[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?

[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?

[Tim Kientzle]

On Dec 14, 2013, at 3:16 PM, Darren Pilgrim  
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 can't limit bpf descriptor?

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

[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

[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

[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

[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

[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

[Adrian Chadd]

On 1 November 2013 08:45, hiren panchasara  wrote:
> On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz  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: send_packet: No buffer space available

[hiren panchasara]

On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz  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 cause up/down cycle after 239356 ?

[John Baldwin]

On Wednesday, August 22, 2012 9:35:34 pm Peter Jeremy wrote:
> On 2012-Aug-22 15:35:01 -0400, John Baldwin  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 ?

[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  and leaving
>  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 ?

[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  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  and leaving
>  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 ?

[Warner Losh]

On Aug 22, 2012, at 7:35 PM, Peter Jeremy wrote:

> On 2012-Aug-22 15:35:01 -0400, John Baldwin  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 ?

[Peter Jeremy]

On 2012-Aug-22 15:35:01 -0400, John Baldwin  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  and leaving
 in the Cc list.

-- 
Peter Jeremy


pgp9SoqeQglFI.pgp
Description: PGP signature

Re: dhclient cause up/down cycle after 239356 ?

[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  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 ?

[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 ?

[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  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 ?

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

[Peter Jeremy]

On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij  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 ?

[Vitalij Satanivskij]

Garrett Cooper wrote:
GC> On Tue, Aug 21, 2012 at 2:55 AM, Vitalij Satanivskij  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 ?

[Garrett Cooper]

On Tue, Aug 21, 2012 at 2:55 AM, Vitalij Satanivskij  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 em0: not found rev r230054

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

[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

[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:  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/ipfw conflict on boot

[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

[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

[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: 
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 fix for systems with media settings

[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

[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 problem with xl0

[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

[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

[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=8843 mtu 1500
options=8
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 )
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

[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 problem with xl0

[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

[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

[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

[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: 
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

[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 fix for systems with media settings

[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

Re: dhclient problem with xl0

[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

[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

[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

[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=8843 mtu 1500
options=8
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 )

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

[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 fix for systems with media settings

[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? (fwd)

[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,
  

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

[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: 
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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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=8802 mtu 1500
options=8
ether 00:e0:00:7e:d0:45
media: Ethernet autoselect (10baseT/UTP)
status: no carrier
fwe0: flags=8802 mtu 1500
ether 02:00:0e:70:a8:72
ch 1 dma -1
lo0: flags=8049 mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
wi0: flags=8843 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=8802 mtu 1500
options=8
ether 00:e0:00:7e:d0:45
media: Ethernet autoselect (10baseT/UTP)
status: no carrier
fwe0: flags=8802 mtu 1500
ether 02:00:0e:70:a8:72
ch 1 dma -1
lo0: flags=8049 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=8802 mtu 1500
options=8
ether 00:e0:00:7e:d0:45
media: Ethernet autoselect (10baseT/UTP)
status: no carrier
fwe0: flags=8802 mtu 1500
ether 02:00:0e:70:a8:72
ch 1 dma -1
lo0: flags=8049 mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
wi0: flags=8802 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]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: 
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--


--
Larry Rosenman htt

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

[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?

[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: 
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 script in rc.d doesn't use ${dhcp_program}(conf/53007)

[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?

[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 in background?

[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?

[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?

[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

[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

[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

[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

[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

[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

[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

[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 busted for -current?

[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?

[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?

[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?

[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=8843 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

[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

Re: dhclient fails on -current

[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