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 documented and explained

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 did you learn through

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.

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

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

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 network

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 all.log (I

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 Cannot

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

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

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

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

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

ower 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: /et

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

gdomain 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] d

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

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

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

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

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 d

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

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

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

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

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

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

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

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

Re: panic: negative refcount after dhclient during boot

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,

Re: panic: negative refcount after dhclient during boot

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,

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

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

panic: negative refcount after dhclient during boot

/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

panic: negative refcount after dhclient during boot

/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

Re: panic: negative refcount after dhclient during boot

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

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

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

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

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

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

, 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

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

, 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

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

. 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

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

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

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

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

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

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

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

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

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

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

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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

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

Re: dhclient sucks cpu usage...

% 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

Re: dhclient sucks cpu usage...

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

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 instantly

Re: dhclient sucks cpu usage...

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

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. What does this mean? I

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

Re: dhclient can't limit bpf descriptor?

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

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

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

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

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

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 to the re(4) bug

dhclient failure with Realtek 8111E Ethernet on new MSI motherboard

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

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

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

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

Re: dhclient: send_packet: No buffer space available

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

Re: dhclient: send_packet: No buffer space available

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

dhclient failure with Realtek 8111E Etnernet on new MSI motherboard

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

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

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

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

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

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

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

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

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 15:39:46

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 quickly, ie. before dhclient receives

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 quickly, ie. before dhclient receives

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

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

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

802.1X: dhclient started before the auth. process ends

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

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 dhclient

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

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 you notice any weird behaviour

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 commits chain case

Re: HEADSUP! dhclient(8) sandboxing.

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

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 weird behaviour. I don't test one

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 mailing

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

Re: devd or dhclient or ifconfig behavior seems broken

, 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

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

Re: dhclient cause up/down cycle after 239356 ?

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

  1   2   3   >