logs archiveBotHelp.net / Freenode / #2f30 / 2015 / August / 21 / 3
stateless
but a buggy server can do it
and as it stands anyone can send packets to the client until we add the port comparison code which is mandated by the RFC
Evil_Bob_
ah
stateless
in get file, the client is basically in these states
rrq -> data -> ack -> data -> ack
assuming no errors
in putfile it is wwq -> ack -> data -> ack
etc.
also I couldn't find a way to implement putfile() with a single buffer like in getfile()
so I needed inbuf/outbuf
not sure though, did not spend too much time on it
that is because you cannot rewind the input
because it is from stdin
so for resending the buffer
you have to remember the old one
you cannot use seek etc.
Evil_Bob_
" All packets other than duplicate ACK's and those used for
termination are acknowledged unless a timeout occurs [4]."
stateless
for getfile this is not an issue
Evil_Bob_
so seems good
stateless
because you can always remember the ack packet
you can always recreate the same ack packet that is
it is not read from an fd
Evil_Bob_, yeah
maybe it would be nice to add multiple file support and drop stdin/stdout
not sure
:)
or maybe not
Evil_Bob_
nah probably not :)
stateless
yeah it is fine right
port comparison really needs to be added
and also generate an error back to the offending host
to hopefully stop it from resending another one
think of this situation
client sends a request
the udp packet is duplicated in the network and arrives twice at the server
the server sends the first reply
client starts downloading the file
2nd reply arrives from another source port on the server
client now switches over to the new port (no port comparison implemented)
versus
client drops the 2nd reply and sends an error
without port comparison, the file would be corrupt upon downloading
Evil_Bob_
yeah :(
stateless
my patch is simple
but does not send an error back yet
calling writepkt from inside readpkt is ugly :P
but whatever :P
also it is a bit of a bi**h to debug because the ports change after the first request
so with tcpdump you can see the clients source port after the RRQ
then put a sleep(1) in readpkt
then reattach tcpdump to match on the new client port
to see the actual data
or maybe use wireshark which can do this automatically :P
Evil_Bob_
haha
stateless
a simple tftpd would also be nice
so you can use your suckless distro as a boot server
it will be about the same size in sloc as the client
Evil_Bob_
i never use tftp, but im interested in it now :)
stateless
i use it a lot at home
to update my sip phone or to boot bsd.rd + autoupgrade template
in theory with tftp + autoinstall on openbsd
you can upgrade an entire lab
just by running around and powering on machines
:P
without any manual intervention
except for the running around bit
:P
you can use a wheelchair if it is more comfortable
Evil_Bob_
loool
or a segway
make sure to wear a helmet though
:P
stateless
haha
Evil_Bob_, also make sure your lab is not located at the edge of a cliff
the safest way to upgrade it then is to crawl
Evil_Bob_
its fine, it is located in my secret volcano lair (not so secret anymore)
stateless
that's what I told the nsa and they didn't believe me
Evil_Bob_
hah
stateless
in the underground passages of lut gholein
Evil_Bob_
we should play d2 sometime (or some game) for your 2f30 clan
*our
*klan
stateless
yes
Evil_Bob_, http://git.2f30.org/divzeroweb/commit/?id=13290bbfa9d56393fed1443c23206279e8113dd8
:P
Evil_Bob_
hah, I LIKE IT
stateless
Evil_Bob_, also another thing I am not currently implementing in tftp is to extract error messages from the error packet if the error code is "undefined"
not sure it matters match but ok
:P
i think the rfc says sth about that
if error code == 0 that is
the error packet potentially has a null-terminated string in it
atmc
https://www.youtube.com/watch?v=QS8qwMna8_o
stateless
atmc, that's all excuses, he doesn't know how to operate modern machinery
he expired in 1989
atmc
:D
i can't hear him talk longer than 30sec
stateless
yes :P
atmc
didn't watch the whole vid
« prev 1 2 3 4 5 6 next »