Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Brizio ! (Registered 2017-08-20) You are not logged in 
CSDb User Forums


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

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 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 17:09
Mixer

Registered: Apr 2008
Posts: 225
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
wbochar

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

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

Registered: Apr 2008
Posts: 225
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
Skate

Registered: Jul 2003
Posts: 464
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
wbochar

Registered: May 2002
Posts: 20
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 23:10
slack_

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
Advanced
Users Online
copass/Leader
Croozor/CML^Arsenic
Knight Rider/Formby ..
iAN CooG/HVSC
Guests online: 50
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 Lunatico  (9.6)
6 Comaland 100%  (9.5)
7 Incoherent Nightmare  (9.5)
8 Wonderland XII  (9.5)
9 Comaland  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Veterans of Style  (9.5)
2 Dawnfall V1.1  (9.5)
3 Daah, Those Acid Pil..  (9.5)
4 Treu Love [reu]  (9.4)
5 Dawnfall  (9.3)
6 SidRok  (9.3)
7 F1 Evolution  (9.3)
8 One-Der  (9.2)
9 Tunnel Vision  (9.2)
10 Game of Thrones [2sid]  (9.1)
Top Groups
1 Pond  (10)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Oxyron  (9.4)
5 Crest  (9.3)
Top Coders
1 Axis  (9.8)
2 Crossbow  (9.8)
3 Graham  (9.8)
4 HCL  (9.8)
5 Lft  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 0.275 sec.