lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 21 Feb 2010 15:42:04 +0100
From:	Philippe De Muyter <phdm@...qel.be>
To:	chas3@...rs.sourceforge.net
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] atm : fix
	/sys/devices/virtual/atm/X/carrier(ATM_PHY_SIG_UNKNOWN)

On Thu, Feb 18, 2010 at 09:22:53AM -0500, Chas Williams (CONTRACTOR) wrote:
> In message <20100214175136.GA15891@...lo.macqel>,Philippe De Muyter writes:
> >cxacru itself does the right thing : as soon as carrier state is known,
> >signal is set to ATM_PHY_SIG_LOST or ATM_PHY_SIG_FOUND, but
> >atm_sysfs.c::show_carrier is wrong.
> 
> so, i was thinking about something like this.  atm_dev->signal is
> initializated to _LOST (because it is at this point), but most drivers
> will set ->signal to _FOUND since they dont handle detecting carrier
> when they finish their hardware initialization.  the usb atm layer 
> is the major exception here, and it appears that they already handle
> the atm_dev->signal status correctly.  the minor exception being
> "unknown line state" -- i am going to assume LOST is the best choice
> for this case.
> 
> please try this and let me know if it fixes your problem.

I have tested with my cxacru modem and it fixes my problem.
I have no other atm modem, but your change seems obviously correct.

> 
> diff --git a/drivers/atm/adummy.c b/drivers/atm/adummy.c
> index 5effec6..2b9315f 100644

Acked-by: Philippe De Muyter <phdm@...qel.be>

Thanks

Philippe
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ