On Wed, 2006-12-06 at 08:26 +0100, Frederic Detienne wrote:
Problem 2 -- null vs. dhcp
-
I would like NetworkManager to acquire an IP address for my wireless
interface through DHCP. OTOH, I would like Gentoo net scripts to NOT do
that at all since the gentoo scripts have no idea how
On Wed, 2006-12-06 at 12:07 -0600, Steev Klimaszewski wrote:
Personally, what I have is,
RC_PLUG_SERVICES=!net.eth*
in my /etc/conf.d/rc
What this does is not start any eth* devices (obviously, if you have a
wlanX device you would want to put !net.eth* !net.wlan* in there -
though
PROTECTED] wrote:
On Wed, 2006-12-06 at 18:49 +, Antony J Mee wrote:
On Wed, 2006-12-06 at 12:07 -0600, Steev Klimaszewski wrote:
Personally, what I have is,
RC_PLUG_SERVICES=!net.eth*
in my /etc/conf.d/rc
What this does is not start any eth* devices
On Wed, 2006-09-20 at 10:53 -0400, Dan Williams wrote:
On Wed, 2006-09-20 at 15:36 +0100, Antony J Mee wrote:
Dan,
While there is a change-over period... Could we have a #define to flag
that the version of NetworkManager against which a plugin is compiled
can use the new dict based
Nice work,
On Fri, 2006-08-04 at 16:40 +0200, Shogun wrote:
I just wrote a patch which enables NM to read configuration file for
Gentoo Linux with baselayout-1.12 (which has different format than before).
I thought the newer format had been around longer than that. Somebody
came on
Hi Jonathan,
Sorry I'm late replying. I've not seen the list in days!
I've been spending considerable time with a few people trying to make
sure this stuff works in several distros. It still needs the core NM
fix for MTU stuff (http://bugzilla.gnome.org/show_bug.cgi?id=344967),
but hopefully
On Mon, 2006-07-17 at 19:17 +0200, Christian Stangier wrote:
If I truncated the log file too much the full version can be seen at
this url: http://kriz.homelinux.com/trashcenter/networkmanager.txt
A while ago when I was using SuSE 10.1 it worked out of the box - now
using Gentoo it doesn't.
Does anybody know what is still up with mailman @ gnome.org?
Is it just the NM list that is suffering from apparently
totally unpredictable delays in delivery?
Recent posts seem to suggest that many people are
affected and experience different levels of delay.
Can anybody confirm such behaviour?
The reason it is not designed like this is for security. If firefox
stores it's passwords in a keyring ( it doesn't yet ), and you download
random spyware/virus from the web and launch it, with the cookie jar
method the rogue program would have access to all your web passwords.
Right now
On Wed, June 21, 2006 8:18 pm, Dan Williams wrote:
So; I think at the moment, the plan is this [1]:
[1] some bits are up for debate
I don't know about debate but a thought or two
You have mentioned worry that some parts of the core code are
starting to experience some bloat eg. the
Though an mtu setting exists in the NMIP4Config structure, the VPN
code in all cases overwrites the MTU on the interface to 1412 bytes.
Almost all PPTP require an MTU setting of 1000 (over PPP) and hence
996 bytes on the interface. (4 bytes for PPP stuff)
The hard coded setting of 1412 bytes
Dan, Tim, (and the list)
I stumbled in to this and have discussed it briefly with
Tim (as this is pretty much the topic of his SoC project).
I have hear mention of device support and dialup
support mentioned with respect to the NetworkManager
core (not the applets). I have some ideas, from
Dan Williams wrote:
Here's the ideal NM situation.
Users will need to pre-pair and preconfigure their BT devices for use
with NM. We'll likely include an application that will allow users to
scan for and select a BT device, pair with it, and set up the
carrier-specific GSM/CDMA settings for
Hello all,
I've had an issue with NM for over a month and hoped it might just be a
quirk that would go
away in time. (I'm running NM from CVS).
When NM connects to an AP is associates correctly, then DHCp runs and
gets me and IP etc.
The routes are correctly set and everything seems to be
Robert Love wrote:
I think we can separate should never restart the system bus from foo
should be able to survive a system bus restart.
The former is good policy, the latter is good programming. We can have
both.
Brilliantly concise :-)
When one considers this a stability issue and not a
giskard wrote:
Il giorno gio, 09/02/2006 alle 17.37 +, Antony J Mee ha scritto:
Hi Tom,
I'm not running Debian (rather Gentoo, it's illegitimate child) but I
have the same issue and
adding #define HEADERS_KERNEL seems to fix this.
or you can use the patches that the `pkg
Antony J Mee wrote:
giskard wrote:
or you can use the patches that the `pkg-utopia debian guys` provide :)
Except that they also include (admittedly consistently across
packages) some
strange patches to 'rebrand' dchdbd in a strange manner (the dbus stuff
I mean) - naff if you're trying
Hi Tom,
I'm not running Debian (rather Gentoo, it's illegitimate child) but I
have the same issue and
adding #define HEADERS_KERNEL seems to fix this.
I'd love to say I understand why this works, or tell you where I got
this information but
sadly I know neither! :-) Perhaps it was that
Dear all,
Perhaps someone on the list can clear up this matter once and for all.
(Dan ??)
Christoph's patch is of cause an important fix. What concerns me however
is what the name of the
original attachment suggests: nm-unredhat-0.6.0.patch
I worry this is another instance of a strange
Hi Ryan,
I am also seeing the same thing, with my BCM4306 card and ndiswrapper, on
a Gentoo box (without SELinux).
The example here is trying to connect to an open network 'magpie'.
I'm not even sure it should work with ndiswrapper (someone please confirm).
Though it does appear that all the
Hi Michael,
Sorry I cannot give a solution but I have precisely the same problem.
I've tried running the latest wpa_supplicant tarball (0.5.1) and even
the head of the cvs tree. Both give me the same result.
I noticed that when I tried running wpa_supplicant interactively with
something like:
Evening all,
I have finally checked in my current work-in-progress code for the PPTP
plugin under vpn-daemons/pptp into CVS.
This rewrite solves the issues regarding the alteration of config files
in /etc,
the passing of IP config info from pppd and name resolution of the VPN
server
as
I'm using a fairly standard Simple theme and I see a very slightly
darker grey (relative to the notification area) in the background of
the nm-applet icon when deactivated. It is very subtle, to the point of
making me wonder if it's an illusion. I never found out why when I went
poking
Hi Nikolaus,
Yes, I've did quite a bit of work on it. Infact I totally revamped it
to use a pppd plugin as it's helper. (Thus is can do the DNS + routing
without modifications to your local /etc/ppp files)
Actually there is one exception... Many distros have an ip-up script
which
Hi Robert,
Thanks for the response. I do want it to just work. But minor edits
then just works seems to be better than doesn't work; if only a step
in the right direction.
This means for me that I can now run NM in one important location
(office) and gives me more motivation to get it
Robert Dan,
I got a very useful response from James Cameron (the PPTP maintainer).
It looks like my correct course of action is to build a pppd plugin,
which apparently
are very version dependent, but I'm sure the packaging for a particular
distro will be able to get around that. It seems a
:
Antony J Mee wrote:
on finishing my WPA mods instead. Annoyingly NM is useless for me both
at home (WPA) and at work (PPTP VPN)... Yet somehow I still think it's
great!
Oh yes, I would love to see WPA support in NM, too!
Shout if you do put something together. I can perhaps give you
The last mention of WPA I can find in the archives was back at the end
of June.
NetworkManager is fantastic, but useless to me without WPA. Before I start
hacking some code, could anybody update me on the present state of the
WPA fixes? I can see no mention of wpa related changes in HEAD.
So
28 matches
Mail list logo
