10 Mar
2020
10 Mar
'20
11:01 p.m.
I'm a big fan of regression. I have programs that I wrote in the 1970's
that will execute just fine on IBM mainframes, _today_.? That's one
major reason they're still around; you don't lose your software
investment, which can be millions of dollars or impossible to replace.?
We had always wondered whether DEC really understood this when canceling
the 36 bit line.
New versions of Linux just drive me nuts when somebody has decided that
something needed changing.? The worst was the change in the /DEV
interface that broke the NI code in KLH10.? It's not that I can't fix
things; I did.? It's that I want to write 20 hosted code as a hobby, not
chase inter-Linux quirks.
I'm also a big fan of people using my software but either not bothering
me or not getting frustrated (or both).? Old machines are the ones most
frequently repurposed; but you can't assume that the user is going to
want or is able to put up a new version of the OS.? They just want to
use your software.
Gnu auto configure can go a long way to handling most of this.? For my
software, if I am aware of different possible results which are
'reasonable', then I code for both (or all of them) and hopefully
recover gracefully by still working with reduced functionality.? The
overall level of expertise is not what it was; something not working the
first time around is often the only reason they need to wash their
hands, which is a pity.
All of this argues for a few lines of logic to determine which interface
to use.? It's hardly a heavy lift and an extremely friendly thing to
do.? Rolling over and dropping dead with little or no information is
what Unix programs are notorious for.? We never tolerated that on the 20.
------------------------------------------------------------------------
On 3/10/20 5:18 PM, David Moylan wrote:
I?m all for backwards compatibility, however the /dev/net/tun
interface has been in linux since the 2.6 days. A quick google shows
that people back in 2010 have been using it, and browsing on
kernel.org for the oldest archived kernel entry of 2.6.11 shows code
examples for /dev/net/tun dated 2005.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docum…
I think the starting date for support of /dev/net/tun is earlier than
that of the discontinuation of support for /dev/tapx.
Given that the whole goal of pyDECnet is to permit usage of decnet on
more modern environments, I think having code that supports back to
2005 is a pretty solid move.
Cheers, Wiz!!
*From:*owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
*On Behalf Of *Thomas DeBellis
*Sent:* Wednesday, 11 March 2020 2:08 AM
*To:* hecnet at Update.UU.SE
*Subject:* Re: [HECnet] Intermittent Connection with PyDECnet?
Since you may be running both on newer and older kernels, does it make
sense to test for which tunnel type interface exists and simply use that?
You don't even need to test versions, but rather try /dev/net/tun and
if it works, use that or if it fails, use /dev/tapx.
I'm a big fan of dynamic configuration, also known in the trade as
'auto magic' or 'automatic nice things'.
------------------------------------------------------------------------
On 3/10/20 9:40 AM, Paul Koning wrote:
Thanks, sorry for leaving that dangling.? I'll test that and merge it into my
code.
paul
------------------------------------------------------------------------
On Mar 10, 2020, at 4:28 AM, Keith Halewood<Keith.Halewood at
pitbulluk.org> <mailto:Keith.Halewood at pitbulluk.org> wrote:
Hi,
These are the changes:
In? Ethernet.py:
?? class _TapEth (_Ethernet):
?????? def open (self):
?????????? fd = os.open('/dev/net/tun', os.O_RDWR | os.O_NONBLOCK)
?????????? ifr = struct.pack('16sH', self.dev.encode('utf-8'),
IFF_TAP | IFF_NO_PI)
?????????? ioctl(fd, TUNSETIFF, ifr)
?????????? self.tap = fd
?????????? self.sellist = ( fd, )
?????????? # Turn the interface on -- needed only on Mac OS
With the definitions of those constants up near the top:
TUNSETIFF = 0x400454ca
TUNSETOWNER = TUNSETIFF + 2
IFF_TUN = 0x0001
IFF_TAP = 0x0002
IFF_NO_PI = 0x1000
Keith
------------------------------------------------------------------------
From:owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of David Moylan
Sent: 10 March 2020 07:46
To:hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE>
Subject: RE: [HECnet] Intermittent Connection with PyDECnet?
Robert Armstrong said on Tuesday, 10 March 2020 4:17 AM
FWIW, the "tap:" option in pyDECnet never worked for me.? I use
pcap
to
access tap devices -
??? circuit TAP-0 Ethernet pcap:tap0 --single-address --cost=2
works for me with Ubuntu 18.04...
When I first went to play with pyDECnet under Ubuntu 18, I also discovered issues
with the tap adapter. Fundamentally the issue comes down to newer kernels (such as in
Ubuntu 18) that use a /dev/net/tun interface to communicate instead of /dev/tapx
I heard on the list that Keith Halewood had modified Paul's code to work with
the newer interface standard, so I reached out to him and he provided me with the changes.
It's only a few lines of code that need modification.
I believe Keith has provided Paul with the changes. I'd love to see them
become mainstream in pyDECnet, as at the moment if I pull down a new build, I have to make
the modifications by hand again.
With the code changes, tap works a dream for me.
circuit tap-1022 Ethernet tap:tap1022 --random-address
cheers, Wiz!!