Re: service routing restart, service dhclient restart (was: Unreliability with DHCP)

[Oleksandr Kryvulia]

06.08.23 19:23, Graham Perrin пише:

Thanks,

On 06/08/2023 08:36, Oleksandr Kryvulia wrote:
… In my case default route is assigned by dhclient, so 'service 
routing restart' must be run quickly after 'service netif restart' - 
before we receive dhcp offer. 


Is this documented and explained somewhere, or did you learn through 
trial and error?


It's my own expirience  + reading /etc/rc.d/routing




Another option is to run 'service dhclient restart wlan0' after 
routing restart. …


Is there, similarly, a need to rush the two commands?
I can't answer for sure, you need to try different options and choose 
the one that works. If you're using typical network configuration, 
you'll probably be fine with routing restart + dhclient restart only. 
This works for me in most cases until I configured lagg interface.


<https://reviews.freebsd.org/P602$27> no route;
<https://reviews.freebsd.org/P602$28-33> /etc/rc.d/dhclient: WARNING: 
failed to start dhclient

service routing restart, service dhclient restart (was: Unreliability with DHCP)

[Graham Perrin]

Thanks,

On 06/08/2023 08:36, Oleksandr Kryvulia wrote:
… In my case default route is assigned by dhclient, so 'service 
routing restart' must be run quickly after 'service netif restart' - 
before we receive dhcp offer. 


Is this documented and explained somewhere, or did you learn through 
trial and error?



Another option is to run 'service dhclient restart wlan0' after 
routing restart. …


Is there, similarly, a need to rush the two commands?

<https://reviews.freebsd.org/P602$27> no route;
<https://reviews.freebsd.org/P602$28-33> /etc/rc.d/dhclient: WARNING: 
failed to start dhclient

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='/

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.


<https://github.com/freebsd/freebsd-src/commit/9ead001d5b42ef9cba04757c9e7ee74c06037139> 
was the OpenSSL 3.0 update bump from 1400091 to 1400092.


I'll installworld then review.



OpenPGP_signature
Description: OpenPGP digital signature

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

[Naman Sood]

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=GlobalSign RSA OV SSL CA 201

Re: VNET jail and dhclient

[KOT MATPOCKuH]

dhclient called very simple:
jail# dhclient epair71b.71
chroot
exiting.
jail# echo $?
1

I'm running 12.0-CURRENT r325051 and:
# sysctl kern.chroot_allow_open_directories
kern.chroot_allow_open_directories: 1

And I found some another workaround:
# dhclient -p /var/empty/pid epair71b.71
Cannot open or create pidfile: Operation not permitted
DHCPDISCOVER on epair71b.71 to 255.255.255.255 port 67 interval 6

2017-11-16 16:07 GMT+03:00 Kristof Provost <kris...@sigsegv.be>:

> On 16 Nov 2017, at 14:04, KOT MATPOCKuH wrote:
>
> Hello, all!
>
> I'm got same problem...
>
> Can you show how you call dhclient? What FreeBSD version are you running?
>
> What’s the output of sysctl kern.chroot_allow_open_directories?
>
> Regards,
> Kristof
>



-- 
MATPOCKuH
___
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: VNET jail and dhclient

[Goran Mekić]

On Thu, Nov 16, 2017 at 04:04:47PM +0300, KOT MATPOCKuH wrote:
> Hello, all!
>
> I'm got same problem...
> Did someone open an PR for this issue?
Yes, Oleg did: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223327


signature.asc
Description: PGP signature

Re: VNET jail and dhclient

[Kristof Provost]

On 16 Nov 2017, at 14:04, KOT MATPOCKuH wrote:
> Hello, all!
>
> I'm got same problem...
>
Can you show how you call dhclient? What FreeBSD version are you running?

What’s the output of `sysctl kern.chroot_allow_open_directories`?

Regards,
Kristof
___
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: VNET jail and dhclient

[KOT MATPOCKuH]

Hello, all!

I'm got same problem...
Did someone open an PR for this issue?

2017-10-11 22:48 GMT+03:00 Goran Mekić <meka@tilda.center>:

> On Tue, Oct 10, 2017 at 09:10:37PM +, Oleg Ginzburg wrote:
> > I think I found something, but I do not understand why this is only
> > observed in jail and with commit change this.
> > The problem about which the Goran wrote can be fixed with:
> >
> > # diff -ruN dhclient.c-orig dhclient.c
> > --- dhclient.c-orig 2017-10-10 23:51:52.451361000 +
> > +++ dhclient.c  2017-10-10 23:54:55.803404000 +
> > @@ -479,6 +479,7 @@
> >
> > fork_privchld(pipe_fd[0], pipe_fd[1]);
> >
> > +   pidfile_close(pidfile);
> > close(ifi->ufdesc);
> > ifi->ufdesc = -1;
> > close(ifi->wfdesc);
> >
> >
> >
> >
> > From pidfile(3) man page:
> >
> > The pidfile_close() function closes a pidfile.  It should be used
> after
> >  daemon fork()s to start a child process.
> >
> >
> > chroot(2) in dhclient return NOPERM (via global errno). it seems to be
> > related to open descriptor outside the chroot.
> >
> > I'm not sure if this fd leak (due to pidfile_remove at the end of
> > dhclient),  nevertheless closing pid fd in my jail/FreeBSD12 before
> chroot
> > solve dhclient issue.
>
> I can confirm Oleg's patch works for me. Weird one, for sure!
>



-- 
MATPOCKuH
___
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: VNET jail and dhclient

[Goran Mekić]

On Tue, Oct 10, 2017 at 09:10:37PM +, Oleg Ginzburg wrote:
> I think I found something, but I do not understand why this is only
> observed in jail and with commit change this.
> The problem about which the Goran wrote can be fixed with:
>
> # diff -ruN dhclient.c-orig dhclient.c
> --- dhclient.c-orig 2017-10-10 23:51:52.451361000 +
> +++ dhclient.c  2017-10-10 23:54:55.803404000 +
> @@ -479,6 +479,7 @@
>
> fork_privchld(pipe_fd[0], pipe_fd[1]);
>
> +   pidfile_close(pidfile);
> close(ifi->ufdesc);
> ifi->ufdesc = -1;
> close(ifi->wfdesc);
>
>
>
>
> From pidfile(3) man page:
>
> The pidfile_close() function closes a pidfile.  It should be used after
>  daemon fork()s to start a child process.
>
>
> chroot(2) in dhclient return NOPERM (via global errno). it seems to be
> related to open descriptor outside the chroot.
>
> I'm not sure if this fd leak (due to pidfile_remove at the end of
> dhclient),  nevertheless closing pid fd in my jail/FreeBSD12 before chroot
> solve dhclient issue.

I can confirm Oleg's patch works for me. Weird one, for sure!


signature.asc
Description: PGP signature

Re: VNET jail and dhclient

[Oleg Ginzburg]

Hello!

On Tue, Oct 10, 2017 at 8:24 PM, Kristof Provost <kris...@sigsegv.be> wrote:

> On 9 Oct 2017, at 9:25, Goran Mekić wrote:
> > Hello,
> >
> > TLDR: I can setup static IP or use dhcpcd to get address, but not
> dhclient.
> >
> > Let me elaborate. I run 12-CURRENT on my laptop and use CBSD as jail
> manager (I don't think it matters).
> >
> What version of CURRENT are you using?
>
> > # dhclient eth0
> > chroot
> > exiting.
> >
> > This is what I found with truss: https://gist.github.com/anonymous/
> 36a4e2bf1760198971934ff609a7d0de#file-gistfile1-txt-L227-L228. Selected
> lines are what I think is the problem. Offending line in the code is
> probably https://svnweb.freebsd.org/base/head/sbin/dhclient/
> dhclient.c?revision=317915=markup#l507. With that asumption, Oleg,
> CBSD author, noticed that the following "patch" works:
> >
> Is there any chance you don’t have /var/empty in your jail?
>
> I do this to create a simple vnet jail:
> sudo jail -c name=alcatraz persist vnet vnet.interface=epair0b
> (in the jail) dhclient epair0b
>
> And see:
> …
> fsync(0x9)   = 0 (0x0)
> close(8) = 0 (0x0)
> socket(PF_ROUTE,SOCK_RAW,0)  = 8 (0x8)
> shutdown(8,SHUT_WR)  = 0 (0x0)
> cap_rights_limit(8,{ CAP_READ,CAP_EVENT })   = 0 (0x0)
> chroot("/var/empty") = 0 (0x0)
> chdir("/")   = 0 (0x0)
> setgroups(0x1,0x800e2c1e4)   = 0 (0x0)
> …
>
> I also see the DCHP request packets on the other end of the epair
> interface.
>
> Regards,
> Kristof
>


What is your FreeBSD version? This problem reproduced on FreeBSD 12 only.
/var/empty is exist and trivial test:

#include 
#include 

int main()
{
printf("%d\n",chroot("/var/empty");
}

works successfully.

I think I found something, but I do not understand why this is only
observed in jail and with commit change this.
The problem about which the Goran wrote can be fixed with:

# diff -ruN dhclient.c-orig dhclient.c
--- dhclient.c-orig 2017-10-10 23:51:52.451361000 +
+++ dhclient.c  2017-10-10 23:54:55.803404000 +
@@ -479,6 +479,7 @@

fork_privchld(pipe_fd[0], pipe_fd[1]);

+   pidfile_close(pidfile);
close(ifi->ufdesc);
ifi->ufdesc = -1;
close(ifi->wfdesc);




From pidfile(3) man page:

The pidfile_close() function closes a pidfile.  It should be used after
     daemon fork()s to start a child process.


chroot(2) in dhclient return NOPERM (via global errno). it seems to be
related to open descriptor outside the chroot.

I'm not sure if this fd leak (due to pidfile_remove at the end of
dhclient),  nevertheless closing pid fd in my jail/FreeBSD12 before chroot
solve dhclient issue.
___
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: VNET jail and dhclient

[Kristof Provost]

On 10 Oct 2017, at 23:10, Oleg Ginzburg wrote:
What is your FreeBSD version? This problem reproduced on FreeBSD 12 
only.

/var/empty is exist and trivial test:


I’m running r324317 on CURRENT, yes.

What arguments are you calling dhclient with?
Clearly there’s a difference between what you’re doing and what 
I’m doing.



I'm not sure if this fd leak (due to pidfile_remove at the end of
dhclient),  nevertheless closing pid fd in my jail/FreeBSD12 before 
chroot

solve dhclient issue.


I would not expect an open file descriptor to be a problem, unless 
perhaps you’ve got an open directory and 
kern.chroot_allow_open_directories is unset.


Regards,
Kristof
___
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: VNET jail and dhclient

[Oleg Ginzburg]

in reply to
https://lists.freebsd.org/pipermail/freebsd-jail/2017-October/003444.html

comment: it looks like it's a regression in FreeBSD 12/Current,
because in FreeBSD 11 dhclient works fine:

--
jail1:/root@[15:16] # dhclient eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 192.168.10.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.10.1
bound to 192.168.8.8 -- renewal in 900 seconds.

jail1:/root@[15:16] # uname -a
FreeBSD jail1.my.domain 11.0-RELEASE-p12 FreeBSD 11.0-RELEASE-p12 #0
r324489: Tue Oct 10 14:57:58 MSK 2017
r...@f10.my.domain:/usr/obj/usr/jails/src/src_11.0/src/sys/VIMAGE
amd64
--
___
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

[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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> > 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> 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"

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

[David Wolfskill]

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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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).

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: r299512 breaks dhclient on some networks

[Don Lewis]

On 18 May, Conrad Meyer wrote:
> On Wed, May 18, 2016 at 5:19 PM, Don Lewis  wrote:
>>
>> It looks to me like r299512 is changing the format of the client
>> identifier by inserting the struct hardware hlen field into it.
> 
> Yes.  The problem with r299512 is that it assumed the client_id was
> actually a valid struct hardware, as the array's size suggested, when
> in fact it has nothing to do with that struct.
> 
>>  That's
>> not valid if htype is non-zero the way I interpret RFC 2132.  On the
>> other hand, I would think that the server would interpret the client ID
>> as an opaque cookie, so I wouldn't think it would make a difference
>> (other than thinking this is a new client) unless your server is
>> configured to look for specific client IDs.
> 
> That seems like a pretty reasonable use of the client identifier.  Or
> less reasonably but still expected, only allowing client identifiers
> of exactly 6 bytes.

See section 9.14 in RFC 2132.  It's not a hard requirement because the
RFC uses MAY and SHOULD, but if the first byte of the ID is 1, then the
remainder of the ID should be a 6 byte ethernet MAC address.  If the
first byte is 0, then the ID is free form.

>> I think that r299512 is mostly incorrect and should be reverted.  The
>> problem reported by CID 1008682 is an overrun of hw_address.haddr.
>> struct hardware looks like this:
>>
>> struct hardware {
>> u_int8_t htype;
>> u_int8_t hlen;
>> u_int8_t haddr[16];
>> };
>>
>> I think the correct fix is just this:
>>
>> size_t hwlen = MIN(ip->hw_address.hlen,
>> sizeof(ip->hw_address.haddr));
>>
>> The old code was wrong because sizeof(client_ident)-1 is the
>> same as sizeof(struct hardware)-1, when it should be -2 to exclude both
>> htype and hlen from the calculation.
> 
> Yep.  Or equivalently, I've defined the length of client_ident in
> terms of sizeof(haddr) + 1.  The result is the same.
> 
>> The fix for CID 1305550 looks correct.
> 
> Maybe; though I reverted it too.  Really I think hlen > sizeof(haddr)
> is invalid, but I'm not familiar enough with dhclient.c to insert that
> check in the right place.  I think throwing in MIN() in an ad-hoc
> fashion maybe isn't the best approach.

If the MIN() is omitted, then Coverity might be able to figure out that
hlen is never greater than sizeof(haddr) and the code is clean.  Just
adding the MIN() might make Coverity think that hlen is not well known
and that it needs to evaluate the code with hlen values that either pass
or fail the comparison.

hlen appears to be set by the code in the AF_LINK section of
discover_interfaces().  Note that Coverity isn't flagging the memcpy()
there, even though it has know way of knowing the relationship between
the length passed to memcpy() there and sizeof(hlen).  Even with a
sanity check there, I think that is too far removed from the code in
make_discover() for it to draw any conclusions about whether hlen still
meets the constraint.

I think the best thing to do is to remove both instances of MIN() and
optionally add an assert() before
if (!options[DHO_DHCP_CLIENT_IDENTIFIER]) {
where it will protect both memcpy() calls.

BTW, the location of
char client_ident[sizeof(struct hardware)];
violates style(9).

___
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: r299512 breaks dhclient on some networks

[Don Lewis]

On 18 May, Ian FREISLICH wrote:
> On 05/18/16 20:19, Don Lewis wrote
>> It looks to me like r299512 is changing the format of the client
>> identifier by inserting the struct hardware hlen field into it.  That's
>> not valid if htype is non-zero the way I interpret RFC 2132.  On the
>> other hand, I would think that the server would interpret the client ID
>> as an opaque cookie, so I wouldn't think it would make a difference
>> (other than thinking this is a new client) unless your server is
>> configured to look for specific client IDs.
> 
> It's not that the server isn't working.  The client is discarding the
> server's offer for whatever reason.

There may be some other place in the code that validates the response
and that calculates the client ID the old way.  When it sees the
response with the new client ID, it doesn't match and the client
discards the response because it thinks the response is for some other
host.

___
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: r299512 breaks dhclient on some networks

[Conrad Meyer]

On Wed, May 18, 2016 at 5:19 PM, Don Lewis  wrote:
>
> It looks to me like r299512 is changing the format of the client
> identifier by inserting the struct hardware hlen field into it.

Yes.  The problem with r299512 is that it assumed the client_id was
actually a valid struct hardware, as the array's size suggested, when
in fact it has nothing to do with that struct.

>  That's
> not valid if htype is non-zero the way I interpret RFC 2132.  On the
> other hand, I would think that the server would interpret the client ID
> as an opaque cookie, so I wouldn't think it would make a difference
> (other than thinking this is a new client) unless your server is
> configured to look for specific client IDs.

That seems like a pretty reasonable use of the client identifier.  Or
less reasonably but still expected, only allowing client identifiers
of exactly 6 bytes.

> I think that r299512 is mostly incorrect and should be reverted.  The
> problem reported by CID 1008682 is an overrun of hw_address.haddr.
> struct hardware looks like this:
>
> struct hardware {
> u_int8_t htype;
> u_int8_t hlen;
> u_int8_t haddr[16];
> };
>
> I think the correct fix is just this:
>
> size_t hwlen = MIN(ip->hw_address.hlen,
> sizeof(ip->hw_address.haddr));
>
> The old code was wrong because sizeof(client_ident)-1 is the
> same as sizeof(struct hardware)-1, when it should be -2 to exclude both
> htype and hlen from the calculation.

Yep.  Or equivalently, I've defined the length of client_ident in
terms of sizeof(haddr) + 1.  The result is the same.

> The fix for CID 1305550 looks correct.

Maybe; though I reverted it too.  Really I think hlen > sizeof(haddr)
is invalid, but I'm not familiar enough with dhclient.c to insert that
check in the right place.  I think throwing in MIN() in an ad-hoc
fashion maybe isn't the best approach.

Best,
Conrad
___
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: r299512 breaks dhclient on some networks

[Ian FREISLICH]

On 05/18/16 20:19, Don Lewis wrote
> It looks to me like r299512 is changing the format of the client
> identifier by inserting the struct hardware hlen field into it.  That's
> not valid if htype is non-zero the way I interpret RFC 2132.  On the
> other hand, I would think that the server would interpret the client ID
> as an opaque cookie, so I wouldn't think it would make a difference
> (other than thinking this is a new client) unless your server is
> configured to look for specific client IDs.

It's not that the server isn't working.  The client is discarding the
server's offer for whatever reason.

But, r300174 has it working again for me.  I can't speak to the
correctness of the fix though.

Ian

-- 

Ian Freislich


-- 
 

Cape Augusta Digital Properties, LLC a Cape Augusta Company

*Breach of confidentiality & accidental breach of confidentiality *

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.
___
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: r299512 breaks dhclient on some networks

[Ian FREISLICH]

On 05/18/16 19:49, Conrad Meyer wrote:
> Hey Ian,
>
> r299512 incorrectly encoded client identifiers because I misunderstood
> the intent of the sizeof()-scaled client_id.  I reverted that change
> and replaced it with r300174, which I believe fixes the first overrun
> more correctly.
Just checked and DHCP is working again.

> (Coverity may still complain about CID 1305550, but I don't believe
> it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).)
>
> Thanks,
> Conrad
>
> On Wed, May 18, 2016 at 3:49 PM, Ian FREISLICH
>  wrote:
>> Hi
>>
>> I cannot for the life of me figure out why the change in r299512 breaks
>> DHCP on one network I use but not on another network.
>>
>> The only clue I can find is that the request whose response is ignored
>> has the following client ID:
>> 1:6:0:22:5f:70:a1:df
>>
>> The request whose response is use has this client ID:
>> 1:0:22:5f:70:a1:df
>>
>> Here's a dhcpdump of the request/offer that gets ignored.
>>
>> ---
>>
>>   TIME: 2016-05-18 18:46:39.134
>> IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
>> OP: 1 (BOOTPREQUEST)
>>  HTYPE: 1 (Ethernet)
>>   HLEN: 6
>>   HOPS: 0
>>XID: 92a34fc3
>>   SECS: 0
>>  FLAGS: 0
>> CIADDR: 0.0.0.0
>> YIADDR: 0.0.0.0
>> SIADDR: 0.0.0.0
>> GIADDR: 0.0.0.0
>> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>>  SNAME: .
>>  FNAME: .
>> OPTION:  53 (  1) DHCP message type 1 (DHCPDISCOVER)
>> OPTION:  61 (  8) Client-identifier 01:06:00:22:5f:70:a1:df
>> OPTION:  12 (  3) Host name zen
>> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>>  28 (Broadcast address)
>>   2 (Time offset)
>> 121 (Classless Static Route)
>>   3 (Routers)
>>  15 (Domainname)
>>   6 (DNS server)
>>  12 (Host name)
>> 119 (Domain Search)
>>
>> ---
>>
>>   TIME: 2016-05-18 18:46:39.134
>> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df)
>> OP: 2 (BOOTPREPLY)
>>  HTYPE: 1 (Ethernet)
>>   HLEN: 6
>>   HOPS: 0
>>XID: 92a34fc3
>>   SECS: 0
>>  FLAGS: 0
>> CIADDR: 0.0.0.0
>> YIADDR: 10.0.0.80
>> SIADDR: 10.0.0.1
>> GIADDR: 0.0.0.0
>> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>>  SNAME: .
>>  FNAME: .
>> OPTION:  53 (  1) DHCP message type 2 (DHCPOFFER)
>> OPTION:  54 (  4) Server identifier 10.0.0.1
>> OPTION:  51 (  4) IP address leasetime  259200 (3d)
>> OPTION:   1 (  4) Subnet mask   255.255.255.0
>> OPTION:   3 (  4) Routers   10.0.0.1
>> OPTION:   6 (  4) DNS server10.0.0.1
>> ---
>>
>>
>> And here's the request/offer that works (with the r299512 backed out)
>>
>> ---
>>
>>   TIME: 2016-05-18 18:35:33.817
>> IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
>> OP: 1 (BOOTPREQUEST)
>>  HTYPE: 1 (Ethernet)
>>   HLEN: 6
>>   HOPS: 0
>>XID: 866cfd85
>>   SECS: 4
>>  FLAGS: 0
>> CIADDR: 0.0.0.0
>> YIADDR: 0.0.0.0
>> SIADDR: 0.0.0.0
>> GIADDR: 0.0.0.0
>> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>>  SNAME: .
>>  FNAME: .
>> OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
>> OPTION:  50 (  4) Request IP address10.0.0.220
>> OPTION:  61 (  7) Client-identifier 01:00:22:5f:70:a1:df
>> OPTION:  12 (  3) Host name zen
>> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>>  28 (Broadcast address)
>>   2 (Time offset)
>> 121 (Classless Static Route)
>>   3 (Routers)
>>  15 (Domainname)
>>   6 (DNS server)
>>  12 (Host name)
>> 119 (Domain Search)
>>
>> ---
>>
>>   TIME: 2016-05-18 18:35:33.817
>> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df)
>> OP: 2 (BOOTPREPLY)
>>  HTYPE: 1 (Ethernet)
>>   HLEN: 6
>>   HOPS: 0
>>XID: 866cfd85
>>   SECS: 0
>>  FLAGS: 0
>> CIADDR: 0.0.0.0
>> YIADDR: 10.0.0.220
>> SIADDR: 10.0.0.1
>> GIADDR: 0.0.0.0
>> CHADDR: 

Re: r299512 breaks dhclient on some networks

[Don Lewis]

On 18 May, To: c...@freebsd.org wrote:
> On 18 May, Conrad Meyer wrote:
>> Hey Ian,
>> 
>> r299512 incorrectly encoded client identifiers because I misunderstood
>> the intent of the sizeof()-scaled client_id.  I reverted that change
>> and replaced it with r300174, which I believe fixes the first overrun
>> more correctly.
>> 
>> (Coverity may still complain about CID 1305550, but I don't believe
>> it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).)
> 
> It's not, but the MIN() doesn't hurt.  Coverity may no longer complain
> though because your change may think that hlen is only 16 at this point
> since that is what the earlier change tests against.
> 
> If it is checked in one place, it should probably be checked in both, or
> you could just add an assert() to check it ...

If you removed the tests in both places, Coverity would probably just
assume that everything is just fine and dandy ...

___
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: r299512 breaks dhclient on some networks

[Don Lewis]

On 18 May, Conrad Meyer wrote:
> Hey Ian,
> 
> r299512 incorrectly encoded client identifiers because I misunderstood
> the intent of the sizeof()-scaled client_id.  I reverted that change
> and replaced it with r300174, which I believe fixes the first overrun
> more correctly.
> 
> (Coverity may still complain about CID 1305550, but I don't believe
> it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).)

It's not, but the MIN() doesn't hurt.  Coverity may no longer complain
though because your change may think that hlen is only 16 at this point
since that is what the earlier change tests against.

If it is checked in one place, it should probably be checked in both, or
you could just add an assert() to check it ...

___
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: r299512 breaks dhclient on some networks

[Don Lewis]

On 18 May, Ian FREISLICH wrote:
> Hi
> 
> I cannot for the life of me figure out why the change in r299512 breaks
> DHCP on one network I use but not on another network.
>  
> The only clue I can find is that the request whose response is ignored
> has the following client ID:
> 1:6:0:22:5f:70:a1:df
> 
> The request whose response is use has this client ID:
> 1:0:22:5f:70:a1:df
> 
> Here's a dhcpdump of the request/offer that gets ignored.
> 
> ---
> 
>   TIME: 2016-05-18 18:46:39.134
> IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
> OP: 1 (BOOTPREQUEST)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 92a34fc3
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 0.0.0.0
> SIADDR: 0.0.0.0
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 1 (DHCPDISCOVER)
> OPTION:  61 (  8) Client-identifier 01:06:00:22:5f:70:a1:df
> OPTION:  12 (  3) Host name zen
> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>  28 (Broadcast address)
>   2 (Time offset)
> 121 (Classless Static Route)
>   3 (Routers)
>  15 (Domainname)
>   6 (DNS server)
>  12 (Host name)
> 119 (Domain Search)
>
> ---
> 
>   TIME: 2016-05-18 18:46:39.134
> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df)
> OP: 2 (BOOTPREPLY)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 92a34fc3
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 10.0.0.80
> SIADDR: 10.0.0.1
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 2 (DHCPOFFER)
> OPTION:  54 (  4) Server identifier 10.0.0.1
> OPTION:  51 (  4) IP address leasetime  259200 (3d)
> OPTION:   1 (  4) Subnet mask   255.255.255.0
> OPTION:   3 (  4) Routers   10.0.0.1
> OPTION:   6 (  4) DNS server10.0.0.1
> ---
> 
> 
> And here's the request/offer that works (with the r299512 backed out)
> 
> ---
> 
>   TIME: 2016-05-18 18:35:33.817
> IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
> OP: 1 (BOOTPREQUEST)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 866cfd85
>   SECS: 4
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 0.0.0.0
> SIADDR: 0.0.0.0
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
> OPTION:  50 (  4) Request IP address10.0.0.220
> OPTION:  61 (  7) Client-identifier 01:00:22:5f:70:a1:df
> OPTION:  12 (  3) Host name zen
> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>  28 (Broadcast address)
>   2 (Time offset)
> 121 (Classless Static Route)
>   3 (Routers)
>  15 (Domainname)
>   6 (DNS server)
>  12 (Host name)
> 119 (Domain Search)
>
> ---
> 
>   TIME: 2016-05-18 18:35:33.817
> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df)
> OP: 2 (BOOTPREPLY)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 866cfd85
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 10.0.0.220
> SIADDR: 10.0.0.1
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
> OPTION:  54 (  4) Server identifier 10.0.0.1
> OPTION:  51 (  4) IP address leasetime  259200 (3d)
> OPTION:   1 (  4) Subnet mask   255.255.255.0
> OPTION:   3 (  4) Routers   10.0.0.1
> OPTION:   6 (  4) DNS server10.0.0.1
> ---

It looks to me like r299512 is changing the format of the client
identifier by inserting the struct 

Re: r299512 breaks dhclient on some networks

[Conrad Meyer]

Hey Ian,

r299512 incorrectly encoded client identifiers because I misunderstood
the intent of the sizeof()-scaled client_id.  I reverted that change
and replaced it with r300174, which I believe fixes the first overrun
more correctly.

(Coverity may still complain about CID 1305550, but I don't believe
it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).)

Thanks,
Conrad

On Wed, May 18, 2016 at 3:49 PM, Ian FREISLICH
 wrote:
> Hi
>
> I cannot for the life of me figure out why the change in r299512 breaks
> DHCP on one network I use but not on another network.
>
> The only clue I can find is that the request whose response is ignored
> has the following client ID:
> 1:6:0:22:5f:70:a1:df
>
> The request whose response is use has this client ID:
> 1:0:22:5f:70:a1:df
>
> Here's a dhcpdump of the request/offer that gets ignored.
>
> ---
>
>   TIME: 2016-05-18 18:46:39.134
> IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
> OP: 1 (BOOTPREQUEST)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 92a34fc3
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 0.0.0.0
> SIADDR: 0.0.0.0
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 1 (DHCPDISCOVER)
> OPTION:  61 (  8) Client-identifier 01:06:00:22:5f:70:a1:df
> OPTION:  12 (  3) Host name zen
> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>  28 (Broadcast address)
>   2 (Time offset)
> 121 (Classless Static Route)
>   3 (Routers)
>  15 (Domainname)
>   6 (DNS server)
>  12 (Host name)
> 119 (Domain Search)
>
> ---
>
>   TIME: 2016-05-18 18:46:39.134
> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df)
> OP: 2 (BOOTPREPLY)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 92a34fc3
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 10.0.0.80
> SIADDR: 10.0.0.1
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 2 (DHCPOFFER)
> OPTION:  54 (  4) Server identifier 10.0.0.1
> OPTION:  51 (  4) IP address leasetime  259200 (3d)
> OPTION:   1 (  4) Subnet mask   255.255.255.0
> OPTION:   3 (  4) Routers   10.0.0.1
> OPTION:   6 (  4) DNS server10.0.0.1
> ---
>
>
> And here's the request/offer that works (with the r299512 backed out)
>
> ---
>
>   TIME: 2016-05-18 18:35:33.817
> IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
> OP: 1 (BOOTPREQUEST)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 866cfd85
>   SECS: 4
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 0.0.0.0
> SIADDR: 0.0.0.0
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
> OPTION:  50 (  4) Request IP address10.0.0.220
> OPTION:  61 (  7) Client-identifier 01:00:22:5f:70:a1:df
> OPTION:  12 (  3) Host name zen
> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>  28 (Broadcast address)
>   2 (Time offset)
> 121 (Classless Static Route)
>   3 (Routers)
>  15 (Domainname)
>   6 (DNS server)
>  12 (Host name)
> 119 (Domain Search)
>
> ---
>
>   TIME: 2016-05-18 18:35:33.817
> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df)
> OP: 2 (BOOTPREPLY)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 866cfd85
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 10.0.0.220
> SIADDR: 10.0.0.1
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
> OPTION:  54 (  4) Server identifier 10.0.0.1
> OPTION:  51 (  4) IP address leasetime  259200 (3d)
> OPTION:   1 (  

r299512 breaks dhclient on some networks

[Ian FREISLICH]

Hi

I cannot for the life of me figure out why the change in r299512 breaks
DHCP on one network I use but not on another network.
 
The only clue I can find is that the request whose response is ignored
has the following client ID:
1:6:0:22:5f:70:a1:df

The request whose response is use has this client ID:
1:0:22:5f:70:a1:df

Here's a dhcpdump of the request/offer that gets ignored.

---

  TIME: 2016-05-18 18:46:39.134
IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 92a34fc3
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 1 (DHCPDISCOVER)
OPTION:  61 (  8) Client-identifier 01:06:00:22:5f:70:a1:df
OPTION:  12 (  3) Host name zen
OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
 28 (Broadcast address)
  2 (Time offset)
121 (Classless Static Route)
  3 (Routers)
 15 (Domainname)
  6 (DNS server)
 12 (Host name)
119 (Domain Search)
   
---

  TIME: 2016-05-18 18:46:39.134
IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df)
OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 92a34fc3
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.0.0.80
SIADDR: 10.0.0.1
GIADDR: 0.0.0.0
CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 2 (DHCPOFFER)
OPTION:  54 (  4) Server identifier 10.0.0.1
OPTION:  51 (  4) IP address leasetime  259200 (3d)
OPTION:   1 (  4) Subnet mask   255.255.255.0
OPTION:   3 (  4) Routers   10.0.0.1
OPTION:   6 (  4) DNS server10.0.0.1
---


And here's the request/offer that works (with the r299512 backed out)

---

  TIME: 2016-05-18 18:35:33.817
IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 866cfd85
  SECS: 4
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
OPTION:  50 (  4) Request IP address10.0.0.220
OPTION:  61 (  7) Client-identifier 01:00:22:5f:70:a1:df
OPTION:  12 (  3) Host name zen
OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
 28 (Broadcast address)
  2 (Time offset)
121 (Classless Static Route)
  3 (Routers)
 15 (Domainname)
  6 (DNS server)
 12 (Host name)
119 (Domain Search)
   
---

  TIME: 2016-05-18 18:35:33.817
IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df)
OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 866cfd85
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.0.0.220
SIADDR: 10.0.0.1
GIADDR: 0.0.0.0
CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
OPTION:  54 (  4) Server identifier 10.0.0.1
OPTION:  51 (  4) IP address leasetime  259200 (3d)
OPTION:   1 (  4) Subnet mask   255.255.255.0
OPTION:   3 (  4) Routers   10.0.0.1
OPTION:   6 (  4) DNS server10.0.0.1
---



-- 
Ian Freislich


-- 
 

Cape Augusta Digital Properties, LLC a Cape Augusta Company

*Breach of confidentiality & accidental breach of confidentiality *

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This 

dhclient/unbound_local/forward.conf

[Poul-Henning Kamp]

I had my (-current) laptop on a couple of crippled guest nets
this week.

DNS didn't work.

I found out that the "forward.conf" file, which should point
local_unbound at the DNS server from the DHCP lease, is put in
/etc/unbound/forward.conf where unbound will not find it.

Should it be in /etc/unbound/conf.d/forward.conf, or should
forward.conf be explicitly included from unbound.conf ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: panic: negative refcount after dhclient during boot

[Ermal Luçi]

On Wed, Jul 8, 2015 at 5:09 PM, Ermal Luçi e...@freebsd.org wrote:



 On Tue, Jul 7, 2015 at 6:11 PM, Rink Springer r...@freebsd.org wrote:

 Hi eri@,

 On Mon, Jul 06, 2015 at 09:21:54AM +0200, Rink Springer wrote:
  On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote:
   On Jul 5, 2015, at 8:16, Rink Springer r...@freebsd.org wrote:
  
Hi all,
   
On my FreeBSD/mips machine (it's a RouterStation Pro), I get the
following panic during boot:
  
   ?
  
This reproduces 100%. I'm at:
   
FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015
   
Let me know what I can do to help track this down; I only started
getting the panic after 'gateway_enable=YES' in /etc/rc.conf
   
The kernel has INVARIANTS but no WITNESS. Config available at
http://rink.nu/tmp/FRINGE - boot log at
 http://rink.nu/tmp/fringe.txt
  
   Please file a bug!
 
  Done, 201371.

 After a suggestion by adrian@, it seems reverting r285051 fixes the
 problem for me (i.e. the system boots now)


 Can you please try with this patch and let me know if it fixes the issue.

 Index: sys/netinet/ip_output.c
 ===
 --- sys/netinet/ip_output.c (revision 285271)
 +++ sys/netinet/ip_output.c (working copy)
 @@ -660,6 +660,13 @@
  done:
 if (ro == iproute)
 RO_RTFREE(ro);
 +   else if (rte == NULL)
 +   /*
 +* If the caller supplied a route but somehow the reference
 +* to it has been released need to prevent the caller
 +* calling RTFREE on it again.
 +*/
 +   ro-ro_rt = NULL;
 if (have_ia_ref)
 ifa_free(ia-ia_ifa);
 return (error);


 Regards,
 Rink



Actually this is the correct fix apparently.
https://reviews.freebsd.org/D3036


-- 
Ermal
___
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: panic: negative refcount after dhclient during boot

[Ermal Luçi]

On Tue, Jul 7, 2015 at 6:11 PM, Rink Springer r...@freebsd.org wrote:

 Hi eri@,

 On Mon, Jul 06, 2015 at 09:21:54AM +0200, Rink Springer wrote:
  On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote:
   On Jul 5, 2015, at 8:16, Rink Springer r...@freebsd.org wrote:
  
Hi all,
   
On my FreeBSD/mips machine (it's a RouterStation Pro), I get the
following panic during boot:
  
   ?
  
This reproduces 100%. I'm at:
   
FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015
   
Let me know what I can do to help track this down; I only started
getting the panic after 'gateway_enable=YES' in /etc/rc.conf
   
The kernel has INVARIANTS but no WITNESS. Config available at
http://rink.nu/tmp/FRINGE - boot log at
 http://rink.nu/tmp/fringe.txt
  
   Please file a bug!
 
  Done, 201371.

 After a suggestion by adrian@, it seems reverting r285051 fixes the
 problem for me (i.e. the system boots now)


Can you please try with this patch and let me know if it fixes the issue.

Index: sys/netinet/ip_output.c
===
--- sys/netinet/ip_output.c (revision 285271)
+++ sys/netinet/ip_output.c (working copy)
@@ -660,6 +660,13 @@
 done:
if (ro == iproute)
RO_RTFREE(ro);
+   else if (rte == NULL)
+   /*
+* If the caller supplied a route but somehow the reference
+* to it has been released need to prevent the caller
+* calling RTFREE on it again.
+*/
+   ro-ro_rt = NULL;
if (have_ia_ref)
ifa_free(ia-ia_ifa);
return (error);


 Regards,
 Rink




-- 
Ermal
___
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: panic: negative refcount after dhclient during boot

[Rink Springer]

Hi eri@,

On Mon, Jul 06, 2015 at 09:21:54AM +0200, Rink Springer wrote:
 On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote:
  On Jul 5, 2015, at 8:16, Rink Springer r...@freebsd.org wrote:
  
   Hi all,
   
   On my FreeBSD/mips machine (it's a RouterStation Pro), I get the
   following panic during boot:
  
  ?
  
   This reproduces 100%. I'm at:
   
   FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015
   
   Let me know what I can do to help track this down; I only started
   getting the panic after 'gateway_enable=YES' in /etc/rc.conf
   
   The kernel has INVARIANTS but no WITNESS. Config available at
   http://rink.nu/tmp/FRINGE - boot log at http://rink.nu/tmp/fringe.txt
  
  Please file a bug!
 
 Done, 201371.

After a suggestion by adrian@, it seems reverting r285051 fixes the
problem for me (i.e. the system boots now)

Regards,
Rink
___
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: panic: negative refcount after dhclient during boot

[Rink Springer]

On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote:
 On Jul 5, 2015, at 8:16, Rink Springer r...@freebsd.org wrote:
 
  Hi all,
  
  On my FreeBSD/mips machine (it's a RouterStation Pro), I get the
  following panic during boot:
 
 ?
 
  This reproduces 100%. I'm at:
  
  FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015
  
  Let me know what I can do to help track this down; I only started
  getting the panic after 'gateway_enable=YES' in /etc/rc.conf
  
  The kernel has INVARIANTS but no WITNESS. Config available at
  http://rink.nu/tmp/FRINGE - boot log at http://rink.nu/tmp/fringe.txt
 
 Please file a bug!

Done, 201371.

Thanks,
Rink
___
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

panic: negative refcount after dhclient during boot

[Rink Springer]

Hi all,

On my FreeBSD/mips machine (it's a RouterStation Pro), I get the
following panic during boot:

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015

r...@greed.home.rink.nu:/home/rink/freebsd/obj/mips.mips/home/rink/freebsd/head/sys/FRINGE
 mips
gcc version 4.2.1 20070831 patched [FreeBSD]
[...]
Starting devd.
Additional inet routing options: gateway=YES.
Starting dhclient.
DHCPREQUEST on arge0 to 255.255.255.255 port 67
panic: negative refcount 0x8087ec24
KDB: enter: panic
[ thread pid 11 tid 100027 ]
Stopped at  kdb_enter+0x4c: lui at,0x8066
db r
?
KDB: reentering
KDB: stack backtrace:
db_trace_thread+30 (?,?,?,?) ra cc72b5180018 sp 0 sz 0
db_trace_self+1c (?,?,?,?) ra cc72b5300018 sp 0 sz 0
80086f30+34 (?,?,?,?) ra cc72b54801a0 sp 0 sz 0
kdb_backtrace+44 (?,?,?,?) ra cc72b6e80018 sp 0 sz 0
kdb_reenter+3c (?,?,?,?) ra cc72b718 sp 0 sz 0
db_error+30 (?,?,?,?) ra cc72b7180018 sp 0 sz 0
db_run_cmd+28 (?,?,?,?) ra cc72b7300018 sp 0 sz 0
80084204+388 (?,?,?,?) ra cc72b74800a8 sp 0 sz 0
db_command_loop+70 (?,?,?,?) ra cc72b7f00018 sp 0 sz 0
80086dc8+f4 (?,?,?,?) ra cc72b80801a8 sp 0 sz 0
kdb_trap+110 (?,?,?,?) ra cc72b9b00030 sp 0 sz 0
trap+cfc (?,?,?,?) ra cc72b9e000c8 sp 0 sz 0
MipsKernGenException+134 (0,4,80560720,12f) ra cc72baa800c8 sp
10001 sz 1
kdb_enter+4c (?,?,?,?) ra cc72bb700018 sp 0 sz 0
vpanic+ec (?,?,?,?) ra cc72bb880020 sp 0 sz 0
kassert_panic+78 (?,8087ec24,80c7b470,0) ra cc72bba80020 sp 1 sz 1
ifa_free+40 (?,?,?,?) ra cc72bbc80018 sp 0 sz 0
ip_forward+838 (?,?,?,?) ra cc72bbe00068 sp 0 sz 0
ip_input+ce4 (823baa00,?,?,?) ra cc72bc480038 sp 1 sz 0
netisr_dispatch_src+134 (?,?,?,?) ra cc72bc800040 sp 0 sz 0
netisr_dispatch+14 (?,?,?,?) ra cc72bcc00018 sp 0 sz 0
ether_demux+254 (?,823baa00,?,?) ra cc72bcd80028 sp 1 sz 0
80333ffc+530 (823baa00,?,?,?) ra cc72bd30 sp 1 sz 0
netisr_dispatch_src+134 (?,?,?,?) ra cc72bd300040 sp 0 sz 0
netisr_dispatch+14 (?,?,?,?) ra cc72bd700018 sp 0 sz 0
80333b58+54 (?,?,?,?) ra cc72bd880020 sp 0 sz 0
804c7948+30c (?,?,?,?) ra cc72bda80048 sp 0 sz 0
intr_event_execute_handlers+13c (?,?,?,?) ra cc72bdf00028 sp 0 sz 0
80228a80+c8 (?,?,?,?) ra cc72be180040 sp 0 sz 0
fork_exit+b0 (?,?,?,?) ra cc72be580028 sp 0 sz 0
fork_trampoline+10 (?,?,?,?) ra cc72be80 sp 0 sz 0
pid 11
db

This reproduces 100%. I'm at:

FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015

Let me know what I can do to help track this down; I only started
getting the panic after 'gateway_enable=YES' in /etc/rc.conf

The kernel has INVARIANTS but no WITNESS. Config available at
http://rink.nu/tmp/FRINGE - boot log at http://rink.nu/tmp/fringe.txt

Regards,
Rink Springer
___
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

panic: negative refcount after dhclient during boot

[Rink Springer]

Hi all,

On my FreeBSD/mips machine (it's a RouterStation Pro), I get the
following panic during boot:

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015

r...@greed.home.rink.nu:/home/rink/freebsd/obj/mips.mips/home/rink/freebsd/head/sys/FRINGE
 mips
gcc version 4.2.1 20070831 patched [FreeBSD]
[...]
Starting devd.
Additional inet routing options: gateway=YES.
Starting dhclient.
DHCPREQUEST on arge0 to 255.255.255.255 port 67
panic: negative refcount 0x8087ec24
KDB: enter: panic
[ thread pid 11 tid 100027 ]
Stopped at  kdb_enter+0x4c: lui at,0x8066
db r
?
KDB: reentering
KDB: stack backtrace:
db_trace_thread+30 (?,?,?,?) ra cc72b5180018 sp 0 sz 0
db_trace_self+1c (?,?,?,?) ra cc72b5300018 sp 0 sz 0
80086f30+34 (?,?,?,?) ra cc72b54801a0 sp 0 sz 0
kdb_backtrace+44 (?,?,?,?) ra cc72b6e80018 sp 0 sz 0
kdb_reenter+3c (?,?,?,?) ra cc72b718 sp 0 sz 0
db_error+30 (?,?,?,?) ra cc72b7180018 sp 0 sz 0
db_run_cmd+28 (?,?,?,?) ra cc72b7300018 sp 0 sz 0
80084204+388 (?,?,?,?) ra cc72b74800a8 sp 0 sz 0
db_command_loop+70 (?,?,?,?) ra cc72b7f00018 sp 0 sz 0
80086dc8+f4 (?,?,?,?) ra cc72b80801a8 sp 0 sz 0
kdb_trap+110 (?,?,?,?) ra cc72b9b00030 sp 0 sz 0
trap+cfc (?,?,?,?) ra cc72b9e000c8 sp 0 sz 0
MipsKernGenException+134 (0,4,80560720,12f) ra cc72baa800c8 sp
10001 sz 1
kdb_enter+4c (?,?,?,?) ra cc72bb700018 sp 0 sz 0
vpanic+ec (?,?,?,?) ra cc72bb880020 sp 0 sz 0
kassert_panic+78 (?,8087ec24,80c7b470,0) ra cc72bba80020 sp 1 sz 1
ifa_free+40 (?,?,?,?) ra cc72bbc80018 sp 0 sz 0
ip_forward+838 (?,?,?,?) ra cc72bbe00068 sp 0 sz 0
ip_input+ce4 (823baa00,?,?,?) ra cc72bc480038 sp 1 sz 0
netisr_dispatch_src+134 (?,?,?,?) ra cc72bc800040 sp 0 sz 0
netisr_dispatch+14 (?,?,?,?) ra cc72bcc00018 sp 0 sz 0
ether_demux+254 (?,823baa00,?,?) ra cc72bcd80028 sp 1 sz 0
80333ffc+530 (823baa00,?,?,?) ra cc72bd30 sp 1 sz 0
netisr_dispatch_src+134 (?,?,?,?) ra cc72bd300040 sp 0 sz 0
netisr_dispatch+14 (?,?,?,?) ra cc72bd700018 sp 0 sz 0
80333b58+54 (?,?,?,?) ra cc72bd880020 sp 0 sz 0
804c7948+30c (?,?,?,?) ra cc72bda80048 sp 0 sz 0
intr_event_execute_handlers+13c (?,?,?,?) ra cc72bdf00028 sp 0 sz 0
80228a80+c8 (?,?,?,?) ra cc72be180040 sp 0 sz 0
fork_exit+b0 (?,?,?,?) ra cc72be580028 sp 0 sz 0
fork_trampoline+10 (?,?,?,?) ra cc72be80 sp 0 sz 0
pid 11
db

This reproduces 100%. I'm at:

FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015

Let me know what I can do to help track this down; I only started
getting the panic after 'gateway_enable=YES' in /etc/rc.conf

The kernel has INVARIANTS but no WITNESS. Config available at
http://rink.nu/tmp/FRINGE - boot log at http://rink.nu/tmp/fringe.txt

Regards,
Rink Springer
___
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: panic: negative refcount after dhclient during boot

[Garrett Cooper]

On Jul 5, 2015, at 8:16, Rink Springer r...@freebsd.org wrote:

 Hi all,
 
 On my FreeBSD/mips machine (it's a RouterStation Pro), I get the
 following panic during boot:

…

 This reproduces 100%. I'm at:
 
 FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015
 
 Let me know what I can do to help track this down; I only started
 getting the panic after 'gateway_enable=YES' in /etc/rc.conf
 
 The kernel has INVARIANTS but no WITNESS. Config available at
 http://rink.nu/tmp/FRINGE - boot log at http://rink.nu/tmp/fringe.txt

Please file a bug!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Peter Wemm]

On Tuesday, September 16, 2014 12:42:36 PM Mateusz Guzik wrote:
 On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote:
  On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote:
   On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org 
wrote:
On 09.09.2014 21:53, Patrick Kelsey wrote:
 I don't think it is worth the trouble, as given the larger pattern
 of
 libc routines requiring multiple capsicum rights, it seems one will
 in
 general have to have libc implementation knowledge when using it in
 concert with capsicum.  For example, consider the limitfd() routine
 in
 kdump.c, which provides rights for the TIOCGETA ioctl to be used on
 stdout so the eventual call to isatty() via printf() will work as

intended.

 I think the above kdump example is a good one for the subtle issues
 that
 can arise when using capsicum with libc.  That call to isatty() is
 via a
 widely-used internal libc routine __smakebuf().  __smakebuf() also
 calls
 __swhatbuf(), which in turn calls _fstat(), all to make sure that
 output
 to a tty is line buffered by default.  It would appear that programs
 that restrict rights on stdout without allowing CAP_IOCTL and
 CAP_FSTAT
 could be disabling the normally default line buffering when stdout
 is a
 tty.  kdump goes the distance, but dhclient does not (restricting
 stdout
 to CAP_WRITE only).
 
 In any event, the patch attached to my first message is seeming like
 the
 way to go.

Well, then commit it (if capsicum team agrees).
   
   Will do - thanks for the feedback.
   
   -Patrick
  
  Is there any possibility that this is related to the problem we've
  recently
  hit in the freebsd.org cluster with this month's refresh?
  
  After running for a while:
  Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator
  Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator
  Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch
  returned
  error -1, errno is Capabilities insufficient
  
  Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully
  last time (65258)
  Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator
  Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator
  Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch
  returned
  error -1, errno is Capabilities insufficient
  
  Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully
  last time (28213)
  Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator
  Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator
  Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch
  returned
  error -1, errno is Capabilities insufficient
  
  I believe this jail was started from the boot process. If I restart the
  jail by hand from a ssh session the problem goes away.
  
  This is unbound from ports and I don't have any more details than this. 
  This is new this month.
 
 Is this thingy multithreaded?
 
 Currently there is a race in the kernel where fd is visible before
 relevant capabilities are installed. This can result in an error like
 this one for weird processes.
 
 I got a patch for this:
 http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.html
 
 but it got stalled on 'memory barrier' discussion. I'll try to ping
 people to move it forward.
 
 IIRC there was a report of unbound failing this way, apparently fixed
 with aforementioned patch.

Yes, unbound is multi-threaded and your comment is the first potential 
explanation that makes sense so far.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.

Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Mateusz Guzik]

On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote:
 On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote:
  On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org wrote:
   On 09.09.2014 21:53, Patrick Kelsey wrote:
I don't think it is worth the trouble, as given the larger pattern of
libc routines requiring multiple capsicum rights, it seems one will in
general have to have libc implementation knowledge when using it in
concert with capsicum.  For example, consider the limitfd() routine in
kdump.c, which provides rights for the TIOCGETA ioctl to be used on
stdout so the eventual call to isatty() via printf() will work as
   
   intended.
   
I think the above kdump example is a good one for the subtle issues that
can arise when using capsicum with libc.  That call to isatty() is via a
widely-used internal libc routine __smakebuf().  __smakebuf() also calls
__swhatbuf(), which in turn calls _fstat(), all to make sure that output
to a tty is line buffered by default.  It would appear that programs
that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT
could be disabling the normally default line buffering when stdout is a
tty.  kdump goes the distance, but dhclient does not (restricting stdout
to CAP_WRITE only).

In any event, the patch attached to my first message is seeming like the
way to go.
   
   Well, then commit it (if capsicum team agrees).
  
  Will do - thanks for the feedback.
  
  -Patrick
 
 Is there any possibility that this is related to the problem we've recently 
 hit in the freebsd.org cluster with this month's refresh?
 
 After running for a while:
 Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator
 Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator
 Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned 
 error -1, errno is Capabilities insufficient
 
 Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully last 
 time (65258)
 Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator
 Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator
 Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch returned 
 error -1, errno is Capabilities insufficient
 
 Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully last 
 time (28213)
 Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator
 Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator
 Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch returned 
 error -1, errno is Capabilities insufficient
 
 I believe this jail was started from the boot process. If I restart the jail 
 by hand from a ssh session the problem goes away.
 
 This is unbound from ports and I don't have any more details than this.  This 
 is new this month.
 

Is this thingy multithreaded?

Currently there is a race in the kernel where fd is visible before
relevant capabilities are installed. This can result in an error like
this one for weird processes.

I got a patch for this:
http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.html

but it got stalled on 'memory barrier' discussion. I'll try to ping
people to move it forward.

IIRC there was a report of unbound failing this way, apparently fixed
with aforementioned patch.

-- 
Mateusz Guzik mjguzik gmail.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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Andrey Chernov]

On 13.09.2014 8:29, Peter Wemm wrote:
 On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote:
 On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org wrote:
 On 09.09.2014 21:53, Patrick Kelsey wrote:
 I don't think it is worth the trouble, as given the larger pattern of
 libc routines requiring multiple capsicum rights, it seems one will in
 general have to have libc implementation knowledge when using it in
 concert with capsicum.  For example, consider the limitfd() routine in
 kdump.c, which provides rights for the TIOCGETA ioctl to be used on
 stdout so the eventual call to isatty() via printf() will work as

 intended.

 I think the above kdump example is a good one for the subtle issues that
 can arise when using capsicum with libc.  That call to isatty() is via a
 widely-used internal libc routine __smakebuf().  __smakebuf() also calls
 __swhatbuf(), which in turn calls _fstat(), all to make sure that output
 to a tty is line buffered by default.  It would appear that programs
 that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT
 could be disabling the normally default line buffering when stdout is a
 tty.  kdump goes the distance, but dhclient does not (restricting stdout
 to CAP_WRITE only).

 In any event, the patch attached to my first message is seeming like the
 way to go.

 Well, then commit it (if capsicum team agrees).

 Will do - thanks for the feedback.

 -Patrick
 
 Is there any possibility that this is related to the problem we've recently 
 hit in the freebsd.org cluster with this month's refresh?
 
 After running for a while:
 Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator
 Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator
 Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned 
 error -1, errno is Capabilities insufficient

unbound itself does not use capsicum, just grep cap_, ldns too, so the
problem can be somewhere else.

-- 
http://ache.vniz.net/



signature.asc
Description: OpenPGP digital signature

Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Peter Wemm]

On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote:
 On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org wrote:
  On 09.09.2014 21:53, Patrick Kelsey wrote:
   I don't think it is worth the trouble, as given the larger pattern of
   libc routines requiring multiple capsicum rights, it seems one will in
   general have to have libc implementation knowledge when using it in
   concert with capsicum.  For example, consider the limitfd() routine in
   kdump.c, which provides rights for the TIOCGETA ioctl to be used on
   stdout so the eventual call to isatty() via printf() will work as
  
  intended.
  
   I think the above kdump example is a good one for the subtle issues that
   can arise when using capsicum with libc.  That call to isatty() is via a
   widely-used internal libc routine __smakebuf().  __smakebuf() also calls
   __swhatbuf(), which in turn calls _fstat(), all to make sure that output
   to a tty is line buffered by default.  It would appear that programs
   that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT
   could be disabling the normally default line buffering when stdout is a
   tty.  kdump goes the distance, but dhclient does not (restricting stdout
   to CAP_WRITE only).
   
   In any event, the patch attached to my first message is seeming like the
   way to go.
  
  Well, then commit it (if capsicum team agrees).
 
 Will do - thanks for the feedback.
 
 -Patrick

Is there any possibility that this is related to the problem we've recently 
hit in the freebsd.org cluster with this month's refresh?

After running for a while:
Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator
Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator
Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned 
error -1, errno is Capabilities insufficient

Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully last 
time (65258)
Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator
Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator
Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch returned 
error -1, errno is Capabilities insufficient

Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully last 
time (28213)
Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator
Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator
Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch returned 
error -1, errno is Capabilities insufficient

I believe this jail was started from the boot process. If I restart the jail 
by hand from a ssh session the problem goes away.

This is unbound from ports and I don't have any more details than this.  This 
is new this month.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.

Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Patrick Kelsey]

On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org wrote:

 On 09.09.2014 21:53, Patrick Kelsey wrote:
  I don't think it is worth the trouble, as given the larger pattern of
  libc routines requiring multiple capsicum rights, it seems one will in
  general have to have libc implementation knowledge when using it in
  concert with capsicum.  For example, consider the limitfd() routine in
  kdump.c, which provides rights for the TIOCGETA ioctl to be used on
  stdout so the eventual call to isatty() via printf() will work as
 intended.
 
  I think the above kdump example is a good one for the subtle issues that
  can arise when using capsicum with libc.  That call to isatty() is via a
  widely-used internal libc routine __smakebuf().  __smakebuf() also calls
  __swhatbuf(), which in turn calls _fstat(), all to make sure that output
  to a tty is line buffered by default.  It would appear that programs
  that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT
  could be disabling the normally default line buffering when stdout is a
  tty.  kdump goes the distance, but dhclient does not (restricting stdout
  to CAP_WRITE only).
 
  In any event, the patch attached to my first message is seeming like the
  way to go.

 Well, then commit it (if capsicum team agrees).



Will do - thanks for the feedback.

-Patrick
___
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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Andrey Chernov]

On 09.09.2014 21:53, Patrick Kelsey wrote:
 I don't think it is worth the trouble, as given the larger pattern of
 libc routines requiring multiple capsicum rights, it seems one will in
 general have to have libc implementation knowledge when using it in
 concert with capsicum.  For example, consider the limitfd() routine in
 kdump.c, which provides rights for the TIOCGETA ioctl to be used on
 stdout so the eventual call to isatty() via printf() will work as intended.
 
 I think the above kdump example is a good one for the subtle issues that
 can arise when using capsicum with libc.  That call to isatty() is via a
 widely-used internal libc routine __smakebuf().  __smakebuf() also calls
 __swhatbuf(), which in turn calls _fstat(), all to make sure that output
 to a tty is line buffered by default.  It would appear that programs
 that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT
 could be disabling the normally default line buffering when stdout is a
 tty.  kdump goes the distance, but dhclient does not (restricting stdout
 to CAP_WRITE only).
 
 In any event, the patch attached to my first message is seeming like the
 way to go.

Well, then commit it (if capsicum team agrees).

-- 
http://ache.vniz.net/
___
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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Patrick Kelsey]

On Mon, Sep 8, 2014 at 6:00 PM, Andrey Chernov a...@freebsd.org wrote:

 On 09.09.2014 1:13, Patrick Kelsey wrote:
  You make a godo point about the wider use of fcntl() in libc - aside
  from the rpc code, by my count there are 14 other entry points in libc
  that use fcntl in their implementation.  To experience breakage,
  programs that use those entry points would also have to be supplying
  them fds with restricted rights that do not include CAP_FCNTL.  By my
  count, there are currently only 12 programs in -current that call
  cap_rights_limit().  I don't think these counts inform us very well as
  to the presence and extent of any capsicum+libc issues similar to the
  one that I've raised.  Those 12 programs mentioned above would have to
  be audited to determine if any of the 15 libc entry points (including
  fcntl) that use fcntl are being used on those restricted fds without
  being granted CAP_FCNTL rights, and whether there are overt or potential
  failures occurring as a result.  Consider that the failure mode in
  tcpdump that I found requires that you be using multiple capture files
  with size-based rotation, otherwise all works fine.  Also consider that
  the failure mode in dhclient only occurs when a rewritten client lease
  file is smaller than its predecessor.

 Just to note by quick glance:
 tcpdump use fdopen(), so in some cases probably already broken without
 F_GETFL rights.
 openssh use fdopen(), so suspicious about F_GETFL too, but I don't
 traverse the order in which fdopen() and cap_rights_* there are applied.


I have now looked at all of the programs in -current that call
cap_rights_limit() (dhclient, hastd, ping, tcpdump, rwhod, ctld, iscsid,
kdump, rwho, units, uniq, and sshd) and examined them to see which file
descriptors cap_rights_limit() is invoked on, with what rights, and whether
libc functions that require fcntl rights (fcntl, fdopendir, fdopen,
freopen, fseek, ftell, popen, lockf, etc) are subsequently used on those
descriptors.  In most cases, the programs are simple and/or the application
of cap_rights_limit() is otherwise limited in scope, and it is easy to see
that they have sufficient rights on the restricted fds for the operations
performed on those fds.  This was a mostly manual inspection, and of course
I may have missed something, but I did not find any further issues related
to insufficient capsicum rights when using libc.

In the case of tcpdump, fdopen() is not used on a file descriptor whose
rights have been restricted via cap_rights_limit().

In the case of openssh, cap_rights_limit() is used by sshd to sandbox the
unprivileged child process when using privilege separation by restricting
the child's stdin, stdout, and stderr, the child's end of the socketpair
used to communicate with the privileged parent and the child's end of the
pipe used to log to the privileged parent.  fdopen() is not used on any of
those descriptors.


  I don't think that this read-only fcntl(F_GETFL) which doesn not
 modify
  anything deserves any special rights at all (i.e. can be just
 enabled by
  default in contrast to F_SETFL), but I am not capsicum expert.
 
  I don't think I am in a position to comment on the implications of
  permanent F_GETFL rights either.  I do think that the point about wider
  use of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK
  right in sys/capability.h, as it would appear users of capsicum and libc
  are more in need of a map of capsicum rights required by libc entry
  points than they are of convenience #defines.

 Theoretically it will be possible to get rid of fcntl(F_GETFL) in
 fseek(), but O_APPEND flag need to be stored somewhere in that case, and
 stdio _flags already have all bit occupied for 16bit short. So the price
 will be changing size of the main stdio structure __sFILE to add new
 space for flags, which is undesirable I think.


I don't think it is worth the trouble, as given the larger pattern of libc
routines requiring multiple capsicum rights, it seems one will in general
have to have libc implementation knowledge when using it in concert with
capsicum.  For example, consider the limitfd() routine in kdump.c, which
provides rights for the TIOCGETA ioctl to be used on stdout so the eventual
call to isatty() via printf() will work as intended.

I think the above kdump example is a good one for the subtle issues that
can arise when using capsicum with libc.  That call to isatty() is via a
widely-used internal libc routine __smakebuf().  __smakebuf() also calls
__swhatbuf(), which in turn calls _fstat(), all to make sure that output to
a tty is line buffered by default.  It would appear that programs that
restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT could be
disabling the normally default line buffering when stdout is a tty.  kdump
goes the distance, but dhclient does not (restricting stdout to CAP_WRITE
only).

In any event, the patch attached to my first message is seeming like

_ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Patrick Kelsey]

In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the
non-append, write-only path.  Consequently, programs that use _ftello()
(via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append, write-only
files and that use capsicum to restrict capabilities on the associated fds
to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and friends) calls on those
files fail with ENOTCAPABLE due to lack of CAP_FCNTL rights.  There appear
to be only two affected programs in the tree - tcpdump and dhclient.  This
affects both CURRENT and 10-STABLE (including 10.1-PRERELEASE)

tcpdump, when configured to write to capture files rotated by size, fails
to rotate and captures indefinitely to the first file in the series.  This
can be reproduced by a command such as: tcpdump -i ifname -C 1 -W 2 -w
packets -v

By inspection, dhclient will fail to trim old data from its client leases
file when rewriting that file with a lesser amount of data than it
currently contains.  See the ftruncate() call in
dhclient.c:rewrite_client_leases().

The attached patch adds CAP_FCNTL to the limited rights established for
non-append, write-only files used by tcpdump and dhclient.  It also
restricts the fcntl rights to CAP_FCNTL_GETFL.

The current need to have CAP_FCNTL rights in order to get or set the file
position on non-append, write-only files is subtle.  Perhaps part of the
answer is to define a CAP_FSEEK right in sys/capability.h that resolves to
CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in rights(4) to
note the need for CAP_FCNTL when using ftell() and friends.

-Patrick


ftell_cap_rights.patch
Description: Binary data
___
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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Andrey Chernov]

On 09.09.2014 0:28, Patrick Kelsey wrote:
 In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the
 non-append, write-only path.  Consequently, programs that use _ftello()
 (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append,
 write-only files and that use capsicum to restrict capabilities on the
 associated fds to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and
 friends) calls on those files fail with ENOTCAPABLE due to lack of
 CAP_FCNTL rights.  There appear to be only two affected programs in the
 tree - tcpdump and dhclient.  This affects both CURRENT and 10-STABLE
 (including 10.1-PRERELEASE)
 
 tcpdump, when configured to write to capture files rotated by size,
 fails to rotate and captures indefinitely to the first file in the
 series.  This can be reproduced by a command such as: tcpdump -i
 ifname -C 1 -W 2 -w packets -v
 
 By inspection, dhclient will fail to trim old data from its client
 leases file when rewriting that file with a lesser amount of data than
 it currently contains.  See the ftruncate() call in
 dhclient.c:rewrite_client_leases().
 
 The attached patch adds CAP_FCNTL to the limited rights established for
 non-append, write-only files used by tcpdump and dhclient.  It also
 restricts the fcntl rights to CAP_FCNTL_GETFL.
 
 The current need to have CAP_FCNTL rights in order to get or set the
 file position on non-append, write-only files is subtle.  Perhaps part
 of the answer is to define a CAP_FSEEK right in sys/capability.h that
 resolves to CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in
 rights(4) to note the need for CAP_FCNTL when using ftell() and friends.
 
 -Patrick

Stdio code use fcntl(F_GETFL) already in many places, f.e. fdopen(),
freopen(). libc code in general use it in rpc code. According to your
note, all that places are currently broken in anyway.

I don't think that this read-only fcntl(F_GETFL) which doesn not modify
anything deserves any special rights at all (i.e. can be just enabled by
default in contrast to F_SETFL), but I am not capsicum expert.

-- 
http://ache.vniz.net/
___
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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Patrick Kelsey]

On Mon, Sep 8, 2014 at 4:42 PM, Andrey Chernov a...@freebsd.org wrote:

 On 09.09.2014 0:28, Patrick Kelsey wrote:
  In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the
  non-append, write-only path.  Consequently, programs that use _ftello()
  (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append,
  write-only files and that use capsicum to restrict capabilities on the
  associated fds to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and
  friends) calls on those files fail with ENOTCAPABLE due to lack of
  CAP_FCNTL rights.  There appear to be only two affected programs in the
  tree - tcpdump and dhclient.  This affects both CURRENT and 10-STABLE
  (including 10.1-PRERELEASE)
 
  tcpdump, when configured to write to capture files rotated by size,
  fails to rotate and captures indefinitely to the first file in the
  series.  This can be reproduced by a command such as: tcpdump -i
  ifname -C 1 -W 2 -w packets -v
 
  By inspection, dhclient will fail to trim old data from its client
  leases file when rewriting that file with a lesser amount of data than
  it currently contains.  See the ftruncate() call in
  dhclient.c:rewrite_client_leases().
 
  The attached patch adds CAP_FCNTL to the limited rights established for
  non-append, write-only files used by tcpdump and dhclient.  It also
  restricts the fcntl rights to CAP_FCNTL_GETFL.
 
  The current need to have CAP_FCNTL rights in order to get or set the
  file position on non-append, write-only files is subtle.  Perhaps part
  of the answer is to define a CAP_FSEEK right in sys/capability.h that
  resolves to CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in
  rights(4) to note the need for CAP_FCNTL when using ftell() and friends.
 
  -Patrick

 Stdio code use fcntl(F_GETFL) already in many places, f.e. fdopen(),
 freopen(). libc code in general use it in rpc code. According to your
 note, all that places are currently broken in anyway.


You make a godo point about the wider use of fcntl() in libc - aside from
the rpc code, by my count there are 14 other entry points in libc that use
fcntl in their implementation.  To experience breakage, programs that use
those entry points would also have to be supplying them fds with restricted
rights that do not include CAP_FCNTL.  By my count, there are currently
only 12 programs in -current that call cap_rights_limit().  I don't think
these counts inform us very well as to the presence and extent of any
capsicum+libc issues similar to the one that I've raised.  Those 12
programs mentioned above would have to be audited to determine if any of
the 15 libc entry points (including fcntl) that use fcntl are being used on
those restricted fds without being granted CAP_FCNTL rights, and whether
there are overt or potential failures occurring as a result.  Consider that
the failure mode in tcpdump that I found requires that you be using
multiple capture files with size-based rotation, otherwise all works fine.
Also consider that the failure mode in dhclient only occurs when a
rewritten client lease file is smaller than its predecessor.



 I don't think that this read-only fcntl(F_GETFL) which doesn not modify
 anything deserves any special rights at all (i.e. can be just enabled by
 default in contrast to F_SETFL), but I am not capsicum expert.


I don't think I am in a position to comment on the implications of
permanent F_GETFL rights either.  I do think that the point about wider use
of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK right in
sys/capability.h, as it would appear users of capsicum and libc are more in
need of a map of capsicum rights required by libc entry points than they
are of convenience #defines.

-Patrick
___
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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

[Andrey Chernov]

On 09.09.2014 1:13, Patrick Kelsey wrote:
 You make a godo point about the wider use of fcntl() in libc - aside
 from the rpc code, by my count there are 14 other entry points in libc
 that use fcntl in their implementation.  To experience breakage,
 programs that use those entry points would also have to be supplying
 them fds with restricted rights that do not include CAP_FCNTL.  By my
 count, there are currently only 12 programs in -current that call
 cap_rights_limit().  I don't think these counts inform us very well as
 to the presence and extent of any capsicum+libc issues similar to the
 one that I've raised.  Those 12 programs mentioned above would have to
 be audited to determine if any of the 15 libc entry points (including
 fcntl) that use fcntl are being used on those restricted fds without
 being granted CAP_FCNTL rights, and whether there are overt or potential
 failures occurring as a result.  Consider that the failure mode in
 tcpdump that I found requires that you be using multiple capture files
 with size-based rotation, otherwise all works fine.  Also consider that
 the failure mode in dhclient only occurs when a rewritten client lease
 file is smaller than its predecessor.

Just to note by quick glance:
tcpdump use fdopen(), so in some cases probably already broken without
F_GETFL rights.
openssh use fdopen(), so suspicious about F_GETFL too, but I don't
traverse the order in which fdopen() and cap_rights_* there are applied.

 I don't think that this read-only fcntl(F_GETFL) which doesn not modify
 anything deserves any special rights at all (i.e. can be just enabled by
 default in contrast to F_SETFL), but I am not capsicum expert.
 
 I don't think I am in a position to comment on the implications of
 permanent F_GETFL rights either.  I do think that the point about wider
 use of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK
 right in sys/capability.h, as it would appear users of capsicum and libc
 are more in need of a map of capsicum rights required by libc entry
 points than they are of convenience #defines.

Theoretically it will be possible to get rid of fcntl(F_GETFL) in
fseek(), but O_APPEND flag need to be stored somewhere in that case, and
stdio _flags already have all bit occupied for 16bit short. So the price
will be changing size of the main stdio structure __sFILE to add new
space for flags, which is undesirable I think.

-- 
http://ache.vniz.net/
___
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...

[John-Mark Gurney]

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

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

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

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

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

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

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

 All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: dhclient sucks cpu usage...

[Alexander V. Chernikov]

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

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

On 10.06.2014 07:03, Bryan Venteicher wrote:

Hi,

- Original Message -

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

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

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

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

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

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


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

I've been using the kludgey workaround patch below.

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

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

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

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

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

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


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

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




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

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

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

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

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

[John-Mark Gurney]

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

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

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

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

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

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

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   41785251435  3868  2236 dhclient
   976em0 -ifs--l   4178539 0 1 0 0 dhclient
 
 and now the rate only drops from ~66MiB/s to ~63MiB/s when dhclient is
 running...  Still a significant drop (5%), but better than before...
Interesting.
Can you provide some traces (pmc or dtrace ones)?

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

dhclient sucks cpu usage...

[John-Mark Gurney]

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

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

[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

dhclient can't limit bpf descriptor?

[Tim Kientzle]

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.

I’ve upgraded Parallels and the Mac OS system that Parallels
is running on, so it could be related to that...

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

[Tim Kientzle]

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

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

Nope, it’s an unmodified GENERIC kernel.

Tim

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

Re: dhclient failure with Realtek 8111E Ethernet on new MSI motherboard

[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

[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

[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

dhclient failure with Realtek 8111E Ethernet on new MSI motherboard

[Thomas Mueller]

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?  

9.2_STABLE, 10-stable or 11-head?

Does it require a specific svn revision?

I just updated FreeBSD-current on new MSI motherboard (svn revision 257695).

dhclient re0 still gives same error.

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?

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

dhclient: send_packet: No buffer space available

[Matthias Apitz]

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

The WLAN for the rest works fine without any problem or hick-ups and
dhclient always gets and assigns the IP to the wlan0 (ath0) interface.
Any idea?

Thx

matthias

-- 
Matthias Apitz   |  /\ ASCII Ribbon Campaign: www.asciiribbon.org
E-mail: g...@unixarea.de |  \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ |   X  - No proprietary attachments
phone: +49-170-4527211   |  / \ - Respect for open standards
___
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 g...@unixarea.de wrote:


 Hello,

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

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

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

I do not think this has been tracked down yet.

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

Re: dhclient: send_packet: No buffer space available

[Adrian Chadd]

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


 Hello,

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

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

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

 I do not think this has been tracked down yet.


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

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



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

dhclient failure with Realtek 8111E Etnernet on new MSI motherboard

[Thomas Mueller]

for MSI Z77 MPOWER motherboard on FreeBSD 10.0-BETA1, from /var/run/dmesg.boot:

re0: Using 1 MSI-X message
re0: Chip rev. 0x2c80
re0: MAC rev. 0x
miibus0: MII bus on re0
rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, 
auto-flow
re0: Ethernet address: d4:3d:7e:97:17:e2


Ethernet chip data for older motherboard, MSI Z68MA-ED55(B3), FreeBSD 9.2 
prerelease amd64, where Realtek 8111E Ethernet works, is

re0@pci0:3:0:0: class=0x02 card=0x76761462 chip=0x816810ec rev=0x06 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet

When I run  dhclient re0, I can't connect, get


DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 20
DHCPOFFER from 192.168.1.1
DHCPREQUEST on re0 to 255.255.255.255 port 67
DHCPREQUEST on re0 to 255.255.255.255 port 67
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

uname -a shows

FreeBSD amelia4 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256437: Mon Oct 14 16:44:23 
UTC 2013 root@:/usr/obj/usr/src/sys/SANDY10  amd64

I also get Memory modified... error message, meaning the system has become 
unstable, reboot as soon as I get the messages together.

My guess is that this is a bug in the Realtek 8111E driver.

This Ethernet on MSI Z77 MPOWER motherboard also fails on OpenBSD 5.3 LiveUSB 
but succeeds on NetBSD-current (6.99.23) amd64 ,and Linux from the System 
Rescue CD written to USB stick.

I had this problem with 9.2 prerelease, so it apparently hasn't been fixed for 
10.0.

Should I file a PR?

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: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol

[Idwer Vollering]

I think r255219 broke compilation on amd64 with WITHOUT_CLANG=yes.
___
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: 802.1X: dhclient started before the auth. process ends

[Jean-Sébastien Pédron]

On 29.07.2013 21:56, Rui Paulo wrote:
 Disable all the configuration settings and run wpa_supplicant -ddd
 all your other options...

I'm not sure I understand what you mean by disable all the
configuration settings but I did some more tests by running
wpa_supplicant manually  (ie. not using netif script) with the same options.

I found that when the interface (here, bge0) is already UP before
running wpa_supplicant, the authentication process is fast. However,
when the interface is DOWN, wpa_supplicant associates quickly but the
authentication process starts between 5 and 20 seconds after.

Here's a log with both run (with interface UP then DOWN):
http://pastebin.com/f5ydiBpV

This delay is new with the recent 10-CURRENT.

A comment about the behavior I would expect (but keep in mind I'm a dumb
user here, not a network expert at all). I see in the logs that when
issueing service netif restart bge0:
1. the interface is put DOWN, which terminates a previous dhclient
2. wpa_supplicant is stopped
3. wpa_supplicant is started again
4. wpa_supplicant associates with a remote peer, which puts the
   interface UP and triggers dhclient

I guess that this works for a Wifi network because the association is
only valid after the authentication finishes successfully. However, with
802.1X not involving Wifi (only wired), the association is made right at
the beginning (see the logs I pasted), putting the interface UP (and
triggering dhclient) before the authentication starts.

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: 802.1X: dhclient started before the auth. process ends

[Rui Paulo]

On 30 Jul 2013, at 05:43, Jean-Sébastien Pédron 
jean-sebastien.ped...@dumbbell.fr wrote:

 On 29.07.2013 21:56, Rui Paulo wrote:
 Disable all the configuration settings and run wpa_supplicant -ddd
 all your other options...
 
 I'm not sure I understand what you mean by disable all the
 configuration settings but I did some more tests by running
 wpa_supplicant manually  (ie. not using netif script) with the same options.
 
 I found that when the interface (here, bge0) is already UP before
 running wpa_supplicant, the authentication process is fast. However,
 when the interface is DOWN, wpa_supplicant associates quickly but the
 authentication process starts between 5 and 20 seconds after.
 
 Here's a log with both run (with interface UP then DOWN):
 http://pastebin.com/f5ydiBpV
 
 This delay is new with the recent 10-CURRENT.
 
 A comment about the behavior I would expect (but keep in mind I'm a dumb
 user here, not a network expert at all). I see in the logs that when
 issueing service netif restart bge0:
1. the interface is put DOWN, which terminates a previous dhclient
2. wpa_supplicant is stopped
3. wpa_supplicant is started again
4. wpa_supplicant associates with a remote peer, which puts the
   interface UP and triggers dhclient
 
 I guess that this works for a Wifi network because the association is
 only valid after the authentication finishes successfully. However, with
 802.1X not involving Wifi (only wired), the association is made right at
 the beginning (see the logs I pasted), putting the interface UP (and
 triggering dhclient) before the authentication starts.


Could you please change the initialisation script rc.d/wpa_supplicant to make 
it run with the extra options -dd ? The messages you sent are not enough to 
diagnose the problem.

--
Rui Paulo

___
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: 802.1X: dhclient started before the auth. process ends

[Lars Engels]

On Fri, Jul 26, 2013 at 02:34:51PM +0200, Jean-Sébastien Pédron wrote:
 Hi!
 
 At $WORK, we use 802.1X to authenticate computers on the network.
 Authenticated computers receive a lease in the 192.168.X.X/24 network.
 Unauthenticated ones receive a lease in the 172.16.X.X/24 network.
 
 Today, I upgraded one computer running 10-CURRENT to latest HEAD and it
 seems that the interface is brought up to early now: dhclient is started
 before wpa_supplicant finishes. This was working perfectly before the
 upgrade.
 
 I don't have logs of the working case, but here are the logs of the
 non-working one:
 http://pastebin.com/ZHcbHLQZ
 
 Was I lucky with wpa_supplicant/dhclient timing? Or is there a real
 issue here?
 

CC'ed wireless@, that's probably the proper list for the issue.


pgpTg7Tk0CF6e.pgp
Description: PGP signature

Re: 802.1X: dhclient started before the auth. process ends

[Adrian Chadd]

I think you were lucky.

dhclient shouldn't start running until wpa_supplicant has completed
authentication.


-adrian

On 29 July 2013 02:59, Lars Engels lars.eng...@0x20.net wrote:
 On Fri, Jul 26, 2013 at 02:34:51PM +0200, Jean-Sébastien Pédron wrote:
 Hi!

 At $WORK, we use 802.1X to authenticate computers on the network.
 Authenticated computers receive a lease in the 192.168.X.X/24 network.
 Unauthenticated ones receive a lease in the 172.16.X.X/24 network.

 Today, I upgraded one computer running 10-CURRENT to latest HEAD and it
 seems that the interface is brought up to early now: dhclient is started
 before wpa_supplicant finishes. This was working perfectly before the
 upgrade.

 I don't have logs of the working case, but here are the logs of the
 non-working one:
 http://pastebin.com/ZHcbHLQZ

 Was I lucky with wpa_supplicant/dhclient timing? Or is there a real
 issue here?


 CC'ed wireless@, that's probably the proper list for the issue.
___
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: 802.1X: dhclient started before the auth. process ends

[Jean-Sébastien Pédron]

On 29.07.2013 15:34, Adrian Chadd wrote:
 I think you were lucky.

I think you're right.

It works perfectly on FreeBSD 9.1, because wpa_supplicant finishes the
auth process really quickly, ie. before dhclient receives an answer from
dhcpd from the unauthenticated network:

Jul 29 15:39:46 - kernel: bge0: link state changed to UP
Jul 29 15:39:46 - dhclient[46150]: DHCPREQUEST on bge0 to
255.255.255.255 port 67
Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-STARTED EAP
authentication started
...
Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-SUCCESS EAP
authentication completed successfully
Jul 29 15:39:48 - dhclient[46150]: DHCPREQUEST on bge0 to
255.255.255.255 port 67
Jul 29 15:39:48 - dhclient[46150]: DHCPACK from 192.168.200.224
Jul 29 15:39:48 - dhclient: New IP Address (bge0): 192.168.200.91
Jul 29 15:39:48 - dhclient: New Subnet Mask (bge0): 255.255.255.0
Jul 29 15:39:48 - dhclient: New Broadcast Address (bge0): 192.168.200.255
Jul 29 15:39:48 - dhclient: New Routers (bge0): 192.168.200.254

On -CURRENT, wpa_supplicant is started more than 10 seconds after the
interface is UP and dhclient sent its request
(http://pastebin.com/ZHcbHLQZ). Therefore, a lease from the
unauthenticated network arrives first. It was working with a previous
-CURRENT (buildworld from around April if memory serves).

 dhclient shouldn't start running until wpa_supplicant has completed
 authentication.

Damn, I always thought it worked this way on FreeBSD and happily laughed
at Linux co-workers who use some kind of rc.local script to work
around this issue :-) In fact, we're all in the same boat!

I may take a look at the issue. I guess the place to fix this is in the
rc scripts. Does someone have a hint?

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: 802.1X: dhclient started before the auth. process ends

[Lars Engels]

On Mon, Jul 29, 2013 at 04:00:44PM +0200, Jean-Sébastien Pédron wrote:
 On 29.07.2013 15:34, Adrian Chadd wrote:
  I think you were lucky.
 
 I think you're right.
 
 It works perfectly on FreeBSD 9.1, because wpa_supplicant finishes the
 auth process really quickly, ie. before dhclient receives an answer from
 dhcpd from the unauthenticated network:
 
 Jul 29 15:39:46 - kernel: bge0: link state changed to UP
 Jul 29 15:39:46 - dhclient[46150]: DHCPREQUEST on bge0 to
 255.255.255.255 port 67
 Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-STARTED EAP
 authentication started
 ...
 Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-SUCCESS EAP
 authentication completed successfully
 Jul 29 15:39:48 - dhclient[46150]: DHCPREQUEST on bge0 to
 255.255.255.255 port 67
 Jul 29 15:39:48 - dhclient[46150]: DHCPACK from 192.168.200.224
 Jul 29 15:39:48 - dhclient: New IP Address (bge0): 192.168.200.91
 Jul 29 15:39:48 - dhclient: New Subnet Mask (bge0): 255.255.255.0
 Jul 29 15:39:48 - dhclient: New Broadcast Address (bge0): 192.168.200.255
 Jul 29 15:39:48 - dhclient: New Routers (bge0): 192.168.200.254
 
 On -CURRENT, wpa_supplicant is started more than 10 seconds after the
 interface is UP and dhclient sent its request
 (http://pastebin.com/ZHcbHLQZ). Therefore, a lease from the
 unauthenticated network arrives first. It was working with a previous
 -CURRENT (buildworld from around April if memory serves).

AFAIK rui@ imported a new version of wpa_supplicant into -CURRENT.

 
  dhclient shouldn't start running until wpa_supplicant has completed
  authentication.
 
 Damn, I always thought it worked this way on FreeBSD and happily laughed
 at Linux co-workers who use some kind of rc.local script to work
 around this issue :-) In fact, we're all in the same boat!
 
 I may take a look at the issue. I guess the place to fix this is in the
 rc scripts. Does someone have a hint?



pgpoXUQ0_TnHn.pgp
Description: PGP signature

Re: 802.1X: dhclient started before the auth. process ends

[Lars Engels]

On Mon, Jul 29, 2013 at 04:00:44PM +0200, Jean-Sébastien Pédron wrote:
 On 29.07.2013 15:34, Adrian Chadd wrote:
  I think you were lucky.
 
 I think you're right.
 
 It works perfectly on FreeBSD 9.1, because wpa_supplicant finishes the
 auth process really quickly, ie. before dhclient receives an answer from
 dhcpd from the unauthenticated network:
 
 Jul 29 15:39:46 - kernel: bge0: link state changed to UP
 Jul 29 15:39:46 - dhclient[46150]: DHCPREQUEST on bge0 to
 255.255.255.255 port 67
 Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-STARTED EAP
 authentication started
 ...
 Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-SUCCESS EAP
 authentication completed successfully
 Jul 29 15:39:48 - dhclient[46150]: DHCPREQUEST on bge0 to
 255.255.255.255 port 67
 Jul 29 15:39:48 - dhclient[46150]: DHCPACK from 192.168.200.224
 Jul 29 15:39:48 - dhclient: New IP Address (bge0): 192.168.200.91
 Jul 29 15:39:48 - dhclient: New Subnet Mask (bge0): 255.255.255.0
 Jul 29 15:39:48 - dhclient: New Broadcast Address (bge0): 192.168.200.255
 Jul 29 15:39:48 - dhclient: New Routers (bge0): 192.168.200.254
 
 On -CURRENT, wpa_supplicant is started more than 10 seconds after the
 interface is UP and dhclient sent its request
 (http://pastebin.com/ZHcbHLQZ). Therefore, a lease from the
 unauthenticated network arrives first. It was working with a previous
 -CURRENT (buildworld from around April if memory serves).

AFAIK rpaulo@ imported a new version of wpa_supplicant into -CURRENT.

 
  dhclient shouldn't start running until wpa_supplicant has completed
  authentication.
 
 Damn, I always thought it worked this way on FreeBSD and happily laughed
 at Linux co-workers who use some kind of rc.local script to work
 around this issue :-) In fact, we're all in the same boat!
 
 I may take a look at the issue. I guess the place to fix this is in the
 rc scripts. Does someone have a hint?



pgph6bZA_QFU9.pgp
Description: PGP signature

Re: 802.1X: dhclient started before the auth. process ends

[Adrian Chadd]

... wait, so the new version of wpa_supplicant takes 10 seconds to
even start doing anything?

Or are the rc scripts to blame?


-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: 802.1X: dhclient started before the auth. process ends

[Rui Paulo]

On 29 Jul 2013, at 07:00, Jean-Sébastien Pédron 
jean-sebastien.ped...@dumbbell.fr wrote:

 On 29.07.2013 15:34, Adrian Chadd wrote:
 I think you were lucky.
 
 I think you're right.
 
 It works perfectly on FreeBSD 9.1, because wpa_supplicant finishes the
 auth process really quickly, ie. before dhclient receives an answer from
 dhcpd from the unauthenticated network:
 
 Jul 29 15:39:46 - kernel: bge0: link state changed to UP
 Jul 29 15:39:46 - dhclient[46150]: DHCPREQUEST on bge0 to
 255.255.255.255 port 67
 Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-STARTED EAP
 authentication started
 ...
 Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-SUCCESS EAP
 authentication completed successfully
 Jul 29 15:39:48 - dhclient[46150]: DHCPREQUEST on bge0 to
 255.255.255.255 port 67
 Jul 29 15:39:48 - dhclient[46150]: DHCPACK from 192.168.200.224
 Jul 29 15:39:48 - dhclient: New IP Address (bge0): 192.168.200.91
 Jul 29 15:39:48 - dhclient: New Subnet Mask (bge0): 255.255.255.0
 Jul 29 15:39:48 - dhclient: New Broadcast Address (bge0): 192.168.200.255
 Jul 29 15:39:48 - dhclient: New Routers (bge0): 192.168.200.254
 
 On -CURRENT, wpa_supplicant is started more than 10 seconds after the
 interface is UP and dhclient sent its request
 (http://pastebin.com/ZHcbHLQZ). Therefore, a lease from the
 unauthenticated network arrives first. It was working with a previous
 -CURRENT (buildworld from around April if memory serves).


Disable all the configuration settings and run wpa_supplicant -ddd all your 
other options...

--
Rui Paulo

___
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

802.1X: dhclient started before the auth. process ends

[Jean-Sébastien Pédron]

Hi!

At $WORK, we use 802.1X to authenticate computers on the network.
Authenticated computers receive a lease in the 192.168.X.X/24 network.
Unauthenticated ones receive a lease in the 172.16.X.X/24 network.

Today, I upgraded one computer running 10-CURRENT to latest HEAD and it
seems that the interface is brought up to early now: dhclient is started
before wpa_supplicant finishes. This was working perfectly before the
upgrade.

I don't have logs of the working case, but here are the logs of the
non-working one:
http://pastebin.com/ZHcbHLQZ

Was I lucky with wpa_supplicant/dhclient timing? Or is there a real
issue here?

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: HEADSUP! dhclient(8) sandboxing.

[Alfred Perlstein]

On 7/3/13 3:52 PM, Pawel Jakub Dawidek wrote:

Hi.

I've just committed Capsicum sandboxing for the dhclient(8).
Let me know (ideally by sending e-mail to current@ and CCing me) if you
notice any weird behaviour.

The work was sponsored by the FreeBSD Foundation.

It broke running dhclient on igb0 for me.  It says interface not found 
or something to that effect.


Can I help somehow?

Basically just ifconfig down igb0 then try to run dhclient.  It will 
not work.  If you up the interface and then run it, it is OK.


See attached image.

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

devd or dhclient or ifconfig behavior seems broken

[Steve Kargl]

For years after connecting wlan0 via dhcp to a spotted
router, I would occasionially need to do

ifconfig wlan0 down
ifconfig wlan0 up

This would toggle

% ifconfig wlan0 | grep media
media: IEEE 802.11 Wireless Ethernet OFDM/6Mbps mode 11g

to

% ifconfig wlan0 | grep media
media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g

After rebuilding, installing, and rebooting a new world, I find
the following in /var/log/messages

Jul  4 00:05:03 laptop-kargl kernel: wlan0: link state changed to DOWN
Jul  4 00:05:04 laptop-kargl kernel: wlan0: link state changed to UP
Jul  4 00:05:04 laptop-kargl devd: Executing '/etc/rc.d/dhclient quietstart
   wlan0

So, devd is firing off a new dhclient.  This has never occurred before.
But, to make matters worse.  The new dhclient appears to be nuking
/etc/resolv.conf.

Has anyone seen such behavior?  How do I stop devd and/or dhclient
from nuking resolv.conf?

-- 
Steve
___
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: HEADSUP! dhclient(8) sandboxing.

[Pawel Jakub Dawidek]

On Wed, Jul 03, 2013 at 11:04:21PM -0700, Alfred Perlstein wrote:
 On 7/3/13 3:52 PM, Pawel Jakub Dawidek wrote:
  Hi.
 
  I've just committed Capsicum sandboxing for the dhclient(8).
  Let me know (ideally by sending e-mail to current@ and CCing me) if you
  notice any weird behaviour.
 
  The work was sponsored by the FreeBSD Foundation.
 
 It broke running dhclient on igb0 for me.  It says interface not found 
 or something to that effect.
 
 Can I help somehow?
 
 Basically just ifconfig down igb0 then try to run dhclient.  It will 
 not work.  If you up the interface and then run it, it is OK.
 
 See attached image.

Thanks for the report. Could you try this patch?

http://people.freebsd.org/~pjd/patches/dhclient.c.patch

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


pgp0Gs_Z1C8ZM.pgp
Description: PGP signature

Re: HEADSUP! dhclient(8) sandboxing.

[Andrey Chernov]

On 04.07.2013 2:52, Pawel Jakub Dawidek wrote:
 I've just committed Capsicum sandboxing for the dhclient(8).
 Let me know (ideally by sending e-mail to current@ and CCing me) if you
 notice any weird behaviour.

I don't test one your very recent commit yet, but whole previous commits
chain case dhclient broken:

Starting dhclient.
em0: no link .. got link
em0: not found
exiting.
/etc/rc.d/dhclient: WARNING: failed to start dhclient

and a bit later in rc

Starting dhclient.
em0: not found
exiting.
/etc/rc.d/dhclient: WARNING: failed to start dhclient

-- 
http://ache.vniz.net/
bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N
___
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: HEADSUP! dhclient(8) sandboxing.

[Sergey V. Dyatko]

On Thu, 4 Jul 2013 11:30:46 +0200
Pawel Jakub Dawidek p...@freebsd.org wrote:

 On Wed, Jul 03, 2013 at 11:04:21PM -0700, Alfred Perlstein wrote:
  On 7/3/13 3:52 PM, Pawel Jakub Dawidek wrote:
   Hi.
  
   I've just committed Capsicum sandboxing for the dhclient(8).
   Let me know (ideally by sending e-mail to current@ and CCing me)
   if you notice any weird behaviour.
  
   The work was sponsored by the FreeBSD Foundation.
  
  It broke running dhclient on igb0 for me.  It says interface not
  found or something to that effect.
  
  Can I help somehow?
  
  Basically just ifconfig down igb0 then try to run dhclient.  It
  will not work.  If you up the interface and then run it, it is OK.
  
  See attached image.
 
 Thanks for the report. Could you try this patch?
 
   http://people.freebsd.org/~pjd/patches/dhclient.c.patch
 

r252693 with patch works for me. 
Thanks


-- 
wbr, tiger
___
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: HEADSUP! dhclient(8) sandboxing.

[Pawel Jakub Dawidek]

On Thu, Jul 04, 2013 at 04:55:14PM +0400, Andrey Chernov wrote:
 On 04.07.2013 2:52, Pawel Jakub Dawidek wrote:
  I've just committed Capsicum sandboxing for the dhclient(8).
  Let me know (ideally by sending e-mail to current@ and CCing me) if you
  notice any weird behaviour.
 
 I don't test one your very recent commit yet, but whole previous commits
 chain case dhclient broken:
 
 Starting dhclient.
 em0: no link .. got link
 em0: not found
 exiting.
 /etc/rc.d/dhclient: WARNING: failed to start dhclient
 
 and a bit later in rc
 
 Starting dhclient.
 em0: not found
 exiting.
 /etc/rc.d/dhclient: WARNING: failed to start dhclient

It should be fixed in r252697. Could you give it a try?

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


pgpvt0u0Xs1b4.pgp
Description: PGP signature

Re: HEADSUP! dhclient(8) sandboxing.

[Andrey Chernov]

On 04.07.2013 17:20, Pawel Jakub Dawidek wrote:
 em0: not found
 
 It should be fixed in r252697. Could you give it a try?
 

Works now, thanks.

-- 
http://ache.vniz.net/
bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N
___
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: devd or dhclient or ifconfig behavior seems broken

[Mark Felder]

Check the man page for dhclient.conf. You can use the supercede
functionality to always force the settings you prefer.
___
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: HEADSUP! dhclient(8) sandboxing.

[Alfred Perlstein]

On 7/4/13 2:30 AM, Pawel Jakub Dawidek wrote:

On Wed, Jul 03, 2013 at 11:04:21PM -0700, Alfred Perlstein wrote:

On 7/3/13 3:52 PM, Pawel Jakub Dawidek wrote:

Hi.

I've just committed Capsicum sandboxing for the dhclient(8).
Let me know (ideally by sending e-mail to current@ and CCing me) if you
notice any weird behaviour.

The work was sponsored by the FreeBSD Foundation.


It broke running dhclient on igb0 for me.  It says interface not found
or something to that effect.

Can I help somehow?

Basically just ifconfig down igb0 then try to run dhclient.  It will
not work.  If you up the interface and then run it, it is OK.

See attached image.

Thanks for the report. Could you try this patch?

http://people.freebsd.org/~pjd/patches/dhclient.c.patch



Thanks Pawel,

That fixes it for me.  I see it's also already committed.

Sorry for taking so long to respond, I think we're on opposite time of 
day. :)


-Alfred

___
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: devd or dhclient or ifconfig behavior seems broken

[Steve Kargl]

On Thu, Jul 04, 2013 at 08:50:21AM -0500, Mark Felder wrote:
 Check the man page for dhclient.conf. You can use the supercede
 functionality to always force the settings you prefer.

Thanks for the suggestion.  I was trying to use resolvconf.conf
to put specific nameservers into resolv.conf, but dhclient (or
the dhcp server I currently hooked to) is nuking resolv.conf.

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

HEADSUP! dhclient(8) sandboxing.

[Pawel Jakub Dawidek]

Hi.

I've just committed Capsicum sandboxing for the dhclient(8).
Let me know (ideally by sending e-mail to current@ and CCing me) if you
notice any weird behaviour.

The work was sponsored by the FreeBSD Foundation.

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


pgpG83WhmJLcx.pgp
Description: PGP signature

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 freebsd-current@freebsd.org and leaving
 curr...@freebsd.org in the Cc list.

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

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