#21375: swconfig command-line documentation
-------------------------------------------------------+-------------------
Reporter: ehem+openwrt@… | Owner:
Type: defect | Status: new
Priority: high | Milestone:
Component: documentation | Version: Trunk
Keywords: swconfig switch commandline documentation |
-------------------------------------------------------+-------------------
There pretty well isn't any of use. Sure
[https://wiki.openwrt.org/doc/techref/swconfig this] gives justification
for the creation of `swconfig` and the netlink-switch interface, but this
says nothing about what any of these options do.
`swconfig dev <device> help` is very badly named. The information there
isn't help, but a listing of the configuration settings. The use of the
strings "--switch", "--vlan" and "--port" suggest extended name options,
as opposed to keys for use with the get/set flags.
There is significant variation in key naming. Are "allow_vid_4095" and
"enable_vlan4k" the same thing? On one switch there is the whole-switch
option "(string): ports" contains a hexadecimal value indicating enabled
ports, versus the referenced page having "(int): disable" on each port
(and then the extra text differing between the two).
What is the format for the vlan attribute "(ports): ports"? Seems a
space-separated list of port numbers, sometimes followed by a per-port
flag letter works (the flag isn't documented. I've also seen a reference
suggesting the spaces are optional. I'm guessing it is similar to
[https://wiki.openwrt.org/oldwiki/historic.whiterussian.nvram the old
format], but I'm unsure which of the '*', 't', and 'u' flags work for this
setting (well, 't' clearly works, but I'm unsure of the other two).
What is the expected behavior for these options? What effect does pvid
have? (similar to the olde documentation?) If a given port is marked
untagged what should one expect if a packet with a tag arrives; packet
dropped, tag ignored, tag stripped, tag left on and additional tag added,
other? How do the "doubletag" and "untag" flags interact with this?
This is '''extremely''' valuable information for testing. If a given
setup doesn't work, then being able to reset the device to go back to the
old configuration is ''highly'' valuable, particularly if "dangerous"
settings are being tried.
--
Ticket URL: <https://dev.openwrt.org/ticket/21375>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
