netdev - Re: [7/8,RFC] CAIF Protocol Stack

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]

Message-ID: <4ACDB56B.1060002@babic.homelinux.org>
Date:	Thu, 08 Oct 2009 11:48:27 +0200
From:	Stefano Babic <stefano.babic@...ic.homelinux.org>
To:	Sjur Brændeland <sjur.brandeland@...ricsson.com>
CC:	netdev@...r.kernel.org,
	Kim Lilliestierna XX <kim.xx.lilliestierna@...ricsson.com>
Subject: Re: [7/8,RFC] CAIF Protocol Stack

Sjur Brændeland wrote:
> Yes, I'll fix this documentation in a new PATCH delivery (hopefully) this week.

Ok, I will test it again when you will send to the ML.

> Hmm, the hanging might be due to a tight loop in the phyif_ser.c:ser_phy_tx function.

Agree. I can trace what happens and I can check that the tty write
function returns always 0. However, I can check that the ops field of
pser_tty is correctly set to the uart_* functions in serial_core.c and
that pser_tty->index points to the serial I chose. At least the
connection to the physical interface seems right.

> [snip]
> 		do {
> 			tty_wr =
> 			    pser_tty->ops->write(pser_tty, bufp, actual_len);

Yes, tty_wr is always 0.

> If pser_tty->ops->write() returns zero it will loop infinetly.
> I guess the proper solution would be not to loop, but to implement a write_wakeup function for the tty...?

Agree, but this is not the problem now, because pser_tty->ops->write
returns always 0.
I have supposed that "clocal" was not set on the serial, but I have
found something different.

In phyif_ser.c, I traced the result of the extract function:

[snip]
do {
                char *bufp;
                /* By default we assume that we will extract
                 * all data in one go. */
                cont = false;

                /* Extract data from the packet. */
                f.cfpkt_extract(cfpkt, sbuf_wr, WRITE_BUF_SIZE,
&actual_len);

I can state that actual_len is always wrong (at least, the first time
.ser_phy_txis called). I get a completely wrong value for it, as if this
variable is not initialized:

actual_len -1090496676

Then the uart_write function cannot work with negative numbers and
explains why it returns 0. So it seems to me at the moment there is a
bug in the extract function. What do you think about ?

Best regards,
Stefano Babic

-- 
stefano <stefano.babic@...ic.homelinux.org>
GPG Key: 0x55814DDE
Fingerprint 4E85 2A66 4CBA 497A 2A7B D3BF 5973 F216 5581 4DDE
--
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