logs archiveBotHelp.net / Freenode / #2f30 / 2015 / August / 21 / 2
dsockwell
https://www.youtube.com/watch?v=bt05FIIZPgM
stateless
Evil_Bob_, can never be sure in this life
:P
Evil_Bob_
:D
at work i couldnt be bothered to install gcc on windows, tried tcc, works well :)
1.5kb binary (had to write a very simple data converter program)
stateless
haha nice
Evil_Bob_
lol https://github.com/lmco/laikaboss "Explode children"
i wonder what non-technical people think of these terms
hah http://xkcd.com/1567/
http://imgur.com/gallery/5wKCo
stateless
Evil_Bob_, haha
Evil_Bob_
stateless: btw havent tested tftp, but looked at the code a bit, looks very clean, some minor things maybe:
http://git.suckless.org/sbase/tree/tftp.c#n111
sendto() and recvfrom() should use ssize_t as return value, and size_t len i think
and for packreq(): http://git.suckless.org/sbase/tree/tftp.c#n54
stateless
yeah
it doesn't matter match
max is 516 bytes
Evil_Bob_
the length of the path and mode could be saved maybe
but should be optimized by the compiler i guess anyway
stateless
yeah
if you make the modifications, push them
the suckless police has been informed and will allow you to pass
Evil_Bob_
lol, dunno if its worthy tbh, i can see why you use int in this case, yea
stateless
also keep in mind packreq will be called once every 5 seconds in the worst-case
so yeah
:P
in the best case, it will only be called once
Evil_Bob_
heh
stateless
using SO_RCVTIMEO turned out to be a nice quick hack to set the receive timeout without using poll
;)
also it would be nice to check
if in putfile() the last transfer is a 0 byte transfer
if the file is a multiple of 512 bytes that is
i think it will be
but to be sure :)
the server sees the 0 byte receive and knows it is done
in the same way in getfile() we get a 0 or < 512 byte transfer and we know it is the last block in the file
only thing remaining is to record the source port of the server when we start receiving data
then if we get a packet not from that port, we should drop it and send an error back without interrupting the current transfer
because now if you are downloading a file from the server
and I send a udp packet to the client from another machine, it will abort because the packet will be malformed
;)
Evil_Bob_
lol
stateless
if the packet is not malformed but proper
then the client will keep requesting data from the new machine
so I can hijack the transfer
:P
I have a simple patch
but not finished
http://sprunge.us/YAHf
if you feel like completing it :P
Evil_Bob_
btw kindof related, at work i reverse engineered/researched an application and saw it downloads updates from an anonymous ftp server lol
stateless
lool
Evil_Bob_
the FTP server runs Microsoft FTPd and is used by thousands of clients...
stateless
is it always the same server?
Evil_Bob_
it downloads an .exe each time and checks against the version
i think so yea, not sure
even if its a super secure ftp server, its not a good idea to run it over plain FTP ;P
stateless
lol
mitm
:P
Evil_Bob_
yea
stateless
https://www.youtube.com/watch?v=fWEobn5V_8k
Evil_Bob_
silly question, but skimming the tftp RFC: the max filename length is unspecified ?
cool song btw
stateless
yes it is not specified
i fixed it to 256 bytes
:P
which is the minimum PATH_MAX by posix
Evil_Bob_
yeah it makes sense :)
stateless
well you can fit up to 516 bytes in total
including everything
i think
there are some extensions
in another rfc
allows to set block size too
now transfers are limited to 32MB
512 bytes * 65535 block IDs
it is a limitation in the protocol
with the extensions you can increase this
Evil_Bob_
ah, well its fine i think :)
reading "4. Initial Connection Protocol" now
it seems broken by design but just "unlikely" to fail
i mean low probability
stateless
yes
i tried to "cope" with certain cases
like in getfile
if you get a data packet with an unexpected blk id
and not the next one you are waiting for
we'll ack it
the rfc doesn't specify what to do there i think
in putfile()
it is a different story
if we get an ack with a random blk id
and not the expected one
we will write out the old buffer again I think
a conforming server implementation shouldn't do that
and it is impossible to get out of order packets
« prev 1 2 3 4 5 6 next »