On 8 Jan 2015, at 05:37, Sampsa Laine <sampsa at mac.com> wrote:
On 8 Jan 2015, at 05:29, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-08 03:23, Paul_Koning at Dell.com wrote:
...
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Ideally there would be an RFC describing this. Is there? Or another spec that spells out the protocol encoding for this magic?
I haven't found any. :-(
On the other hand, I could have missed something.
The "old" way of possibly dealing with this would be to use the page structure mode in ftp, but that would appear to be seriously discouraged. And besides, it is still kindof a difficult fit here.
RFC 959 talks about a file structure command:
FILE STRUCTURE (STRU)
The argument is a single Telnet character code specifying
file structure described in the Section on Data
Representation and Storage.
The following codes are assigned for structure:
F - File (no record structure)
R - Record structure
P - Page structure
The default structure is File.
https://www.ietf.org/rfc/rfc959.txt
Not sure if this is of any help or works with any modern clients..
It's not even implemented in the VMS FTP server, where I could see the record structured files being quite useful..:
230 User logged in.
Remote system type is VMS.
ftp> stru
We only support file structure, sorry.
On 8 Jan 2015, at 05:29, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-08 03:23, Paul_Koning at Dell.com wrote:
...
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Ideally there would be an RFC describing this. Is there? Or another spec that spells out the protocol encoding for this magic?
I haven't found any. :-(
On the other hand, I could have missed something.
The "old" way of possibly dealing with this would be to use the page structure mode in ftp, but that would appear to be seriously discouraged. And besides, it is still kindof a difficult fit here.
RFC 959 talks about a file structure command:
FILE STRUCTURE (STRU)
The argument is a single Telnet character code specifying
file structure described in the Section on Data
Representation and Storage.
The following codes are assigned for structure:
F - File (no record structure)
R - Record structure
P - Page structure
The default structure is File.
https://www.ietf.org/rfc/rfc959.txt
Not sure if this is of any help or works with any modern clients..
On 2015-01-08 03:22, Paul_Koning at Dell.com wrote:
On Jan 7, 2015, at 9:03 PM, Johnny Billquist <bqt at softjar.se> wrote:
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work )
Usually, but it depends on the protocol. Some protocols FTP is a notorious example carry addresses and/or port numbers inside the application protocol data.
Right. And most any NAT box I know of knows this, and actually snoop the ftp control session to catch this so it can work.
But you are absolutely correct in that it is an extra level of excitement.
Does this server support passive mode? A lot of NAT servers need passive mode for FTP to work, or work more reliably if you use passive mode. (I just like passive mode because it isn t quite so conceptually broken as the older mode of FTP.)
I don't know about the VMS one. Mine do. :-)
But passive mode was in ftp already from the start, so anyone not implementing it would be rather silly. It is also required if you ever want to initiate a transfer between two boxes, if you yourself is on a third box.
And yes, passive mode is much easier for NAT to handle, since it looks much more like any normal session coming through. No need to snoop the ftp control channel in this case.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2015-01-08 03:23, Sampsa Laine wrote:
On 8 Jan 2015, at 04:03, Johnny Billquist <bqt at softjar.se> wrote:
Aha. Interesting output. That was sortof what I had a vague memory remembering it looking like. Now I need to decide if I want to do it similar.
Do people think file protection (for example) is useful to see? What about owner? I certainly have the information available, but I have not displayed it so far.
I would try to make it look as close to the *nix implementations, that way automated / GUI front-ends are more likely to work nicely with the server.
That is probably going to fail in various ways anyway, so it's not high on my list of priorities.
RSX (and VMS) file protection codes does not map well to Unix. And owner information is a even bigger headache in RSX, as you normally never do translate the UIC to something else. And presenting a UIC will already make it look very non-Unix. :-)
For example, I have a very nice GUI file transfer program called Transmit.app on OS X, but it REALLY gets confused when talking to VMS..
People try to be too clever. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2015-01-08 03:23, Paul_Koning at Dell.com wrote:
...
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Ideally there would be an RFC describing this. Is there? Or another spec that spells out the protocol encoding for this magic?
I haven't found any. :-(
On the other hand, I could have missed something.
The "old" way of possibly dealing with this would be to use the page structure mode in ftp, but that would appear to be seriously discouraged. And besides, it is still kindof a difficult fit here.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
...
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Ideally there would be an RFC describing this. Is there? Or another spec that spells out the protocol encoding for this magic?
paul
On 8 Jan 2015, at 04:03, Johnny Billquist <bqt at softjar.se> wrote:
Aha. Interesting output. That was sortof what I had a vague memory remembering it looking like. Now I need to decide if I want to do it similar.
Do people think file protection (for example) is useful to see? What about owner? I certainly have the information available, but I have not displayed it so far.
I would try to make it look as close to the *nix implementations, that way automated / GUI front-ends are more likely to work nicely with the server.
For example, I have a very nice GUI file transfer program called Transmit.app on OS X, but it REALLY gets confused when talking to VMS..
sampsa
On 2015-01-08 03:19, Sampsa Laine wrote:
On 8 Jan 2015, at 04:03, Johnny Billquist <bqt at softjar.se> wrote:
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work...)
IIRC unless the FTP server is working is "Passive Mode" port 21 is used just for control, and the server opens a random high-numbered port to which the client connects and the data is transferred over that - so that's where NAT'ing gets in the way.
Almost. In active mode, the ftp server initiates a second connection for data. This is by default on port 20 of the server, and by default to the same port as the control connection of the client. And the client is expected to listen for this specific connection.
However, NAT boxes normally knows this, and actually handles all needed for it to work.
I have no need for FTP on my boxes (I prefer Kermit) so haven't tried particularly hard to get around this problem.
:-)
Well, if your NAT box do something funny, then I'd just go for passive mode, which have a higher chance of working, since in that case, the client also opens the data connection.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 7, 2015, at 9:03 PM, Johnny Billquist <bqt at softjar.se> wrote:
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work )
Usually, but it depends on the protocol. Some protocols FTP is a notorious example carry addresses and/or port numbers inside the application protocol data.
Does this server support passive mode? A lot of NAT servers need passive mode for FTP to work, or work more reliably if you use passive mode. (I just like passive mode because it isn t quite so conceptually broken as the older mode of FTP.)
paul
On 8 Jan 2015, at 04:03, Johnny Billquist <bqt at softjar.se> wrote:
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work...)
IIRC unless the FTP server is working is "Passive Mode" port 21 is used just for control, and the server opens a random high-numbered port to which the client connects and the data is transferred over that - so that's where NAT'ing gets in the way.
I have no need for FTP on my boxes (I prefer Kermit) so haven't tried particularly hard to get around this problem.
sampsa
Thanks. (I doubt the VMS ftp server would care about NAT, it's not something the system behind a NAT knows or should care about. It's the NAT router who have to do all the work...)
Aha. Interesting output. That was sortof what I had a vague memory remembering it looking like. Now I need to decide if I want to do it similar.
Do people think file protection (for example) is useful to see? What about owner? I certainly have the information available, but I have not displayed it so far.
Johnny
On 2015-01-08 02:50, Sampsa Laine wrote:
So I opened port 21 on my router but I don't think the OpenVMS 7.3 UCX FTP server likes being behind NAT'd routers.
But here's some sample output I took from a simple DIR command:
kermit at gorilla:~$ ftp gorvax
Connected to gorvax.
220 gorvax.inside.sampsa.com FTP Server (Version 5.1) Ready.
Name (gorvax:kermit): bqt
331 Username bqt requires a Password
Password:
230 User logged in.
Remote system type is VMS.
ftp> dir
200 PORT command successful.
150 Opening data connection for SYS$SYSDEVICE:[BQT]*.*;* (192.168.77.202,55552)
Directory SYS$SYSDEVICE:[BQT]
SMGTERMS.TXT;1 170/171 20-MAY-2002 16:12:23 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;3
0/9 8-JAN-2015 03:46:12 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;2
1/9 8-JAN-2015 03:44:10 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;1
1/9 8-JAN-2015 03:43:20 [BQT] (RWED,RWED,RE,)
TERMTABLE.TXT;1 1/9 20-MAY-2002 16:12:24 [BQT] (RWED,RWED,RE,)
VMSHELP.EXE;1 11/18 20-MAY-2002 16:04:05 [BQT] (RWED,RWED,RE,)
Total of 6 files, 184/225 blocks
226 LIST Directory transfer complete.
On 8 Jan 2015, at 02:46, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-08 01:41, Mark Pizzolato - Info Comm wrote:
On Wednesday, January 07, 2015 at 4:35 PM, Johnny Billquist wrote:
On 2015-01-08 01:32, Sampsa Laine wrote:
I think I could get one up and running on GORVAX pretty quickly - what
exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output
format is sortof hackish. I'm thinking that maybe VMS have some nice format
that I can copy. There might be other tings I can get inspiration from
eventually as well, but LIST is the immediate interest.
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
So I opened port 21 on my router but I don't think the OpenVMS 7.3 UCX FTP server likes being behind NAT'd routers.
But here's some sample output I took from a simple DIR command:
kermit at gorilla:~$ ftp gorvax
Connected to gorvax.
220 gorvax.inside.sampsa.com FTP Server (Version 5.1) Ready.
Name (gorvax:kermit): bqt
331 Username bqt requires a Password
Password:
230 User logged in.
Remote system type is VMS.
ftp> dir
200 PORT command successful.
150 Opening data connection for SYS$SYSDEVICE:[BQT]*.*;* (192.168.77.202,55552)
Directory SYS$SYSDEVICE:[BQT]
SMGTERMS.TXT;1 170/171 20-MAY-2002 16:12:23 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;3
0/9 8-JAN-2015 03:46:12 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;2
1/9 8-JAN-2015 03:44:10 [BQT] (RWED,RWED,RE,)
TCPIP$FTP_SERVER.LOG;1
1/9 8-JAN-2015 03:43:20 [BQT] (RWED,RWED,RE,)
TERMTABLE.TXT;1 1/9 20-MAY-2002 16:12:24 [BQT] (RWED,RWED,RE,)
VMSHELP.EXE;1 11/18 20-MAY-2002 16:04:05 [BQT] (RWED,RWED,RE,)
Total of 6 files, 184/225 blocks
226 LIST Directory transfer complete.
On 8 Jan 2015, at 02:46, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-08 01:41, Mark Pizzolato - Info Comm wrote:
On Wednesday, January 07, 2015 at 4:35 PM, Johnny Billquist wrote:
On 2015-01-08 01:32, Sampsa Laine wrote:
I think I could get one up and running on GORVAX pretty quickly - what
exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output
format is sortof hackish. I'm thinking that maybe VMS have some nice format
that I can copy. There might be other tings I can get inspiration from
eventually as well, but LIST is the immediate interest.
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2015-01-08 01:41, Mark Pizzolato - Info Comm wrote:
On Wednesday, January 07, 2015 at 4:35 PM, Johnny Billquist wrote:
On 2015-01-08 01:32, Sampsa Laine wrote:
I think I could get one up and running on GORVAX pretty quickly - what
exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output
format is sortof hackish. I'm thinking that maybe VMS have some nice format
that I can copy. There might be other tings I can get inspiration from
eventually as well, but LIST is the immediate interest.
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
I know I read some manual about the DEC TCPIP package ftp server and client also managing this. It would, in fact, be nice to be compatible with that. However, atleast when storing or retreiving files from Unix systems, what DEC did is that they actually transfer two files. One with the data, and a separate one with the file metadata. Ugly, I think, and I would like to try and avoid that.
But that is a client only thing, as far as I can see. Anyone know how VMS does it if talking to another VMS system?
I suspect I might have a hard time if they do it by detecting that the remote server is a VMS system, since I will not lie about that. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Wednesday, January 07, 2015 at 4:35 PM, Johnny Billquist wrote:
On 2015-01-08 01:32, Sampsa Laine wrote:
I think I could get one up and running on GORVAX pretty quickly - what
exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output
format is sortof hackish. I'm thinking that maybe VMS have some nice format
that I can copy. There might be other tings I can get inspiration from
eventually as well, but LIST is the immediate interest.
The MultiNet FTP Server moves files between similarly capable FTP Clients and keeps the File Attributes consistent while copying data (i.e. You can simply ftp RMS Indexed files between VMS systems and the results will be immediately usable).
- Mark
On 2015-01-08 01:32, Sampsa Laine wrote:
Had one on RHESUS for ages but RHESUS is currently down for the foreseeable future.
Tried finding rhesus. Also tried HILANT without luck. :-)
I think I could get one up and running on GORVAX pretty quickly - what exactly are you looking for with regard to inspiration?
Right now I've implemented the LIST command, but the directory output format is sortof hackish. I'm thinking that maybe VMS have some nice format that I can copy. There might be other tings I can get inspiration from eventually as well, but LIST is the immediate interest.
If you could do it in a snap, that would be nice.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2015-01-08 01:31, Cory Smelosky wrote:
On Thu, 8 Jan 2015, Johnny Billquist wrote:
Do anyone have a VMS FTP server up and running on the internet? I'm
working on a FTP server for RSX, and figured I'd get some inspiration
from VMS for some details...
I can foward a port readily.
I also have 4.3BSD's one up 24x7.
Unix is not that meaningful, and besides, I have plenty to test against. VMS is much closer to RSX, and as such, can provide some more interesting ideas.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Had one on RHESUS for ages but RHESUS is currently down for the foreseeable future.
I think I could get one up and running on GORVAX pretty quickly - what exactly are you looking for with regard to inspiration?
sampsa
On 8 Jan 2015, at 02:29, Johnny Billquist <bqt at softjar.se> wrote:
Do anyone have a VMS FTP server up and running on the internet? I'm working on a FTP server for RSX, and figured I'd get some inspiration from VMS for some details...
So I need to look at one. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Thu, 8 Jan 2015, Johnny Billquist wrote:
Do anyone have a VMS FTP server up and running on the internet? I'm working on a FTP server for RSX, and figured I'd get some inspiration from VMS for some details...
I can foward a port readily.
I also have 4.3BSD's one up 24x7.
So I need to look at one. :-)
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Do anyone have a VMS FTP server up and running on the internet? I'm working on a FTP server for RSX, and figured I'd get some inspiration from VMS for some details...
So I need to look at one. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Absolutely Paul :-)
If I had any previous experience with that kind of coding I would at least gave a look. Seriously, it's not a one man job, right?
Anyway , it was a nice idea..
So if there's a spare decbrouter 90 around I'm willing to try that.
Hans
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Paul_Koning at Dell.com
Verzonden: zaterdag 3 januari 2015 16:54
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Hecnet Peering/Python
On Jan 3, 2015, at 3:02 AM, Hans Vlems <hvlems at zonnet.nl> wrote:
Paul,
the latest supported VMS versions for Python are 2.7.8 for Alpha and 2.7.9
for Itanium.
Which kind of kills the experiment, right? :(
Hans
Pretty much. It would be possible to port the code back to that version, but it would be a fair amount of work and not something I d be interested in. I prefer Python 3 for new projects for a number of reasons; some of those affect pydecnet significantly.
I suppose you could see what s involved in building Python 3.3 on VMS? :-)
paul
On Jan 3, 2015, at 3:02 AM, Hans Vlems <hvlems at zonnet.nl> wrote:
Paul,
the latest supported VMS versions for Python are 2.7.8 for Alpha and 2.7.9
for Itanium.
Which kind of kills the experiment, right? :(
Hans
Pretty much. It would be possible to port the code back to that version, but it would be a fair amount of work and not something I d be interested in. I prefer Python 3 for new projects for a number of reasons; some of those affect pydecnet significantly.
I suppose you could see what s involved in building Python 3.3 on VMS? :-)
paul
Paul,
the latest supported VMS versions for Python are 2.7.8 for Alpha and 2.7.9
for Itanium.
Which kind of kills the experiment, right? :(
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Paul_Koning at Dell.com
Verzonden: vrijdag 2 januari 2015 20:23
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Hecnet Peering
On Jan 2, 2015, at 2:08 PM, Hans Vlems <hvlems at zonnet.nl> wrote:
It would be nice to move the connection off a Linux box to a VMS system.
There is a libpcap version for VMS, it's used by simh.
The problem is Python. AFAIK that i s just v2.7 for VMS. I know my systems
run that kit, but I don't use it much so a newer version may be available.
Hans
The Python 3.3 what s new document says that VMS is no longer supported
due to lack of a maintainer . So it may be possible to build Python 3.2 on
VMS. The current DECnet/Python code wants 3.3, but earlier on I used 3.2
and there isn t much that needs 3.3. (In other words, it would not be all
that hard to change it back to allow 3.2.)
paul
-----
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2014.0.4794 / Virusdatabase: 4253/8859 - datum van uitgifte:
01/03/15
On 01/02/2015 09:17 PM, Johnny Billquist wrote:
One can tunnel most anything over GRE, even raw Ethernet
frames,
regardless of the higher-level protocols. Hence the 'G' for
"Generic".
Yes. But you need some ingress and egress that makes use of it. Or
else
we could just as well argue that UDP can tunnel anything.
...which it can. ;) On a Cisco, assigning a DECnet cost to an
interface (and a GRE endpoint is a pseudo-interface on a Cisco) forms
that ingress/egress.
(I know YOU know this; I'm saying it for the benefit of those
here who
are just learning about this)
Actually, I don't know the details, even though I pretty much know how
it *could* be done. I've pretty much never actually worked on a Cisco
box. :-)
However, DECnet costs cannot possibly be related, as we're now not
talking about DECnet protocols. (LAT and MOP are not using DECnet...)
You need to somehow tell the Cisco box to grab all ethernet packets
with
a certain protocol number, and pass those on over the tunnel, and have
the other end do the reverse.
Assigning a DECnet cost to a tunnel endpoint pseudo-interface
causes
it to pay attention to DECnet packets.
Which is not LAT and MOP. Which is what I've written multiple times now.
:-)
Right. I didn't say it was.
Seemed to me you implied it. Oh well. Me and english... :-)
Oh, nono...I'm sorry if it seemed that way.
DECnet packets are routed by the Cisco router. MOP and LAT are not
protocols running on top of DECnet, but are their own protocols directly
on ethernet. Which is also why they in essence are "local only", as they
cannot be routed.
...but they can be bridged, which you can ALSO do with a GRE tunnel.
The very same GRE tunnel as is handling DECnet, in fact.
Yes. And this is where it comes to me not knowing Ciscos. I know how you
do it in general if we talk networking. And this is just what my bridge
does, except it don't use GRE, but is more simple and stupid. :-)
I wouldn't say that; I think it's just that GRE is more standardized,
and typically ends in a router, which gives it more powerful
capabilities...but not by virtue of it being GRE.
But I assume there must be a way to tell a Cisco to bridge an arbitrary
ethernet protocol, using GRE as the tunneling protocol.
Yes there is. You can also bridge ALL packets on a network to a
different network, regardless of protocol.
I remember looking at the GRE interface under NetBSD many years ago when
I wanted to setup HECnet, but the documentation confused me in the
details, and I just wanted something really simple, so I wrote my own
bridge instead. It was a dirty hack on a dark night. It does (more or
less) do what I needed, but it's really just a quick hack.
Yes. Computer operating system-based implementations tend to be a bit
ridiculous. In a router it's more natural. I'm sure being written by
"router people" has a big positive influence on its implementation as
well, as opposed to being written by "operating system people".
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
On 2015-01-03 02:54, Dave McGuire wrote:
On 01/02/2015 08:43 PM, Johnny Billquist wrote:
One can tunnel most anything over GRE, even raw Ethernet frames,
regardless of the higher-level protocols. Hence the 'G' for
"Generic".
Yes. But you need some ingress and egress that makes use of it. Or
else
we could just as well argue that UDP can tunnel anything.
...which it can. ;) On a Cisco, assigning a DECnet cost to an
interface (and a GRE endpoint is a pseudo-interface on a Cisco) forms
that ingress/egress.
(I know YOU know this; I'm saying it for the benefit of those
here who
are just learning about this)
Actually, I don't know the details, even though I pretty much know how
it *could* be done. I've pretty much never actually worked on a Cisco
box. :-)
However, DECnet costs cannot possibly be related, as we're now not
talking about DECnet protocols. (LAT and MOP are not using DECnet...)
You need to somehow tell the Cisco box to grab all ethernet packets with
a certain protocol number, and pass those on over the tunnel, and have
the other end do the reverse.
Assigning a DECnet cost to a tunnel endpoint pseudo-interface causes
it to pay attention to DECnet packets.
Which is not LAT and MOP. Which is what I've written multiple times now.
:-)
Right. I didn't say it was.
Seemed to me you implied it. Oh well. Me and english... :-)
DECnet packets are routed by the Cisco router. MOP and LAT are not
protocols running on top of DECnet, but are their own protocols directly
on ethernet. Which is also why they in essence are "local only", as they
cannot be routed.
...but they can be bridged, which you can ALSO do with a GRE tunnel.
The very same GRE tunnel as is handling DECnet, in fact.
Yes. And this is where it comes to me not knowing Ciscos. I know how you do it in general if we talk networking. And this is just what my bridge does, except it don't use GRE, but is more simple and stupid. :-)
But I assume there must be a way to tell a Cisco to bridge an arbitrary ethernet protocol, using GRE as the tunneling protocol.
I remember looking at the GRE interface under NetBSD many years ago when I wanted to setup HECnet, but the documentation confused me in the details, and I just wanted something really simple, so I wrote my own bridge instead. It was a dirty hack on a dark night. It does (more or less) do what I needed, but it's really just a quick hack.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2015-01-03 02:49, Paul_Koning at Dell.com wrote:
On Jan 2, 2015, at 8:41 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-03 02:13, Paul_Koning at Dell.com wrote:
On Jan 2, 2015, at 7:57 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-02 19:07, Paul_Koning at Dell.com wrote:
On Jan 2, 2015, at 12:34 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-01-02 18:28, Hans Vlems wrote:
Is there an advantage if you use a tunnel in stead of Johnny's bridge
program which I use?
It scales better and use less network bandwidth, if that is a concern.
Less network bandwidth because the GRE tunnel doesn t use Ethernet padding and regular Ethernet headers, while the JB bridge is a bridge so it does have both of those?
That seems like the only difference; from the DECnet routing layer point of view, both are LAN links and the protocol operation is the same for both.
No, you're not thinking about the larger picture, Paul. :-)
Like I responded myself. One "problem" is all the routers that are broadcasting. Both hello messages and routing updates. And they need to go to all bridges connected. While if you had a tunnel between two routers, you'll end up with just the chatter between those two routers. Any routers located on each end, or elsewhere, is of no concern for the link.
But you re comparing different cases. GRE is like a two-station Ethernet; your bridge is more general. The flooding case of a bridge makes a difference only if you have more than two stations.
Right. But we should not talk about GRE here, because that just confuse the issue. The thing is, the Ciscos are routers, with a tunnel between the two routers. So you only have these two routers talking to each other over the tunnel.
With the bridge, you do not get that isolation. You will instead have every router on each side (even if you just have two points to the bridge) talking across the bridge. So the number of packets over the bridge is essentially proportional to the number of routers connected to the ethernet segments.
And in the HECnet specific case, the bridge actually have around 10 active points, and atleast one router at each point
Ok. But if someone wanted the efficiency of a GRE tunnel without having a device capable of talking that protocol, one could set up another instance of a JB bridge, with just those two systems on it. Then it would be just as efficient.
If you also placed a router between the rest of the net and the bridge then yes, then they become equivalent.
I agree that if you compare a point to point topology tunnel with a 10-point bridge, the two necessarily look rather different.
Yeah... :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
