El mar, 16-05-2006 a las 11:09 -0700, Giridhar Pemmasani escribi=C3=B3:
> --- Javier Kohen <jkohen@...> wrote:
> > Previously it would restore
> > the network interface and link to working state
> > after resume, now the
> > network does not work after resume. I'm using WEP on
> What exactly is 'working state'? ndiswrapper doesn't
> control network interface. It is the other way around.
> If you mean wireless settings are not correct after
> resume, note that that they should be set again after
> resume - not all drivers retain encryption/ssid
> information during suspend/resume.
I confirmed earlier today that this is exactly the problem I was having.
> Check wireless
> settings after resume and if necessary, set them
> again, as required. Older versions of ndiswrapper
> implemented suspend/resume partially. Newer versions
> handle all cases. However, suspend/resume is a bit
> conservative; it halts device in more cases than it
> should. Latest svn fixes it; check and give feedback.
> However, this may break other drivers, so don't rely
> on ndiswrapper or windows driver retaining wireless
> settings during suspend/resume and do it in user space
I see. I've installed the hibernate package so I can configure some
commands to run on suspend/resume, as you suggested. This solves the
issue I reported, so I'll close the bug I opened (sorry for that).
However, it seems that this solution could use some tuning, as some
applications come back to life before the network interface is restored,
thus failing in weird ways. I know this isn't related to ndiswrapper at
all, but I suppose that somebody else here is having similar problems.
How did you solve it?
Javier Kohen <jkohen@...>
ICQ: blashyrkh #2361802