Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums

Forums > C64 Coding > IP65 tftp connection issues
2017-04-02 08:43
Account closed

Registered: May 2002
Posts: 20
IP65 tftp connection issues

ca65 / ip65
I'm using Vice 2.4 with RRNET enabled.

All of my tests so far have worked; DHCP, DNS and HTTP downloads.

I am trying to get tFTP to work, which is proving difficult. I've pxe'd machines on this network before. I have tFTP enabled on a NAS box (serving and its direct IP:69)

From my Dev station, I have a windows based tFTP client, which connects to the NAS. Below is the Log Entry:

[02-Apr-17 01:27:06] Client /share/tftpboot/screen.bin, 4 Blocks Served

If I run my boot prg, DHCP gets an IP, DNS gets outside entries (ddns), but the moment I try to pull a file from tFTP I get:

(On NAS)
[02-Apr-17 01:28:07] Client, Unknown transfer ID

This IP above is the c64, which shows it's negotiating a connection but I have no idea what the error is. Everything I've read has no descriptor for the error, other than it's an error.

the tftp_status variable is showing 0, then 1, 2 and then 6. 6 is not on the table, so
tftp_initializing = 1 ; initial state
tftp_initial_request_sent = 2 ; sent the RRQ or WRQ, waiting for some data
tftp_transmission_in_progress = 3 ; we have sent/received the first packet of file data
tftp_complete = 4 ; we have sent/received the final packet of file data
tftp_error = 5 ; we got an error

Has anyone else got this to work?
2017-04-02 17:09

Registered: Apr 2008
Posts: 263
Well, I do not have a clue about how the tftp is implemented in this case, but I've seen a few implementations.

After the initial connect to the server port, servers often change the actual transfer to take place between other udp ports, and create a "transfer" structure to hold transfer state and connection information. TFTP protocol does not have a transfer id itself, so it is a piece of data held by either the client or the server to keep track of connections. Client should use the port that server responds with for the rest of the transfer.

When a new packet arrives the structure is queried in order to direct requests to correct handler.

It may be so that the transfer structure is closed before the final ack for the last packet is handled by the server or the client, so the last ack then causes the unexpected error.

Some servers only use a single connection, so they just alter the ports from server port to something else for the duration of the transfer and then back.

Anyway, it sounds like a client or server bug to me. Transfer is closed wrong or the connection is not returned to server state after the transfer is complete.
2017-04-02 22:53
Account closed

Registered: May 2002
Posts: 20
It's definitely with my client program. I think some of my debugging code is boffing something else.
I cleared my debugging vars and went back to the base tftp.s and I'm getting other errors:

[02-Apr-17 16:44:14] Client, Malformed Request, Invalid/Missing Filename

I'll keep digging...
2017-04-03 10:57

Registered: Apr 2008
Posts: 263
Wireshark is great tool for this sort of debugging, if you can route your connection so that your PC can see it.
2017-04-04 16:37

Registered: Jul 2003
Posts: 470
If Wireshark doesn't work, Cain&Abel always works. But your virus killer (if you use one) wouldn't like it since it uses ARP Poisoning.
2017-04-06 05:06
Account closed

Registered: May 2002
Posts: 20
I spoke with Jonno Downes, who figured out what was going on.

307 33.647628 TFTP 52 Read Request, File: , Transfer type: OCTET
308 33.647997 TFTP 90 Error Code, Code: Not defined, Message: Malformed

tFtp filename was using PTR3 in zeropage, which was also shared by the ethernet frame pointer. In most situations they can coexist, but in a few places they can bork each other.

Switching filename to another ZP in tftp.s fixed the problem.

Also, a side note with wireshark.. if you have a one sided conversation occurring (no sends but only responses) check your VPN software. I had an old VPN client that was blocking the sending side being capped.

All files are downloading now :)
2017-04-06 23:10
Account closed

Registered: Nov 2009
Posts: 2
BTW I've passed this info on to Oliver Schmidt (current ip65 maintainer) so the fix can be made in main ip65 distribution as well
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Guests online: 17
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 The Shores of Reflec..  (9.6)
5 Comaland 100%  (9.6)
6 We Come in Peace  (9.6)
7 Lunatico  (9.6)
8 Incoherent Nightmare  (9.5)
9 Wonderland XII  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Dawnfall V1.1  (9.5)
2 Synthesis  (9.5)
3 FMX Music Demo  (9.5)
4 Pandemoniac Part 2 o..  (9.5)
5 Daah, Those Acid Pil..  (9.5)
6 Treu Love [reu]  (9.5)
7 Merry Xmas 2017  (9.4)
8 Dawnfall  (9.4)
9 Gubbdata 2017 Invite  (9.3)
10 SidRok  (9.3)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Finnish Gold  (9.4)
5 Crest  (9.3)
Top Fullscreen Graphicians
1 Joe  (9.9)
2 Veto  (9.8)
3 Mirage  (9.7)
4 Jailbird  (9.6)
5 Hein  (9.5)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.135 sec.