gnrc_networking: offers txtsnd, does not print received packets

[miri64]

gnrc_networking is offering the txtsnd command but does not print it results when receiving a packet. Overall this is a good situation (the application would otherwise get spammed with link layer packet output), but it might be confusing for new users. I'm voting to remove the txtsnd command from shell_commands an put it only in the applications were it is needed, as partly proposes in #2755.

[OlegHahm]

Against removing txtsnd from shell commands. It's a very helpful debug tool.

[miri64]

Even if there is no information printed at the receiver?

An alternative would be to introduce a dump command that would allow to activate the "dumpage" of a certain nettype.

[OlegHahm]

Yes, even without - I can still see it in Wireshark - or in the debug output of my networking modules. ;)

[OlegHahm]

To be clear: I see your general point and I second it.

[haukepetersen]

I would not remove it, how about a txtrcv command, that waits exactly for 1 network packet to arrive and the prints this?

[miri64]

You mean link layer packet. But this still might be confusing, since any network layer packet (Neighbor solicitations, RPL DIOs etc.) would also be printed and preempt the packet the user was originally expecting... I would opt more for a activatable/deactivatable solution.

[OlegHahm]

Hm, difficult, particular, if you have additional traffic on the wire. On native, for instance, even the default example sees a lot of traffic on the link layer, stemming from the host system.

[haukepetersen]

Isn't the txtsnd only compiled into the default example (without further network stack)?

[miri64]

Nope, it's compiled into any application, that uses the gnrc_netif module.

[haukepetersen]

ok, then forgot what I proposed :-)

[OlegHahm]

But maybe you have a good point: how about making the txtsnd command optional and disable it per default? This would go into the direction of @authmillenon's initial proposal, but still make it available for debugging purposes if needed.

[haukepetersen]

another dumb idea: how about to put a proprietary header (like RIOT in ASCII) in front of the data send via txtsnd. This could be easily parsed by the receiver...

[haukepetersen]

hm, now that I though about his again: why don't we just drop txtsnd from the gnrc_networking example? If you want to focus on link layer only communication, use the default example instead?

[OlegHahm]

Hm, doesn't this go back to the initial discussion?

[haukepetersen]

won't be fixed for this release -> set Milestone to 2016.07

[OlegHahm]

Hm, actually, I would be okay with dropping txtsnd from gnrc_networking example, but I'm still against removing the shell command. Anybody objects putting it into a separate module and include it only for default example?

[miri64]

No objections.

[kYc0o]

No objections, but please address it for the next release :)

[LudwigKnuepfer]

Just to add some beef to the discussion which I did not read:
being able to txtsnd with happening on the receiving side is very confusing.

[OlegHahm]

<theo-de-raadt-mode>Slackers!</theo-de-raadt-mode>

[OlegHahm]

see #6397