bug? xmodem 0.2.4 transfers where 0.3.2+ does not.

[BrendanSimon]

The xmodem package on PyPi is out of date. It is at version 0.3.2, but 0.4.1 is released (or tagged) and there is another recent bug fix committed post 0.4.1. Could you please update so I can pip install the latest / most stable version.

Is there a forum to discuss issues with xmodem?
I currently have an issue where xmodem 0.3.2 (using python 2.7 on OS X Yosemite 10.10) is giving me timeout errors. The same code works ok with xmodem 0.2.3 (using python 2.6). I'm hoping a later version will fix things. What is the best way to install the latest version (given PyPi is out of date).

[BrendanSimon]

Just cloned the repository and installed it and the same thing happens. No data is sent and/or received.
I've tried the following commits.
38b19f3 [38b19f3] nak-resend-on-timeout-getc
8c33227 [8c33227]

[BrendanSimon]

Checked version 0.2.4 and it works, so something has changed somewhere post 0.2.4.

[krishardy]

Thanks for the report. I'll try to look into it today.

-Kris

On July 26, 2015 6:34:19 AM MDT, BrendanSimon notifications@github.com wrote:

Checked version 0.2.4 and it works, so something has changed somewhere
post 0.2.4.

---

Reply to this email directly or view it on GitHub:
#14 (comment)

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[jquast]

@BrendanSimon -- assuming you have a virtualenv, or don't mind using root, you can install the latest development version from github as follows:

$ pip uninstall xmodem # uninstall any version from pypi
$ git clone https://github.com/tehmaze/xmodem.git # get latest 'master' branch'
$ cd xmodem
$ pip install -e . # install "development egg", so modifications made in this folder are immediately available to other programs without re-installing xmodem.

[jquast]

These can be difficult to reproduce, because you very likely have a device transmitting xmodem protocol that I do not have access to -- but any source code, debug output, etc. that you can provide would help! The latest version from github has the most helpful debug messages.

[BrendanSimon]

Something happened in the following commit which causes my device to no longer respond after an XMODEM.send().
commit: fdada4d

Interestingly, XMODEM.send() returns True, but further writes/reads don't succeed.
The previous commit had no such issue (with my device).
commit: 9763468

Maybe it has to do with changes to getc() timeouts, or crc mode, or end or transmission acks ??
Maybe I have to make changes to my code ?? Any suggestions ??

[jquast]

to restate,

but any source code, debug output, etc. that you can provide would help!

there is debug logging in the latest master branch, please !

[krishardy]

@jquast Nothing obvious pops out to me in XMODEM.send()

@BrendanSimon When you state "but further writes/reads don't succeed", could you please elaborate on this? Do you know that they don't succeed because XMODEM.send() returns False, it never returns, your device isn't acting the way that you expect, or some other reason? Do you know if data is being transmitted over RS232 to your device, and what your device is responding with? As jquast mentioned, everything you can provide will help (source code, debug output, etc.).

[jquast]

Re-reviewing agan, This could have been fixed by #19 if this were some kind of timing-boundry issue. I'm tempted to close this issue in the coming weeks unless we can receive more details.

[BrendanSimon]

I will see if I can get some cycles this weekend to relook at this.

[BrendanSimon]

As "luck" would have it, I had to do some work on this product again ;-)
I upgraded to v0.4.5 to see if things were better, but alas the error is still there.

What I discovered is there seems to be different padding in the last block.

• v0.4.5 has 0x1A pad bytes.
• v0.2.4 has 0xFF pad bytes.

Is this correct and would/should it cause an issue?

v0.4.5

DEBUG: XmodemWrite(data=bytearray(b'\x019\xc6\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a;v'), data_size=133)

v0.2.4

DEBUG: XmodemWrite(data='\x01', data_size=1)
DEBUG: XmodemWrite(data='9', data_size=1)
DEBUG: XmodemWrite(data='\xc6', data_size=1)
DEBUG: XmodemWrite(data='\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff', data_size=128)
DEBUG: XmodemWrite(data='\x84', data_size=1)
DEBUG: XmodemWrite(data='\xb4', data_size=1)

[BrendanSimon]

I tried setting the pad argument to b0xff and it made no difference.

Looking a closer at the data it seems that the transfer succeeds and the EOT character is sent too, but for some reason my device seems to not respond after the transfer (with v0.4.5) but does with (v0.2.4).

My code explicitly sends the EOT after the transfer. I see that in both xmodem versions the EOT is sent on my behalf so I shouldn't need to do it, however it seems I don't get an ACK back when using v0.2.4, but I do get an ACK when using v0.4.5.

What I'm guessing is happening is that with v0.2.4, my device misses the inbuilt EOT for some reason (timing? is is sent too quickly?), but with v0.4.5 my device does see the EOT and responds with an ACK. I don't check for this ACK, as I send an explicit EOT and check the result then. Since the transfer is complete I don't get a 2nd ACK back and my program generates a timeout exception.

[BrendanSimon]

What I am seeing is that v0.2.4 sends the EOT but does not consume the ACK reply, where as v0.4.5 sends the EOT and does consume the ACK reply.

My app doesn't handle this variation in function, and generates an exception.

So, in the end, I don't know if this is a bug or not. Probably not, just a difference that I need to cater for.