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

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 docu

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

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 d

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

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

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

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 -

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

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 patche

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

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

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

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

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

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 ne

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

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

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

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

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

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

Re: VNET jail and dhclient

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 C

Re: VNET jail and dhclient

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

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

Re: VNET jail and dhclient

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

Re: VNET jail and dhclient

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

Re: VNET jail and dhclient

Hello! On Tue, Oct 10, 2017 at 8:24 PM, Kristof Provost 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 lapt

Re: VNET jail and dhclient

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

Re: VNET jail and dhclient

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 inter

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

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 ampdude

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

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

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

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 vn

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

> 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 fails: can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor

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

Re: r299512 breaks dhclient on some networks

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

Re: r299512 breaks dhclient on some networks

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,

Re: r299512 breaks dhclient on some networks

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 arr

Re: r299512 breaks dhclient on some networks

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 in

Re: r299512 breaks dhclient on some networks

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

Re: r299512 breaks dhclient on some networks

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

Re: r299512 breaks dhclient on some networks

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 s

Re: r299512 breaks dhclient on some networks

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

Re: r299512 breaks dhclient on some networks

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 be

r299512 breaks dhclient on some networks

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 cl

dhclient/unbound_local/forward.conf

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

Re: panic: negative refcount after dhclient during boot

On Wed, Jul 8, 2015 at 5:09 PM, Ermal Luçi wrote: > > > On Tue, Jul 7, 2015 at 6:11 PM, Rink Springer 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, Rin

Re: panic: negative refcount after dhclient during boot

On Tue, Jul 7, 2015 at 6:11 PM, Rink Springer 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 wrote: > > > > > > > Hi all, > > > > > > > > On my F

Re: panic: negative refcount after dhclient during boot

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 wrote: > > > > > Hi all, > > > > > > On my FreeBSD/mips machine (it's a RouterStation Pro), I get the > > > follow

Re: panic: negative refcount after dhclient during boot

On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote: > On Jul 5, 2015, at 8:16, Rink Springer 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.

Re: panic: negative refcount after dhclient during boot

On Jul 5, 2015, at 8:16, Rink Springer 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 he

panic: negative refcount after dhclient during boot

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

panic: negative refcount after dhclient during boot

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

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

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

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

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

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

ine 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 (res

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

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

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

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 >

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

> 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

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

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

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

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

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

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 ind

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

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 aff

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

, 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

Re: dhclient sucks cpu usage...

age 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

Re: dhclient sucks cpu usage...

m 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, bu

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

t 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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

ver 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

dhclient sucks cpu usage...

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

Re: dhclient can't limit bpf descriptor?

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

Re: dhclient can't limit bpf descriptor?

On Dec 14, 2013, at 3:16 PM, Darren Pilgrim wrote: > On 12/14/2013 12:12 PM, Tim Kientzle wrote: >> Opened up an old VM from a month or so ago (r257910) and dhclient won’t >> start. >> >> Specifically, dhclient complains (when run by root): >> “can’t

Re: dhclient can't limit bpf descriptor?

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

dhclient can't limit bpf descriptor?

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

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

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 >

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

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

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

nted, 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 momen

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

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 t

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

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

dhclient failure with Realtek 8111E Ethernet on new MSI motherboard

(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

Re: dhclient: send_packet: No buffer space available

On 1 November 2013 08:45, hiren panchasara wrote: > On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz wrote: >> >> >> Hello, >> >> Since I have updated my netbook to r255948 I see from time to time in >> the console the message: >> >> Nov 1 1

Re: dhclient: send_packet: No buffer space available

On Fri, Nov 1, 2013 at 8:32 AM, Matthias Apitz wrote: > > > Hello, > > Since I have updated my netbook to r255948 I see from time to time in > the console the message: > > Nov 1 16:20:28 tiny-r255948 dhclient[696]: send_packet: No buffer space > available Yes, thi

dhclient: send_packet: No buffer space available

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

dhclient failure with Realtek 8111E Etnernet on new MSI motherboard

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

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

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

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

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

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 d

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

On 29 Jul 2013, at 07:00, 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

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

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

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

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

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

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

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

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

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

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 wrote: > On Fri, Jul 26, 2013 at 02:34:51PM +0200, Jean-Sébastien Pédron wrote: >> Hi! >> >> At $WORK, we use 802.1X

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

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

802.1X: dhclient started before the auth. process ends

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 t

Re: devd or dhclient or ifconfig behavior seems broken

f, 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-curre

Re: HEADSUP! dhclient(8) sandboxing.

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 m

Re: devd or dhclient or ifconfig behavior seems broken

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

Re: HEADSUP! dhclient(8) sandboxing.

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 mai

Re: HEADSUP! dhclient(8) sandboxing.

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 wei

Re: HEADSUP! dhclient(8) sandboxing.

On Thu, 4 Jul 2013 11:30:46 +0200 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 d

Re: HEADSUP! dhclient(8) sandboxing.

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

Re: HEADSUP! dhclient(8) sandboxing.

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 yo

devd or dhclient or ifconfig behavior seems broken

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 a

Re: HEADSUP! dhclient(8) sandboxing.

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 dhclie

HEADSUP! dhclient(8) sandboxing.

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

Re: dhclient cause up/down cycle after 239356 ?

On Wednesday, August 22, 2012 9:35:34 pm Peter Jeremy wrote: > On 2012-Aug-22 15:35:01 -0400, John Baldwin wrote: > >Hmm. Perhaps we could use a debouncer to ignore "short" link flaps? Kind of > >gross (and OpenBSD doesn't do this). For now this change basically ignores > >link up events if the

  1   2   3   >