Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Tony Finch wrote: Terry Lambert [EMAIL PROTECTED] wrote: I can't wait for IPv6 stateless autoconfiguration plus SLPv2 so we can get rid of all this DHCP crap once and for all. 8-(. SLPv2 is used to find the gateway and DNS server, and after that, everything magically works. I thought that the gateway address is (already) set up using RFC 2461 router and prefix discovery. Won't work for any U.S. Cable modems or DSL, which is based on ATM (which is an NBMA-type link). It also doesn't work for ISDN (iDSL), which is an SDMS-type link and doesn't have full prefix information available. So basically, if you have broadband, it won't work. I think that any broadcast system, like 802.11a, 802.11b, 802.11g, Motorolla Canopy, etc.. will also have issues, since the machines are implicitly multihomed for the nearest one. Finally, I haven't seen a router with ND turned on, if it was even supported, so it wouldn't advertise or respond to any solicitations to advertise (basically, you'd end up with an ability to use this to fire off indirect DOS attacks against third parties, so it tends to be disabled, or at least that was the explanation I was given). Basically, this leaves the client machine playing by the ND rules in the INCOMPLETE state, with no one to talk to. Microsoft actually solved this problem for IPv4 in link.local with their Internet Connection Sharing product at one time, but then went back to DHCP in later releases for reasons unknown (maybe because of 802.11 base-station-mode cards becoming available for Windows... who knows?). In any case, ND is kind of like DHCP, in that explicit support for the protocol is needed in order for both the client and server to communicate, which is kind of what I thought people needed to get away from when I was talking about losing DHCP. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Hi, Odd: %%% # cat /etc/sleep_dhclient #!/bin/sh omshell /dev/null EOF connect new control open set state = 3 update close EOF # cat /etc/wakeup_dhclient #!/bin/sh omshell /dev/null EOF connect new control open set state = 4 update close EOF %%% This was working fine for me a few months ago. It still does - my fault. Looks like I forgot update :P and with state 2 I did that. But the interface adding does still not work. Maybe a different syntax than this ? connect new interface open set rl0 = up; update close Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Wed, Jul 30, 2003 at 08:52:19AM +0200, Martin Blapp wrote: But the interface adding does still not work. Maybe a different syntax than this ? connect new interface open set rl0 = up; update close I think you want this syntax (although I still couldn't get it to work): connect new interface set name = rl0 open set state = up update close -Dom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, Jul 29, 2003 at 10:18:05PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Blapp [EMAIL PROTECTED] writes: : Hi Folks, : : I had a closer loom at the OMAPI stuff in dhclient. : : Just to say, I'm very disappointed. The only objects that exist are: : control and interface. The later is not inplemented at all. : It pretends to work, but if you look at the source there are : stubs only :P. : : control does only release leases and exit (state 2), I never managed to make : dhclient sleep (state 3) and wake up (state 2). : : It seems that the whole implementation is only a proof of concept : and not very functional at all, at least for the client side, dhcpd : may be different. : : I'll think about how we can solve this differently. This : really sucks ! That's why I start/kill dhclient from pccard_ether. The trouble with that is when you have one fixed interface and one from a pccard. You want the fixed interface to be running dhcp continuously, and not have it interrupted when the pccard is plugged in. I guess that we could do this by running a per-interface dhclient, but I've not had much success with that in the past. I'd like to talk about how that interacts with laptop suspend behaviour, but given that my laptop still can't resume properly, I'm inclined to leave it for the moment. ;-) -Dom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Terry Lambert [EMAIL PROTECTED] wrote: I can't wait for IPv6 stateless autoconfiguration plus SLPv2 so we can get rid of all this DHCP crap once and for all. 8-(. SLPv2 is used to find the gateway and DNS server, and after that, everything magically works. I thought that the gateway address is (already) set up using RFC 2461 router and prefix discovery. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: NORTHWEST 3 OR 4 FALLING VARIABLE 2 OR 3 FOR A TIME THEN GRADUALLY INCREASING SOUTH OR SOUTHEAST 3 OR 4. SHOWERS WITH A RISK OF SOME FOG PATCHES AT FIRST, BECOMING FAIR FOR A TIME BUT FURTHER RAIN LATER. GOOD OCCASIONALLY MODERATE IN RAIN AND SHOWERS, LOCALLY POOR IN ANY FOG PATCHES. SLIGHT BECOMING SLIGHT OR MODERATE. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, 29 Jul 2003, Terry Lambert wrote: This is part of the problem. The other parts are that this is really networking code, and should be a separate thing, if possible, and, as Martin just pointed out, the OMAPI stuff is not really cooked yet. Hence the notion of a neteventd -- I don't really mind what container it's in, as long as its structured around the network-centric pieces. It's really a lot easier the process a small list of events in dhacpd as a result of a kqueue or kqueue/select combo, if you want to avoid rewriting as much code as humanly possible, and still be able to pull this feature out of the project. Absolutely agreed. If OMAPI is working well, that may well provide a lot of what we want. One benefit to central management of the network configuration would be that we'd get things like GUI control and profiles a lot more easily. I still haven't been able to repeat your test; are you sure you are listening on a routing socket for the configuration change events? Maybe I'm doing something silly with my dumb little test program that you aren't doing with yours? I'm not seeing my Linksys my 3COM interfaces showing up and disappearing as kevents, but they are definitely still being seen by the laptop. Maybe it's my local hacks to make it work at all (it's an older Sony VAIO PCG-XG29). I can't speak to your configuration, but I can describe mine :-). I've tested two different situations with route monitor creation and removal of virtual interfaces (in this case, vlan interfaces), and physical interfaces (in this case, my wi0 card in my notebook). Both appear to be generating proper notifications during arrival and departure. The only events that I expected to see, but didn't, were IPv6 link layer address arrival and departure. I ran these tests with 5.0-CURRENT from around July 3, but I seem to recall seeing this work properly previously. I don't have any RELENG_4 boxes with removable physical interfaces at this point. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Martin Blapp wrote: I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. [ ... ] If there are other ideas, I'm open to them. You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, Jul 29, 2003 at 09:56:48AM +0200, Martin Blapp wrote: I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. Yay! This bites me badly on my laptop with a permanent fxp0 and a sometimes-present wi0. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. X = Link on IF + = Interface gets added or has new link - = Interface gets removed or lost link IF1 IF2 GW1 GW2 --- X X X + X - X X + X X Too this functionality to dhclient, there is only one way to do it. the ISC-dhclient package offers a OMAPI Command Shell omsshell(1). There you can add new interfaces or even remove existing ones. The work that needs to be done is: - Adding a unix domain socket to OMAPI, so root (or a choosen user) can access dhclient (or dhcpd) on the local machine without authentification. You can get omshell working without auth over tcp/ip - I managed this today when playing. But a unix domain socket would be nicer because the dhclient server binds to INADDR_ANY by default. - Providing the omshell scripts for adding and removing interfaces, adding new default gateways on interface removal etc ... - Change our infrastructure (devd, rc.d/dhclient script) to use them. If there are other ideas, I'm open to them. At present, dhclient gets given a list of interfaces at startup-time. Would it be better to start it in no-interfaces mode (-n -w) and dynamically add /all/ interfaces using omshell? Another (loosely related) thing is that we should be able to use omshell to tell dhclient to pause before going into suspend. This is hinted at in the dhclient man page, but it would be good to get it into the standard infrastructure. -Dom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Hi, can access dhclient (or dhcpd) on the local machine without authentification. You can get omshell working without auth over tcp/ip - I managed this today when playing. But a unix domain socket would be nicer because the dhclient server binds to INADDR_ANY by default. Cool. Do you have any pointers for me to try ? Little example etc ? At present, dhclient gets given a list of interfaces at startup-time. Would it be better to start it in no-interfaces mode (-n -w) and dynamically add /all/ interfaces using omshell? Exactly. Starting dhclient as a daemon without any interfaces. And just use omshell to add/remove interfaces. Another (loosely related) thing is that we should be able to use omshell to tell dhclient to pause before going into suspend. This is hinted at in the dhclient man page, but it would be good to get it into the standard infrastructure. Yup, that makes sence. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, Jul 29, 2003 at 02:01:36PM +0200, Martin Blapp wrote: can access dhclient (or dhcpd) on the local machine without authentification. You can get omshell working without auth over tcp/ip - I managed this today when playing. But a unix domain socket would be nicer because the dhclient server binds to INADDR_ANY by default. Cool. Do you have any pointers for me to try ? Little example etc ? /etc/dhclient.conf contains: omapi port 7911; Then, as root: # dhclient -n -w And in another terminal: % netstat -an | grep -w 7911 tcp4 0 0 *.7911 *.* LISTEN % omshell connect obj: null new control obj: control open obj: control state = 00:00:00:00 set state = 2 obj: control state = 2 update obj: control state = 2 At this point, go back to the other window and notice that dhclient hs terminated. I haven't played much further than this yet, though. The only other thing I noticed is that getting a list of what objects are present doesn't seem to be supported. Well, I couldn't see how to do it... -Dom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, 29 Jul 2003, Terry Lambert wrote: Martin Blapp wrote: I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. [ ... ] If there are other ideas, I'm open to them. You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Some of those events already exist for routing sockets, so in a worst case scenario, you can hook up a routing socket to a kqueue :-). Martin -- you might want to try the route monitor command sometime and take a look at the vent stream there for things to consider. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Robert Watson wrote: [ ... ] If there are other ideas, I'm open to them. You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Some of those events already exist for routing sockets, so in a worst case scenario, you can hook up a routing socket to a kqueue :-). Martin -- you might want to try the route monitor command sometime and take a look at the vent stream there for things to consider. Does that work if you don't have an IP address assigned to the interface at all yet? I was under the impression that it only sent out route change events (maybe I need to update my copy of the -current sources, though). What I was talking about is the idea that naked interface (0.0.0.0) arrivals and departures could be signalled, which would cause dhclient to try to get a lease on the interface. I'm afraid there's still a chicken-and-egg problem over devices that you want to be able to come and go, without attempting to get a lease. Probably the way to handle them is with an explicit not this device list, since it would let unknown devices just work by default, which is kind of what you want. Presumably, if you don't want a lease it's because you've got a static assignment for that particular device that you want used instead. I can't wait for IPv6 stateless autoconfiguration plus SLPv2 so we can get rid of all this DHCP crap once and for all. 8-(. SLPv2 is used to find the gateway and DNS server, and after that, everything magically works. If you get a lease in a zone, then because the forward record exists (because you have a Cert. for your own zone, the local DNS server should be willing to perform updates for your reverse record which it knows matcheds the forward record that lives in its zone but exists back on your home domain. Of course, this only works with IPv6, unless you use IPv4 with a link.local net plus integrated NAT in the gateway box. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, 29 Jul 2003, Terry Lambert wrote: Some of those events already exist for routing sockets, so in a worst case scenario, you can hook up a routing socket to a kqueue :-). Martin -- you might want to try the route monitor command sometime and take a look at the vent stream there for things to consider. Does that work if you don't have an IP address assigned to the interface at all yet? I was under the impression that it only sent out route change events (maybe I need to update my copy of the -current sources, though). What I was talking about is the idea that naked interface (0.0.0.0) arrivals and departures could be signalled, which would cause dhclient to try to get a lease on the interface. got message of size 24 on Tue Jul 29 13:27:59 2003 RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 6, what: arrival got message of size 96 on Tue Jul 29 13:28:45 2003 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 24 on Tue Jul 29 13:28:45 2003 RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 6, what: departure The event that you currently have to get using kqueue() is the link state, which isn't announced using routing sockets. If only for consistency, I'd like it if there were an ifnet level announcement in routing sockets for a link state change on capable interfaces. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Terry Lambert wrote: Martin Blapp wrote: I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. [ ... ] If there are other ideas, I'm open to them. You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Instead of just adding the stuff to devd? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Some people have parts that are so private they themselves have no knowledge of them. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, 29 Jul 2003, Daniel C. Sobral wrote: You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Instead of just adding the stuff to devd? Currently, devd is in the business of dealing with attachment and removal from the hardware management subsystem. Network subsystem events, such as interface has arrived are semantically different, but close enough in many cases. In the past, routing sockets have been the means by which topology-relevant changes are announced to the user processes. More recently, kqueue has permitted monitoring of a plethora of event types. I think there's a decent argument for a neteventd, perhaps integrated as a thread into devd, listening on network events rather than device attach/detach events. The only real problem is that it would be very nice if the DHCP client code were available in a library so it could be linked into a network event manager. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Hi Folks, I had a closer loom at the OMAPI stuff in dhclient. Just to say, I'm very disappointed. The only objects that exist are: control and interface. The later is not inplemented at all. It pretends to work, but if you look at the source there are stubs only :P. control does only release leases and exit (state 2), I never managed to make dhclient sleep (state 3) and wake up (state 2). It seems that the whole implementation is only a proof of concept and not very functional at all, at least for the client side, dhcpd may be different. I'll think about how we can solve this differently. This really sucks ! Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Wed, 30 Jul 2003, Martin Blapp wrote: control does only release leases and exit (state 2), I never managed to make dhclient sleep (state 3) and wake up (state 2). Odd: %%% # cat /etc/sleep_dhclient #!/bin/sh omshell /dev/null EOF connect new control open set state = 3 update close EOF # cat /etc/wakeup_dhclient #!/bin/sh omshell /dev/null EOF connect new control open set state = 4 update close EOF %%% This was working fine for me a few months ago. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : : On Tue, 29 Jul 2003, Daniel C. Sobral wrote: : : You could add kevents for interface arrival and departure, and : add a kqueue to the dhcpd to catch the arrival/departure events, : and then just act on them. : : Instead of just adding the stuff to devd? : : Currently, devd is in the business of dealing with attachment and removal : from the hardware management subsystem. currently, that's true. : Network subsystem events, such as : interface has arrived are semantically different, but close enough in : many cases. I've been pondering making devd grok such events, as well as other power events. Eg, it will be a place that acpi could route acpi events to replace apm. : In the past, routing sockets have been the means by which : topology-relevant changes are announced to the user processes. More : recently, kqueue has permitted monitoring of a plethora of event types. I : think there's a decent argument for a neteventd, perhaps integrated as a : thread into devd, listening on network events rather than device : attach/detach events. I think that would be a good idea Don't know if there's a 'thread' or a virtual thread-like thing. : The only real problem is that it would be very nice : if the DHCP client code were available in a library so it could be linked : into a network event manager. It would make things a lot easier. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
In message: [EMAIL PROTECTED] Martin Blapp [EMAIL PROTECTED] writes: : : Hi Folks, : : I had a closer loom at the OMAPI stuff in dhclient. : : Just to say, I'm very disappointed. The only objects that exist are: : control and interface. The later is not inplemented at all. : It pretends to work, but if you look at the source there are : stubs only :P. : : control does only release leases and exit (state 2), I never managed to make : dhclient sleep (state 3) and wake up (state 2). : : It seems that the whole implementation is only a proof of concept : and not very functional at all, at least for the client side, dhcpd : may be different. : : I'll think about how we can solve this differently. This : really sucks ! That's why I start/kill dhclient from pccard_ether. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Daniel C. Sobral wrote: Terry Lambert wrote: You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Instead of just adding the stuff to devd? The entire dhcpd code? Isn't that what dhcpd is for? Is devd a kitchen sink program? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Robert Watson wrote: On Tue, 29 Jul 2003, Daniel C. Sobral wrote: You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Instead of just adding the stuff to devd? Currently, devd is in the business of dealing with attachment and removal from the hardware management subsystem. Network subsystem events, such as interface has arrived are semantically different, but close enough in many cases. In the past, routing sockets have been the means by which topology-relevant changes are announced to the user processes. More recently, kqueue has permitted monitoring of a plethora of event types. I think there's a decent argument for a neteventd, perhaps integrated as a thread into devd, listening on network events rather than device attach/detach events. The only real problem is that it would be very nice if the DHCP client code were available in a library so it could be linked into a network event manager. This is part of the problem. The other parts are that this is really networking code, and should be a separate thing, if possible, and, as Martin just pointed out, the OMAPI stuff is not really cooked yet. It's really a lot easier the process a small list of events in dhacpd as a result of a kqueue or kqueue/select combo, if you want to avoid rewriting as much code as humanly possible, and still be able to pull this feature out of the project. I still haven't been able to repeat your test; are you sure you are listening on a routing socket for the configuration change events? Maybe I'm doing something silly with my dumb little test program that you aren't doing with yours? I'm not seeing my Linksys my 3COM interfaces showing up and disappearing as kevents, but they are definitely still being seen by the laptop. Maybe it's my local hacks to make it work at all (it's an older Sony VAIO PCG-XG29). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
