-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial TFTP support #3911
Initial TFTP support #3911
Conversation
Nice one! |
*/ | ||
typedef struct __attribute__((packed)) { | ||
tftp_opcodes_t opc : 16; | ||
uint16_t block_nr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
network_uint16_t
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see the change. push? (:
@DipSwitch may it be possible to use the |
I'll check in a sec. How can I implement an timeout msg if I refactor to |
I'm only on my phone and about to sleep, so won't be on IRC tonight. Sorry :( |
Oke np, maybe we could steal an idea of LwIP where we create |
This would solve the timeout problem for the TFTP client application. For the server implementation I would need to check, it would probably come down to creating a thread / task for each client. |
bf9f24c
to
ce6ac59
Compare
======= | ||
* @brief Start an TFTP server | ||
* | ||
>>>>>>> ce6ac59aff53a20b2a06b65b722595e08a9c084a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have a merge conflict here
Is it sending or receiving? For receiving packets this is the correct order. |
It is receiving, but the assert was never hit before...
|
Apparently it's happening only for 6LoWPAN. |
Hence, we have |
But not on my board, on my board the whole network stack seems to stop for
a while. But not tested with the latest master. I'll test latest master
first thing in the morning.
|
OlegHahm@41569b9 would fix it, but seems to be a workaround. @authmillenon, what's your opinion? |
Your way looks definitely more like it was done in GNRC for the most part. |
c1398b8
to
bbfee68
Compare
Merged and squashed |
@DipSwitch can you open an issue about the header order swap? |
other than that, I'd say: ACK & merge when T is happy? |
One Travis job consistently fails because it exceeds 50min... |
The build has succeeded without errors in the past if I remember correct. |
Yes, I saw it, too. Let's give Travis one more chance. |
Damn! Would you mind rebasing one more time as soon as #4399 is merged? (You may call me paranoid.) |
Sure no problem :)
|
@DipSwitch can you rebase now? #4399 was merged |
Oops lol, wait, let me fix this xD |
bbfee68
to
274e211
Compare
Fix: packet size and typo in transfer mode main -> mail
ef62d6e
to
ede923b
Compare
Great job, thanks! |
Woohoo, nice! :) |
Whoohoo! That took a while :D
|
Options that where thrown up by @authmillenon
Re-Write to use
conn
API depends on #3921conn
loses the capability of zero-copy since I now could allocate the packet buffer at maximum size and reallocate it to the size that it actually is after filling it.