SOLVED:minicom RTS deasserted upon hangup (Usbserial bug)

[eccerr0r]

I just noticed something weird while trying to get mgetty+sendfax vgetty to work on my voicemodem.

The voicemodem unfortunately is not directly supported - it's a Conexant but its command set isn't compatible with Rockwell though it detects it as such. But anyway...

While trying to experiment with the voice modem, I finally got it to play voice messages (synthesized by espeak ) but couldn't get it to record. So I tried the command sequence in minicom, and sure enough, it also did not record - no data came back... most of the time...

I had noticed that sometimes it did come back. So I meta-h hung up in minicom and tried the command again. This time, no dice: no voice data. WEIRD.

So I plugged in my simple line analyzer and noticed RTS was asserted when it worked -- and deasserted when it doesn't. AHA! But the weird thing is that minicom apparently deasserts RTS when meta-h hangup is used, and fails to reassert it despite RTSCTS hardware flow control is enabled. So, is this a bug or intended operation? Is there a way to get it to reassert RTS?

[EDIT]

I found that I can get it to reassert RTS by going to the serial port setup (Meta-O, serial port setup) and temporarily disabling hardware flow control and reenabling it). This is kind of awkward. In any case, somehow mgetty+sendfax / vgetty also exhibits the same problem.... Might be a USB serial port issue and actually a kernel bug.

[EDIT: Solved sort of]
It's a usbserial (belkin_sa?) bug. A true 16550 serial port does not exhibit this issue.

[Edit: More information if people are interested... Neddy?]
Hangup behavior (meta-h, hangup) in minicom:
16550 ISA/LPC - both RTS and DTR go low, both go back high (BEST)
pl2303 - only DTR goes low and back high (ACCEPTABLE)
belkin_sa - both RTS and DTR go low, only DTR goes back high (BAD)
mct_u232 - both RTS and DTR go low, and stay low (AWFUL)

Upon inspection of the source code for the worst driver, mct_u232.c ...