Hi Remy, I am using net-auto-wireless. The problem arises when you are still connected to the network, but somehow the connection gets obfuscated. Then you need to reconnect manually (there are other scenarios too which would profit from a nicer syntax for reconnecting). Moritz On 31.01.2012 13:51, Rémy Oudompheng wrote:

I was also wondering why you didn't use net-auto-wireless, can you explain?

On 31.01.2012 15:10, Thomas Bächler wrote:

Am 31.01.2012 14:49, schrieb Moritz Beller:

...

Then you need to reconnect manually

That's a bug, you never need to or should do that.

Yup, I agree. Still, we need to do that. But maybe we can talk about the actual fix and decide whether it's an improvement over the current behaviour on -r? :-) Moritz

On 31.01.2012 19:12, Leonid Isaev wrote:

On Tue, 31 Jan 2012 15:35:56 +0100 Thanks for looking into this. But I wonder what exactly do you mean by "bad wlan"? And what are AP parameters (wep, wpa enterprise)?

I am not sure what is going on there -- it's the eduroam at my university (WPA-EAP, certificate authentication via PAP). They are using Cisco routers with a firmware that has some buffer overflow issues if too many connections are opened at the same time. As I am not resonsible for the machines, I cannot debug this. All I know is that from time to time, the connection dies -- although I am still connected --- and I have to issue a reconnect with nectfg. Which I tried to make simpler syntacticwise and which I would really like to discuss now. Moritz

Hi Leonid, On 02.02.2012 19:36, Leonid Isaev wrote:

So you are still associated/authenticated to the AP, right? When you reconnect is the same AP or a different one? This info should be in /var/log/{kernel,daemon}.log where MACs are printed.

I'm not objecting to netcfg modifications -- just trying to see if there a bigger wpa_supplicant issue here...

Thanks for try to trouble-shoot the problem. I will report back, as soon as I have the opportunity to test it again. Moritz

Dear Remy and the rest, I am currently not an Arch Linux Developer, but am willing to maintain the netcfg repository. Someone else will have to do the packaging in that case, I guess. Is this something you would like, Remy? As for the patch, I don't think we should want a syntax to reconnect every profile, since this is in general not something one should want to do. It feels like an ugly workaround. In my opinion it would be a lot nicer to introduce a syntax to reconnect all profiles that use a specified interface. Regards, - Jouke On Thu, Feb 9, 2012 at 10:47, Moritz Beller <m.o.m.o@web.de> wrote:

On 31.01.2012 13:31, Moritz Beller wrote:

...

Hi,

I've written a small patch for netcfg [1]. However, it seems currently nobody really is responsible for this awesome project and some tickets are pending a long time already. Remy said that he has little time to do anything (he also posted this in december [2]), as said James whom I also contacted.

*bump*

Any progress on who is responsible for netcfg and merging the patch?

Moritz