| Age | Commit message (Collapse) | Author |
|---|
|
Only start console if it exists on the running system. If a user detaches a
USB serial console and reboots - it should not fail!
|
|
During testing it was discovered that there is a well known problem (we had for
ethernet interfaces) also in the serial port world. They will be enumerated and
mapped to /dev/ttyUSBxxx differently from boot to boot. This is especially
painful on my development APU4 board which also has a Sierra Wireless MC7710
LTE module installed.
The serial port will toggle between ttyUSB2 and ttyUSB5 depending on the
amount of serial port extenders attached (FT4232H).
The shipped udev rule (/usr/lib/udev/rules.d/60-serial.rules) partly solves
this by enumerating the devices into /dev/serial/by-id folder with their name
and serial number - it's a very good idea but I've found that not all of the
FT4232H dongles have a serial number programmed - this leads to the situation
that when you plug in two cables with both having serial number 0 - only one
device symlink will appear - the previous one is always overwritten by the
latter one.
Derive /usr/lib/udev/rules.d/60-serial.rules and create a /dev/serial/by-bus
directory and group devices by attached USB root port.
|
|
Support for Hayes modems has been long gone (1.2.x) and nobody cared. It was
removed in commit d582bbaf3 ("update console settings for systemd") of
vyatta-cfg-system.
So as there have been zero complaints - cleanup the CLI.
|
|
The current implementation only works once the system has been fully booted
up and the config nodes have been process. So there is no "early" kernel
debugging. It is started with priority 400 (after all network stuff) - thus it
has a questionable at all for Kernel debugging.
It would only make sense if the entire system is changed to supply the config
stuff to the Kernel commandline and then send it to a dedicated MAC address
target as network will be initialized late.
As there are zero Phabricator tasks available and we do not know any user using
this - the "feature" will be removed.
|
|
Migrate the serial console subsystem to XML and Python.
|
|
|
|
T2559: Make the sensors automatically load necessary modules
|
|
|
|
l2tp: T2565: Add missing gw-ip-address
|
|
|
|
|
|
Instead of using "show version" as catch-all command for information rather
add "show system cpu" op-mode command which is analogous to "show system memory"
which deals with RAM.
|
|
|
|
Commit 1c7d7cbd39 ("wwan: T2529: migrate device from ttyUSB to usbXbY.YpZ.Z")
added a new completion helper path for USB based serial interfaces. If no USB
based serial port was available on the system this produced the following
error: "ls: cannot access '/dev/serial/by-bus': No such file or directory"
Only list USB based serial interfaces if there is at least one connected to
the system.
|
|
Commit 886a986a122e ("isis: T2495: exclude generated nodes from package") missed
calling rm -rf, instead only rm -f was called leaving the directory intact.
|
|
* 'udev' of github.com:c-po/vyos-1x:
usb: op-mode: T2560: display USB interface information
pppoe: op-mode: T2488: retrieve log info from journalctl
wwan: op-mode: T2488: retrieve log info from journalctl
wwan: T2241: interface is not bond- or bridgeable
wwan: T2488: remove generation of dedicated logfile
wwan: T2529: migrate device from ttyUSB to usbXbY.YpZ.Z
udev: T2490: add persistent USB device files
|
|
|
|
vyos@vyos:~$ show system usb
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=qcserial, 480M
|__ Port 3: Dev 4, If 2, Class=Vendor Specific Class, Driver=qcserial, 480M
|__ Port 3: Dev 4, If 3, Class=Vendor Specific Class, Driver=qcserial, 480M
|__ Port 3: Dev 4, If 8, Class=Vendor Specific Class, Driver=qmi_wwan, 480M
vyos@vyos:~$ show system usb serial
No USB to serial converter connected
vyos@vyos:~$ show system usb serial
Device Model Vendor
------ ------ ------
usb0b1.3.3.4p1.0 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.3.3.4p1.1 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.3.3.4p1.2 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.3.3.4p1.3 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.3.4p1.0 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.3.4p1.1 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.3.4p1.2 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.3.4p1.3 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.3p1.0 MC7710 Sierra Wireless, Inc.
usb0b1.3p1.2 MC7710 Sierra Wireless, Inc.
usb0b1.3p1.3 MC7710 Sierra Wireless, Inc.
usb0b1.4p1.0 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.4p1.1 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.4p1.2 Quad_RS232-HS Future Technology Devices International, Ltd
usb0b1.4p1.3 Quad_RS232-HS Future Technology Devices International, Ltd
|
|
|
|
|
|
Commit 2cb806271928 ("wirelessmodem: T2241: make VRF and bond/bridge membership
mutually exclusive") added some logic which is not forseen/neither makes sense
on a dialup interface, thus it's removed again
|
|
... all information are present in journald.
|
|
During testing it was discovered that there is a well known problem (we had for
ethernet interfaces) also in the serial port world. They will be enumerated and
mapped to /dev/ttyUSBxxx differently from boot to boot. This is especially
painful on my development APU4 board which also has a Sierra Wireless MC7710
LTE module installed.
The serial port will toggle between ttyUSB2 and ttyUSB5 depending on the
amount of serial port extenders attached (FT4232H).
The shipped udev rule (/usr/lib/udev/rules.d/60-serial.rules) partly solves
this by enumerating the devices into /dev/serial/by-id folder with their name
and serial number - it's a very good idea but I've found that not all of the
FT4232H dongles have a serial number programmed - this leads to the situation
that when you plug in two cables with both having serial number 0 - only one
device symlink will appear - the previous one is always overwritten by the
latter one.
Derive /usr/lib/udev/rules.d/60-serial.rules and create a /dev/serial/by-bus
directory and group devices by attached USB root port.
vyos@vyos:~$ find /dev/serial/by-bus/ -name usb* -exec basename {} \; | sort
usb0b1.3p1.0
usb0b1.3p1.2
usb0b1.3p1.3
usb0b2.4p1.0
usb0b2.4p1.1
usb0b2.4p1.2
usb0b2.4p1.3
So we have USB root 0 with bus 1.3 and port 1.0. The enumeration is constant
accross reboots.
|
|
During testing it was discovered that on 5 out of 10 reboots the USB
enumeration/mapping from physical port to /dev/ttyUSB is different. The root
cause is that it's a FIFO so first found/loaded driver module will be assigned
ttyUSB0.
This mixed up the serial interfaces of my FTDI chips and my connected Sierra
Wireless MC7710 card which was no longer functioning as it now was mapped to
a different USB interface.
The solution is a udev rule which persistently maps the USB-tree-device to a
device file in /dev. Wait? isn't this what /dev/serial/by-{id,path} is for?
Correct, it does the very same thing but the problem is as follows:
* by-path uses device file names which also incorporate the parent bus system,
this results in "pci-0000:00:10.0-usb-0:2.4:1.0-port0"
* by-id will overwrite the assigned device symlink if a new USB device with the
same name appears. This happens to some FTDI devices with no serial number
programmed so the device added last wins and will be the only one in
the by-id folder - cruel world!
This commit adds a new directory /dev/serial/by-bus which holds the following
device files (as example):
$ ls -1 /dev/serial/by-bus/
usb0b1.3p1.0
usb0b1.3p1.2
usb0b1.3p1.3
usb0b2.4p1.0
usb0b2.4p1.1
usb0b2.4p1.2
usb0b2.4p1.3
|
|
vyos@vmware:~$ show environment sensors
VyOS running under hypervisor, no sensors available
vyos@apu4:~$ show environment sensors
ath10k_hwmon-pci-0500
temp1: N/A
k10temp-pci-00c3
temp1: +54.6°C (high = +70.0°C)
(crit = +105.0°C, hyst = +104.0°C)
fam15h_power-pci-00c4
power1: 3.28 W (interval = 0.01 s, crit = 6.00 W)
|
|
|
|
- remove first line from output (sed -e 1d)
- remove leading tab indention (sed -e 's/^\t*//g')
- remove colons (sed -e 's/://')
- align output vertically (column -t -s' ')
|
|
[fixed] options returned by ethtool -k mean that they can not be change and
thus offloading can neither be enabled nor disabled. It makes no sense to
display those parameters at all.
|
|
Migrate additional show commands to XML
* show interfaces tunnel ...
* show interfaces input ...
* show interfaces pseudo-ethernet ...
* show interfaces l2tpv3 ...
* show interfaces bridge ...
* show interfaces vti ...
* show interfaces vxlan ...
|
|
|
|
|
|
|
|
|
|
Commit 728b1feaf744 ("dhcpv6-pd: T2551: fix prefix length not set in config")
reworked the way the configuration path is accesses on the individual
interfaces, but it was missed out to apply it correctly when reading in
sla-len and sla-id values.
|
|
Retrieving the CLI nodes from current config was missed out and only
implemented for PPPoE.
|
|
Python developers can just comment the line.
|
|
show interfaces ethernet eth0 identify
|
|
|
|
|
|
Command node was missing.
|
|
When DHCPv6-PD is configured to delegate a prefix to a non existing interface,
it is restarted (systemd default) but will then hit the restart rate-limit which
disables the service entirely.
As VyOS currently has no "hook" to be called once an interface goes online we
need this "try and error" approach until there is a way to deal with it. This
behavior can be reproduced when delegating an IPv6 prefix to a bridge interface
as a bridge interface will always be started after all interfaces have been
configured.
We will now restart dhcp6c as long as the requested interface is online.
|
|
|
|
vlan: T2553: fix vif-s regression
|
|
A typo caused vif-s interfaces to not commit.
|
|
openvpn: T2550: fix for IPv4 remote-host addresses
|
|
Commit bb9f998 added IPv6 support for OpenVPN, but IPv4 only
configurations stopped working (Address family for hostname not supported)
Commit fc467519 fixed some scenarios by using IPv4 protocols
if 'local-host' is IPv4 address, but the client mode is using
'remote-host' instead and was still broken.
This commit in addition to 'local-host' also checks all the
'remote-host' addresses.
|
|
When migrating all single instances of the IP address XML definition to the
reusable include file an error was ported, too. This allowed an interface be
assigned an IPv4/IPv6 network address es e.g. 192.0.2.0/24 which is invalid.
The validator has been fixed to only allow IPv4/IPv6 host addresses instead.
|
|
rip-xml: T2547: XML for conf-mode protocol RIP
|
|
This reverts commit 44355e6525daec62120601073065f63c9f9a7993.
|
|
|
