[feature] Allow recognizing wireguard interface as of type virtual
nemesifier opened this issue · 2 comments
If the proto address of an interface is wireguard, we can consider its type to be "virtual".
@nemesisdesign is this the only change needed?
96f55f2
P.S. :- How the interface data looks like for wireguard? It would be easy to have a test case for it then
@nemesisdesign is this the only change needed? 96f55f2
Yes. I think we'd be better off preparing a list of values and build the if to check if the proto is any of the values present in the list, so as we add support for more virtual interfaces we can extend this list of values (eg: vxlan, gre, etc).
P.S. :- How the interface data looks like for wireguard? It would be easy to have a test case for it then
Output now produced is:
{
"addresses": [
{
"address": "172.16.0.9",
"family": "ipv4",
"mask": 32,
"proto": "wireguard"
}
],
"mac": "00:00:00:00:00:00",
"mtu": 1280,
"multicast": false,
"name": "wg0",
"txqueuelen": 1000,
"type": "other",
"up": true
}The output of ubus call network.interface dump looks as follows:
{
"interface": "wg0",
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 81437,
"l3_device": "wg0",
"proto": "wireguard",
"updated": [
"addresses",
"routes"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "172.16.0.9",
"mask": 32
}
],
"ipv6-address": [
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
],
"route": [
{
"target": "172.16.0.1",
"mask": 32,
"nexthop": "0.0.0.0",
"source": "0.0.0.0/0"
}
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
}
}