[CSDb] - User Forums - IP65 tftp connection issues

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > IP65 tftp connection issues

2017-04-02 06:43

wbochar

Registered: May 2002
Posts: 26

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 255.255.255.255:69 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 192.168.2.67:64033 /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 192.168.2.24:26880, 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 15:09

Mixer

Registered: Apr 2008
Posts: 422

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 20:53

wbochar

Registered: May 2002
Posts: 26

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 192.168.2.23:26880, Malformed Request, Invalid/Missing Filename

I'll keep digging...

2017-04-03 08:57

Mixer

Registered: Apr 2008
Posts: 422

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 14:37

Skate

Registered: Jul 2003
Posts: 490

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 03:06

wbochar

Registered: May 2002
Posts: 26

I spoke with Jonno Downes, who figured out what was going on.

307 33.647628 192.168.2.3 192.168.2.20 TFTP 52 Read Request, File: , Transfer type: OCTET
308 33.647997 192.168.2.20 192.168.2.3 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 21:10

slack_
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

Refresh

Subscribe 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

Advanced

Users Online

CreaMD/React
maestro
megasoftargentina
macx
Mason/Unicess
Twilight/Excess/Arcade
Guests online: 125

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Bromance  (9.6)
10 Memento Mori  (9.6)

Top onefile Demos

1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top NTSC-Fixers

1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Page generated in: 0.035 sec.