# netplugd + baselayout-1.12.x + preup function [solved]

## seppelrockt

I recently switched to the ~x86 baselayout cause I want to use netplugd for my LAN. I need to run xsupplicant on the LAN interface (it's a wired interface, no WLAN) to do EAP-MD5 authetification (for internet connectivity over my University).

The init script for xsupplicant doesn't work properly (can't stop the xsupplicant) and my networking card needs some spezial care so I ended up with the following preup funktion in /etc/conf.d/net:

```
# This block is for authetification with xsupplicant

#***************************************************

# Set eth0 to "PROMISC" mode to work properly with dhcpcd

preup() {

        if [[ ${IFACE} == "eth0" ]]; then

                if [ -f /var/run/xsupplicant ]; then

                        rm /var/run/xsupplicant

                fi

                einfo "Start xsupplicant on ${IFACE}"

                xsupplicant -i eth0 > /dev/null

                einfo "Put ${IFACE} into 'PROMISC' mode"

                interface_set_flag "${IFACE}" promisc true

        fi

}

```

The idea is that I don't have to wait for the xsupplicant on boot when there is no cable pluged. But this doesn't work cause the preup function is run BEFORE netplugd is started for eth0 and I guess it might not be possible for netplugd to decide whether eth0 in plugged before the preup "initialisation" is run (here: authentification). Now I hope that this is not true in my case and somebody can tell me how I can first start netplugd and then run the preup.

I want to switch to wpa_supplicant for the authentification on wired LAN but this feature is just work in progress and I couldn't set my LAN up when I tried wpa_supplicant last time (0.4.2 or something) - but I will check in the next days whether it works with 0.4.5. Any ideas how to integrate the whole task in conf.d/net without preup but instead using the wpa_supplicant module is highly welcome.Last edited by seppelrockt on Fri Nov 18, 2005 6:48 pm; edited 1 time in total

----------

## UberLord

I guess you would have to create a xsupplicant net-scripts module - you can use the ones in /lib/rcscripts/net.modules.d as a basis to show you how to write one. I see you're already using some baselayout functions, so you have a good starting point  :Smile: 

If you write one and get it working, please open a bug on bugs.gentoo.org, attach the module and assign the bug to uberlord@gentoo.org and if it's good enough it will go into baselayout  :Smile: 

----------

## seppelrockt

OK, i might try this. But first I need some more infos about the net part of baselayout - is there any knowledge source beside studing the other rcscripts? The xsupplicant rcscript has to do all the things I previewsly did with the preup, right? Be prepared to be asked thousands of questions in the next days ... well, I hope only questions that can not be answered by docs.

However I am not sure whether I try to get wpa_supplicant working cause I don't like xsupplicant much and it looks like it will have a not so bright future in Gentoo (no versions bumbs, improvements). In this case is there still a new rcscript needed or will the one that is already there work for wirde interfaces, too? In case it have to be tweaked would you prefere to split the wpa_supplicant rcscript into wired/wireless or can all this be handles in one rcscript?

----------

## UberLord

 *seppelrockt wrote:*   

> OK, i might try this. But first I need some more infos about the net part of baselayout - is there any knowledge source beside studing the other rcscripts?

 

Besides studying the source, you can always ask me - preferably on irc.freenode.net #gentoo-base

 *Quote:*   

> The xsupplicant rcscript has to do all the things I previewsly did with the preup, right?

 

It just has to start and stop xsupplicant and handle any command line options

 *Quote:*   

>  Be prepared to be asked thousands of questions in the next days ... well, I hope only questions that can not be answered by docs.

 

Sure, but on irc unless I'm not there.

 *Quote:*   

> 
> 
> However I am not sure whether I try to get wpa_supplicant working cause I don't like xsupplicant much and it looks like it will have a not so bright future in Gentoo (no versions bumbs, improvements). In this case is there still a new rcscript needed or will the one that is already there work for wirde interfaces, too? In case it have to be tweaked would you prefere to split the wpa_supplicant rcscript into wired/wireless or can all this be handles in one rcscript?

 

I have no plans to make wpa_supplicant net module work on wired interfaces as it cannot work on wired interfaces itself.

----------

## seppelrockt

 *UberLord wrote:*   

> I have no plans to make wpa_supplicant net module work on wired interfaces as it cannot work on wired interfaces itself.

 

Wrong - wpa_supplicant >= 0.4.0 can be used for all wired interfaces when invokrd with: wpa_supplicant -Dwired

----------

## UberLord

 *seppelrockt wrote:*   

> Wrong - wpa_supplicant >= 0.4.0 can be used for all wired interfaces when invokrd with: wpa_supplicant -Dwired

 

Heh - so it can!

I'll see if I can tailor the wpa_supplicant module for it this week.

----------

## UberLord

OK, I've started working on a patch to allow wpa_supplicant to work on wired interfaces.

As ifplugd and netplug also control wired interfaces, it was a little tricker than I thought.

http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-wired.patch

It should work, please test and post feedback  :Smile: 

----------

## seppelrockt

 *UberLord wrote:*   

> OK, I've started working on a patch to allow wpa_supplicant to work on wired interfaces.
> 
> As ifplugd and netplug also control wired interfaces, it was a little tricker than I thought.
> 
> http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-wired.patch
> ...

 

That's simply amazing - I was very happy when I found a new ebuild for wpa_supplicant-0.4.5 in portage and some seconds later you provide me with a patch for baselayout. I will test both today in the afternoon and report back. Thanks so far for your work!

----------

## UberLord

Please note that I have no equipment to test wpa_supplicant over wired ethernet, but the daemons look like they're starting and stopping properly  :Smile: 

I just blogged about writing this patch too

So give me some feedback on it  :Smile: 

----------

## UberLord

Patch updated - it works on wireless cards again!

----------

## seppelrockt

Is there a way to tell wpa_supplicant from inside /etc/conf.d/net which conf to use? I ask cause I use wpa_supplicant for both wired (AEp-MD5 Auth.) and wireless (WPA with preshared key) interface and have to define different conf files (at least I think so).

EDIT: Doesn't look so good atm - I am still fighting to get wpa-supplicant to work with wired LAN (manually, not with baselayout). I first have to manage this before I can check the baselayout stuff  :Sad: 

EDIT2: It's a little late now so that might be the reason why I didn't realize that everything works fine with wpa_supplicant - is just doesn't tell me anything even with the -dd debug flag *LOL*. So let's check the baselayout patch.

----------

## seppelrockt

Yeaaaah, it works - sort of. But it "appears" not to work cause the status messages might need some more tweaking. I get the "starting netplug on eth0" message and then "failed to configure eth0 in the background".  This is not correct cause ifconfig shows that everything worked fine (eth0 has an IP) or sometimes it needs a little longer to get one, but it always works. So maybe you could put your hands on the backgrounding messages to make this already great peace of work perfect (I don't have a good idea in what way it should change atm, I have to say).

Here is some dmesg output in case this helps:

```
Oct 18 00:30:48 whiterabbit netplugd[10592]: eth0: state ACTIVE flags 0x00001063 UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST -> 0x00001022 BROADCAST,NOTRAILERS,MULTICAST

Oct 18 00:30:48 whiterabbit netplugd[13834]: /etc/netplug.d/netplug eth0 probe -> pid 13834

Oct 18 00:30:48 whiterabbit device eth0 left promiscuous mode

Oct 18 00:30:48 whiterabbit netplugd[10592]: eth0: state PROBING pid 13834 exited status 0

Oct 18 00:30:48 whiterabbit netplugd[10592]: caught signal 15 - exiting

Oct 18 00:31:27 whiterabbit b44: eth0: Link is up at 100 Mbps, full duplex.

Oct 18 00:31:27 whiterabbit b44: eth0: Flow control is off for TX and off for RX.

Oct 18 00:31:27 whiterabbit netplugd[14301]: eth0: state DOWN flags 0x00001023 UP,BROADCAST,NOTRAILERS,MULTICAST -> 0x00001063 UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST

Oct 18 00:31:27 whiterabbit netplugd[14312]: /etc/netplug.d/netplug eth0 in -> pid 14312

Oct 18 00:31:34 whiterabbit rc-scripts: Failed to configure eth0 in the background

Oct 18 00:31:37 whiterabbit NETDEV WATCHDOG: eth0: transmit timed out

Oct 18 00:31:37 whiterabbit b44: eth0: transmit timed out, resetting

Oct 18 00:31:37 whiterabbit b44: eth0: Link is down.

Oct 18 00:31:37 whiterabbit netplugd[14301]: eth0: state INNING flags 0x00001063 UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST -> 0x00001023 UP,BROADCAST,NOTRAILERS,MULTICAST

Oct 18 00:31:40 whiterabbit b44: eth0: Link is up at 100 Mbps, full duplex.

Oct 18 00:31:40 whiterabbit b44: eth0: Flow control is off for TX and off for RX.

Oct 18 00:31:40 whiterabbit netplugd[14301]: eth0: state WAIT_IN flags 0x00001023 UP,BROADCAST,NOTRAILERS,MULTICAST -> 0x00001063 UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST

Oct 18 00:31:40 whiterabbit device eth0 entered promiscuous mode

Oct 18 00:31:48 whiterabbit rc-scripts: Failed to configure eth0 in the background

Oct 18 00:31:48 whiterabbit netplugd[14301]: eth0: state WAIT_IN pid 14312 exited status 0

Oct 18 00:31:48 whiterabbit netplugd[14788]: /etc/netplug.d/netplug eth0 out -> pid 14788

Oct 18 00:31:49 whiterabbit netplugd[14301]: eth0: state OUTING pid 14788 exited status 0

Oct 18 00:31:49 whiterabbit netplugd[15246]: /etc/netplug.d/netplug eth0 in -> pid 15246

Oct 18 00:32:02 whiterabbit netplugd[14301]: eth0: state INNING pid 15246 exited status 0

```

----------

## UberLord

OK, could do you the following please?

```
ifconfig eth0 up

wpa_supplicant -c /etc/wpa_supplicant.cont -i eth0 -D wired
```

And while that chugs away, run this in another terminal

```
wpa_cli -i eth0 status
```

Run that last command say once every 10 seconds for minute or so and then post the results - but be nice and scrub any duplicate outputs!

I'm guessing that wpa_supplicant isn't assoication/connecting to your IEEE server.

I must see if I can set one up myself!

----------

## seppelrockt

 *UberLord wrote:*   

> I'm guessing that wpa_supplicant isn't assoication/connecting to your IEEE server.
> 
> I must see if I can set one up myself!

 

I'm not sure if I understand you right but let me assure you that from the wpa_supplicant side everithing works right - I am using the inet connection of my university now trough which I am authentificated with wpa_supplicant (used with baselayout integration). From the dmesg I've posted yesterday only the last part is relevant (the other stuff was from testing and might be confusing). This is what I have always in dmesg on boot:

```
Oct 18 00:31:48 whiterabbit rc-scripts: Failed to configure eth0 in the background 

Oct 18 00:31:48 whiterabbit netplugd[14301]: eth0: state WAIT_IN pid 14312 exited status 0 

Oct 18 00:31:48 whiterabbit netplugd[14788]: /etc/netplug.d/netplug eth0 out -> pid 14788 

Oct 18 00:31:49 whiterabbit netplugd[14301]: eth0: state OUTING pid 14788 exited status 0 

Oct 18 00:31:49 whiterabbit netplugd[15246]: /etc/netplug.d/netplug eth0 in -> pid 15246 

Oct 18 00:32:02 whiterabbit netplugd[14301]: eth0: state INNING pid 15246 exited status 0
```

EDIT: Downloading KDE stuff right now and than have to go to work - I'll post the info you've requested as soon as possible.

----------

## UberLord

You probably need to give the script more time - netplug times out after 10 seconds by default. That's probably not enough time to spawn another net.eth0 and launch wpa_supplicant and then let that launch net.eth0 again.

```
plug_timeout_eth0="20"
```

Try timeouts of 20, 30, 40, 50, then 60 seconds. I'd be interested to know what the timeout threshold is btw  :Smile: 

Or you could set the timeout to -1 which means it isn't even go to bother waiting. This results in a faster boot time. The downside is that you either need to call "rc" in a postup to start net services as unless you set RC_NET_STRICT_CHECKING to "lo" or "none" in /etc/conf.d/rc

----------

## seppelrockt

OK if played a little with the plug_timeout and when I set it to 40 or more I doesn't timeout. As I already  use RC_NET_STRICT_CHECKING="lo" I finaly changed plug_timeout to -1 so netplug might finish it's task when KDE is loading  :Wink:  But I don't know if I like the warning message - a simple "backgrounding" or something might be a better solution. Is it realistic that one accidently puts in -1 and not with the idea to simple not wait?

Thanks again for this great solution - I plugged the cord off and on some times and everytime the connection was established PLUS /etc/init.d/net.eth0 shows the correct status in every situation. So I can finaly wipe out the nasty xsupplicant. And I didn't even need to so much for this improved situation (OK, I was called cheeky git on a public blog, but in this special case I dont care  :Wink: ).

Some questions remain: How to deal with the two wpa_supplicant interfaces eth0 (wired) and eth1 (WLAN)? Can I tell wpa_supplicant to use different conf files by passing the -c argument inside /conf.d/net?

What if both interfaces are active on the same time (I've read wpa_supplicant needs an -N switch in this case - do you have something like this in baselayout)?

I will invastigate in this questions in the afternoon and check carefully whether both interfaces work at the same time. Then I report back of cause and when everything works fine, I hope you can commit the patch to CVS soon.

After the feature hits portage I will write an article in the Wiki of the students appartements to tell the Gentoo people here how to use the new stuff.

----------

## UberLord

 *seppelrockt wrote:*   

> OK if played a little with the plug_timeout and when I set it to 40 or more I doesn't timeout. As I already  use RC_NET_STRICT_CHECKING="lo" I finaly changed plug_timeout to -1 so netplug might finish it's task when KDE is loading  But I don't know if I like the warning message - a simple "backgrounding" or something might be a better solution. Is it realistic that one accidently puts in -1 and not with the idea to simple not wait?

 

I'll review the warning ... no promises though

 *Quote:*   

> Some questions remain: How to deal with the two wpa_supplicant interfaces eth0 (wired) and eth1 (WLAN)? Can I tell wpa_supplicant to use different conf files by passing the -c argument inside /conf.d/net?

 

Erm no.

Actually I didn't think of that. Should be a simple fix though

 *Quote:*   

> What if both interfaces are active on the same time (I've read wpa_supplicant needs an -N switch in this case - do you have something like this in baselayout)?

 

We deal with this by launching a seperate wpa_supplicant daemon for each interface that requires it[/quote]

 *Quote:*   

> I hope you can commit the patch to CVS soon.

 

It's already in our svn repo (although slightly modified)  :Smile: 

----------

## UberLord

http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-conf.patch

Requires the earlier patch too.

----------

## ripper_svk

UberLord, could you estimate when will the patch be applied to baselayout in portage? i'm too dumb to use "patch" and a bit scared not to damage my system (i trust your patch, but i don't try myself to apply it correctly)

----------

## UberLord

Assuming you have baselayout-1.12.0_pre9-r1 installed ...

Make a backup of /lib/rcscripts/net.modules.d, then do this

```
cd /tmp

wget http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-wired.patch

wget http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-conf.patch

patch -p0 < wpa_supplicant-wired.patch

patch -p0 < wpa_supplicant-conf.patch

```

There you go.

If it fails for whatever reason, you can copy your backup of the net.modules.d folder

If that fails, simply emerge -av1 baselayout

----------

## seppelrockt

 *ripper_svk wrote:*   

> UberLord, could you estimate when will the patch be applied to baselayout in portage? i'm too dumb to use "patch" and a bit scared not to damage my system (i trust your patch, but i don't try myself to apply it correctly)

 

Live is all about learning new things on every corner ...

Are you with me?

1. quickpkg baselayout (packages a "backup" of your current baselayout install - if something goes wrong later)

2. Download patch

3. su - (become root)

3. 

```
cd /lib/rcscripts/netmodules.d/
```

4. 

```
patch -p1 </path/where/you/put/the/patch
```

5. Check if everything worked from the patch messages. if not read man patch or ask here

# Some explanations:

If you just want to patch on file with another it is simply 

```
patch original_file patchfile
```

But if you look at Uberlords patch you will see that it not one but tree or so patches concatenated to one file. Each of the patches in the file applies to another file inside /lib/rcscripts/netmodules.d. If you want to know the details look at the headers of the single patches (starting with the +++ and --- lines). In this case it is easy to let patch do the work recursive to the current directory by 

```
patch -p1 < patchfile
```

The -p is for stripping prefixes - please refer to the man cause I can't explain this very good in English (I'm German).

----------

## seppelrockt

 *UberLord wrote:*   

> http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-conf.patch
> 
> Requires the earlier patch too.

 

OK thanks, works with this lines in /etc/conf.d/net

```

wpa_supplicant_eth0="-Dwired -c/etc/wpa_supplicant.conf.wired"

wpa_supplicant_eth1="-Dipw -c/etc/wpa_supplicant.conf.wlan"

```

But I found out that I can not run eth0 and eth1 (aka wlan) at the same time cause both need a running wpa_supplicant and when eth0 is running:

```
~ # /etc/init.d/net.eth1 start

 * Starting eth1

 *   Starting wpa_supplicant on eth1 ...

/sbin/wpa_supplicant already running.          [ !! ]

```

----------

## UberLord

A patch that allows multiple instances of wpa_supplicant - requires wpa_supplicant-0.4.x as the 0.3.x branch does not work with pidfiles

http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-multiple.patch

----------

## seppelrockt

 *UberLord wrote:*   

> A patch that allows multiple instances of wpa_supplicant - requires wpa_supplicant-0.4.x as the 0.3.x branch does not work with pidfiles
> 
> http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-multiple.patch

 

Thank, will try this when I am at home in the afternoon.

When your three patches make in in SVN then baselayout will depend on wpa_supplicant >= 0.4.5 (older versions have some problems with wired interfaces still), right? This meants on the way to stabilize baselayout-1.12.x it's also important to stabilize the wpa_supplicant-0.4.5 (or greater).

----------

## UberLord

 *seppelrockt wrote:*   

> When your three patches make in in SVN then baselayout will depend on wpa_supplicant >= 0.4.5 (older versions have some problems with wired interfaces still), right? This meants on the way to stabilize baselayout-1.12.x it's also important to stabilize the wpa_supplicant-0.4.5 (or greater).

 

0.3.x will still work - you just can't run it on more than one interface. So technically, we don't need to stable 0.4.x with baselayout-1.12

----------

## seppelrockt

 *UberLord wrote:*   

>  *seppelrockt wrote:*   When your three patches make in in SVN then baselayout will depend on wpa_supplicant >= 0.4.5 (older versions have some problems with wired interfaces still), right? This meants on the way to stabilize baselayout-1.12.x it's also important to stabilize the wpa_supplicant-0.4.5 (or greater). 
> 
> 0.3.x will still work - you just can't run it on more than one interface. So technically, we don't need to stable 0.4.x with baselayout-1.12

 

OK, same for wired LAN - if you don't need it, you can stick with 0.3.x - if you want it you have to use the keyworded 0.4.5. Maybe you can point that out when the next version bump is done for baselayout in the changelog - just to prevent wrong complaints and bug reports (in case anybody else then me needs this features).

----------

## seppelrockt

Tested the patch and IT WORKS (tm). I had to adjust the dhcp on eth1 (WLAN) to do nodns and nogateway so that the internet stuff in still routed trough eth0 but that was no problem with the power of baselayout (that is well documented in /etc/conf.d/net.example).

Thank you so much Uberlord!

----------

## UberLord

Excellent news  :Smile: 

----------

## seppelrockt

Hmmm, is there a way to only use the dhcp_eth1="nodns nogateway" if 

a) eth0 AND eth1 are both up and running or

b) eth1 is connected to a specific essid?

The result of both approaches would be the same: at home I have inet over LAN so everything must be routed over eth0. At university I use WLAN (LAN is not plugged) thus routing over eth1.

----------

## UberLord

Why don't you try RC_AUTO_INTERFACE="yes" and then see what happens to your routing table and /etc/resolv.conf with both interfaces active  :Wink: 

----------

## ripper_svk

i've used the patches and they work. thank you!

----------

## seppelrockt

 *UberLord wrote:*   

> Why don't you try RC_AUTO_INTERFACE="yes" and then see what happens to your routing table and /etc/resolv.conf with both interfaces active 

 

Sometimes life is so simple  :Wink:  Works, great!

----------

## UberLord

 *seppelrockt wrote:*   

>  *UberLord wrote:*   Why don't you try RC_AUTO_INTERFACE="yes" and then see what happens to your routing table and /etc/resolv.conf with both interfaces active  
> 
> Sometimes life is so simple  Works, great!

 

With RC_AUTO_INTERFACE="yes" you get the Gentoo equivalent of NetworkManager minus the shiny GUI. And unlike NetworkManager, we actually work  :Smile: 

----------

## seppelrockt

Uberlord, if you have a minute time or two, could you please visite this post cause it might be related to baselayout 1.12.x? Thanks in advance!

----------

## seppelrockt

I tested the long awaited baselayout 1.12.0_pre10 and the patches made it in there exept the patch for multible wpa_supplicant.conf files that can be specified from within /etc/conf.d/net for every interface.

I hope you just forgot it and it will make into the _pre11 or even a fast _pre10-r1.

OT: I tried the PARALLEL_INIT thing or what it's called and the "serial" service can not be started at all. I wonder why I need this at all (it never came into my view before). Can I savely remove it from boot?

----------

## UberLord

 *seppelrockt wrote:*   

> I tested the long awaited baselayout 1.12.0_pre10 and the patches made it in there exept the patch for multible wpa_supplicant.conf files that can be specified from within /etc/conf.d/net for every interface.
> 
> I hope you just forgot it and it will make into the _pre11 or even a fast _pre10-r1.

 

Whups! I lost the patch as well - do you still have it to save me from writing it?

 *Quote:*   

> OT: I tried the PARALLEL_INIT thing or what it's called and the "serial" service can not be started at all. I wonder why I need this at all (it never came into my view before). Can I savely remove it from boot?

 

You can safely remove it - the serial init script has been moved to the serial package and is no longer in baselayout

----------

## seppelrockt

 *UberLord wrote:*   

>  *seppelrockt wrote:*   I tested the long awaited baselayout 1.12.0_pre10 and the patches made it in there exept the patch for multible wpa_supplicant.conf files that can be specified from within /etc/conf.d/net for every interface.
> 
> I hope you just forgot it and it will make into the _pre11 or even a fast _pre10-r1. 
> 
> Whups! I lost the patch as well - do you still have it to save me from writing it?

 

Here you go: wpa_supplicant-multiple.patch and wpa_supplicant-conf.patch

Friendly reminder: Did you change your mind about the error message when the timeout for an interface is set to -1? I still belive a simple "backgrounding ..." message is the better way to go  :Wink: 

----------

## UberLord

Thanks for that - they are definitely comitted to our tree now  :Smile: 

I have changed the message to a simple einfo "Backgrounding ..." and we now default to a -1 timeout  :Smile: 

I'll probably include this in a -r1 sometime soon

----------

## UberLord

Here's a patch that should apply cleanly to pre10

http://dev.gentoo.org/~uberlord/baselayout/wpa_supplicant-mulitple-conf.patch

I'm waiting on a futher pppd patch from mrness before I roll a pre10-r1

----------

## seppelrockt

 *UberLord wrote:*   

> Thanks for that - they are definitely comitted to our tree now 
> 
> I have changed the message to a simple einfo "Backgrounding ..." and we now default to a -1 timeout 
> 
> I'll probably include this in a -r1 sometime soon

 

Thanks, that's great news and all my wishes finaly came true  :Wink: 

Regarding the updated patch, do you want me to check it again or is this not nessecary? I'm asking because I did a symlink as workaround for the wpa_supplicant.conf and so I am to lasy to patch the baselayout (have a lot to do for university atm). My workaround would be enough for the time until -r1 is out. But if you want feedback, I will test it again.

----------

## UberLord

Yeah, please try it just to make sure  :Smile: 

Something else came up, so there will be an -r1, and probably before end of Friday

----------

## seppelrockt

 *UberLord wrote:*   

> Yeah, please try it just to make sure 
> 
> Something else came up, so there will be an -r1, and probably before end of Friday

 

Damn, you have been rooling out -r1 so fast that I didn't even had a chance to test the new patch. But given this patch is in the -r1 it's just fine, cause -r1 works great here. I guess I have to reboot just to see whether I see the "Backgrounding" message now  :Wink: 

Ones again a BIG THANK YOU!

----------

## UberLord

Just be aware of this bug

https://bugs.gentoo.org/show_bug.cgi?id=112088

It's been present in the 1.12 branch for sometime, but the change to default -1 timeouts has exposed it a little   :Confused: 

----------

## seppelrockt

 *UberLord wrote:*   

> Just be aware of this bug
> 
> https://bugs.gentoo.org/show_bug.cgi?id=112088
> 
> It's been present in the 1.12 branch for sometime, but the change to default -1 timeouts has exposed it a little  

 

I checked it on my system but I had to read the bug report twice to understand that they talk about net.ethX DEPENDEND services. Well, I do not have any of them and the interface itselve comes up nicely after restart.

My new idea is to write a vpnc module for baselayout during the next 2 weeks - do you think this is a good idea in general or may there be any problems? Maybe this is bloating baselayout to much?

Before I can start I have to solve some general problems here (not Gentoo related - vpnc often doesn't come up and says "authetification unsuccessful").

----------

## UberLord

 *seppelrockt wrote:*   

> My new idea is to write a vpnc module for baselayout during the next 2 weeks - do you think this is a good idea in general or may there be any problems? Maybe this is bloating baselayout to much?

 

What's wrong with a plain init script?

----------

## seppelrockt

 *UberLord wrote:*   

>  *seppelrockt wrote:*   My new idea is to write a vpnc module for baselayout during the next 2 weeks - do you think this is a good idea in general or may there be any problems? Maybe this is bloating baselayout to much? 
> 
> What's wrong with a plain init script?

 

Yes you are right! Init script will do in this case.

----------

