Page MenuHomeVyOS Platform

commit-archive breaks with IPv6 source addresses
Closed, ResolvedPublic

Description

There appears to be a 1.4 specific issue where commit-archive is broken, I'm not sure if it's because I'm using a source address, or v6:

trae@cr01a-vyos# commit
save
Using source address fd52:d62e:8011:fffe:192:168:253:2
Archiving config...
  sftp://stor01z-rh8.int.trae32566.org:/int/cr01a-vyos Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 174, in upload
    upload_sftp(local_path, url.hostname, url.path, url.username, url.password, source=source)
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 104, in upload_sftp
    transfer_sftp('upload', *args, **kwargs)
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 82, in transfer_sftp
    sock.bind((source, 0))
socket.gaierror: [Errno -9] Address family for hostname not supported
[edit protocols bgp]
trae@cr01a-vyos# save
Saving configuration to '/config/config.boot'...
Done
[edit]
trae@cr01a-vyos# show system config-management commit-archive 
 location sftp://USER:[email protected]:/int/cr01a-vyos
 source-address fd52:d62e:8011:fffe:192:168:253:2
[edit]

Details

Difficulty level
Unknown (require assessment)
Version
1.4-rolling-202105192127
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

trae32566 triaged this task as Normal priority.May 20 2021, 7:00 AM
trae32566 created this task.
trae32566 created this object in space S1 VyOS Public.
erkin changed the task status from Open to Needs testing.May 30 2021, 10:00 AM
erkin renamed this task from commit-archive Broken to commit-archive breaks with IPv6 source addresses.May 30 2021, 10:04 AM
erkin changed the task status from Needs testing to In progress.Jun 2 2021, 9:53 AM

This does not appear to be fixed; I think it's something specific to 1.4:

trae@cr01a-vyos# commit
Using source address fd52:d62e:8011:fffe:192:168:253:2
Archiving config...
  sftp://stor01z-rh8.int.trae32566.org:/int/cr01a-vyos Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 287, in upload
    upload_sftp(local_path, url.hostname, url.path, username, password, port, source, progressbar)
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 166, in upload_sftp
    transfer_sftp('upload', *args, **kwargs)
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 162, in transfer_sftp
    sock.shutdown()
TypeError: shutdown() takes exactly one argument (0 given)
[edit policy route-map BGP-BACKBONE-OUT]
trae@cr01a-vyos# run show ver

Version:          VyOS 1.4-rolling-202106102016
Release Train:    sagitta

Built by:         [email protected]
Built on:         Fri 11 Jun 2021 01:17 UTC
Build UUID:       2394fc33-a732-4bae-bfa2-2df3d9b26fe0
Build Commit ID:  931b023809e5b1

Architecture:     x86_64
Boot via:         installed image
System type:      KVM guest

Hardware vendor:  Red Hat
Hardware model:   KVM
Hardware S/N:     
Hardware UUID:    7ee7d231-b896-480e-b505-46a175f26439

Copyright:        VyOS maintainers and contributors

@trae32566 Does this problem still persist in the newest rolling release?

Yes, though the error has changed:

trae@cr01b-vyos# commit
Using source address fd52:d62e:8011:fffe:192:168:253:3
Archiving config...
  sftp://stor01z-rh8.int.trae32566.org:/int/cr01b-vyos Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 299, in upload
    upload_sftp(local_path, url.hostname, url.path, username, password, port, source, progressbar)
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 178, in upload_sftp
    transfer_sftp('upload', *args, **kwargs)
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 174, in transfer_sftp
    sock.shutdown(socket.SHUT_RDWR)
OSError: [Errno 9] Bad file descriptor

Now I see the problem. paramiko.client.SSHClient().close() calls paramiko.transport.Transport().close() which implicitly calls socket.close() regardless of whether the socket was internally created or externally provided. This is a bit counterintuitive but I'll simply remove the socket closing logic then.

erkin set Issue type to Bug (incorrect behavior).Dec 23 2021, 2:18 PM