Skip to content
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

Merged
merged 1 commit into from
Dec 4, 2015
Merged

Initial TFTP support #3911

merged 1 commit into from
Dec 4, 2015

Conversation

DipSwitch
Copy link
Member

Options that where thrown up by @authmillenon

Re-Write to use conn API depends on #3921

  • Con: Re-Writing to conn 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.

@OlegHahm OlegHahm added this to the Release NEXT MAJOR milestone Sep 21, 2015
@OlegHahm OlegHahm added Area: network Area: Networking Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Sep 21, 2015
@OlegHahm
Copy link
Member

Nice one!

*/
typedef struct __attribute__((packed)) {
tftp_opcodes_t opc : 16;
uint16_t block_nr;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

network_uint16_t ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressed

Copy link
Member

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? (:

@miri64
Copy link
Member

miri64 commented Sep 21, 2015

@DipSwitch may it be possible to use the conn interface for application protocols? This way other future network stacks would also profit from your implementation.

@DipSwitch
Copy link
Member Author

I'll check in a sec. How can I implement an timeout msg if I refactor to conn? I'll be on IRC in a minute to avoid spam ;)

@miri64
Copy link
Member

miri64 commented Sep 21, 2015

I'm only on my phone and about to sleep, so won't be on IRC tonight. Sorry :(

@DipSwitch
Copy link
Member Author

Oke np, maybe we could steal an idea of LwIP where we create int gnrc_conn_recvfrom_timeout(conn_t *conn, void *data, size_t max_len, void *addr, size_t *addr_len, uint16_t *port, uint32_t timeout_ms) where the conn API also waits for a predefined timeout message type?

@DipSwitch
Copy link
Member Author

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.

=======
* @brief Start an TFTP server
*
>>>>>>> ce6ac59aff53a20b2a06b65b722595e08a9c084a
Copy link
Member

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

@miri64
Copy link
Member

miri64 commented Dec 1, 2015

Is it sending or receiving? For receiving packets this is the correct order.

@DipSwitch
Copy link
Member Author

DipSwitch commented Dec 1, 2015 via email

@OlegHahm
Copy link
Member

OlegHahm commented Dec 1, 2015

Apparently it's happening only for 6LoWPAN.

@OlegHahm
Copy link
Member

OlegHahm commented Dec 1, 2015

pkt->next->next->next is of type GNRC_NETTYPE_NETIF, pkt is of type GNRC_NETTYPE_UNDEF.

Hence, we have undef->IPv6->UDP->netif which seems odd to me - in both directions. Could this reordering happen during IPHC decompression?

@DipSwitch
Copy link
Member Author

DipSwitch commented Dec 1, 2015 via email

@OlegHahm
Copy link
Member

OlegHahm commented Dec 1, 2015

OlegHahm@41569b9 would fix it, but seems to be a workaround. @authmillenon, what's your opinion?

@miri64
Copy link
Member

miri64 commented Dec 1, 2015

Your way looks definitely more like it was done in GNRC for the most part.

@DipSwitch
Copy link
Member Author

Merged and squashed

@emmanuelsearch
Copy link
Member

@DipSwitch can you open an issue about the header order swap?

@emmanuelsearch
Copy link
Member

other than that, I'd say: ACK & merge when T is happy?

@emmanuelsearch
Copy link
Member

One Travis job consistently fails because it exceeds 50min...

@DipSwitch
Copy link
Member Author

The build has succeeded without errors in the past if I remember correct.

@OlegHahm
Copy link
Member

OlegHahm commented Dec 3, 2015

Yes, I saw it, too. Let's give Travis one more chance.

@OlegHahm
Copy link
Member

OlegHahm commented Dec 3, 2015

Damn! Would you mind rebasing one more time as soon as #4399 is merged? (You may call me paranoid.)

@DipSwitch
Copy link
Member Author

DipSwitch commented Dec 3, 2015 via email

@cgundogan
Copy link
Member

@DipSwitch can you rebase now? #4399 was merged

@DipSwitch
Copy link
Member Author

Oops lol, wait, let me fix this xD

@DipSwitch DipSwitch force-pushed the tftp_client branch 2 times, most recently from bbfee68 to 274e211 Compare December 3, 2015 20:23
Fix: packet size and typo in transfer mode main -> mail
OlegHahm added a commit that referenced this pull request Dec 4, 2015
@OlegHahm OlegHahm merged commit 09aa558 into RIOT-OS:master Dec 4, 2015
@OlegHahm
Copy link
Member

OlegHahm commented Dec 4, 2015

Great job, thanks!

@daniel-k
Copy link
Member

daniel-k commented Dec 4, 2015

Woohoo, nice! :)

@DipSwitch
Copy link
Member Author

DipSwitch commented Dec 4, 2015 via email

@DipSwitch DipSwitch deleted the tftp_client branch December 16, 2015 22:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants