On Sun, 19 May 2013, Brian Hechinger wrote:
Eth: opened OS device tap1
Eth: Error Transmitting packet: Network is down
You may need to run as root, or install a libpcap version
which is at least 0.9 from your OS vendor or www.tcpdump.org
Eth: Error Transmitting packet: Network is down
You may need to run as root, or install a libpcap version
which is at least 0.9 from your OS vendor or www.tcpdump.org
XQ: MAC Address Conflict on LAN for address 08:00:2B:AA:BB:CC, change
the MAC address to a unique value
Eth: closed tap1
vax.ini> attach xq tap1
Unit not attachable
Ideas? From what I can determine, FreeBSD 9 ships with libpcap 1.2.1 (at
least as of a year ago).
I never used TUN/TAP on FreeBSD...I always added extra virtual NICs and used BPF there.
-brian
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
Eth: opened OS device tap1
Eth: Error Transmitting packet: Network is down
You may need to run as root, or install a libpcap version
which is at least 0.9 from your OS vendor or www.tcpdump.org
Eth: Error Transmitting packet: Network is down
You may need to run as root, or install a libpcap version
which is at least 0.9 from your OS vendor or www.tcpdump.org
XQ: MAC Address Conflict on LAN for address 08:00:2B:AA:BB:CC, change
the MAC address to a unique value
Eth: closed tap1
vax.ini> attach xq tap1
Unit not attachable
Ideas? From what I can determine, FreeBSD 9 ships with libpcap 1.2.1 (at
least as of a year ago).
-brian
http://rhesus.sampsa.com/medialib/vax/
On 19 May 2013, at 20:44, Brian Hechinger <wonko at 4amlunch.net> wrote:
I can't find my copy. I do know it exists on a machine that is powered
off, but that doesn't help me much. :)
Anyone have a copy handy that can be fetched from outside of HECnet?
-brian
I can't find my copy. I do know it exists on a machine that is powered
off, but that doesn't help me much. :)
Anyone have a copy handy that can be fetched from outside of HECnet?
-brian
OK,
Here's a really quick draft of what I'm thinking, feel free to add your thoughts
The parseable info begins with ".BEGIN-HECNET-INFO" and ends with ".END-HECNET-INFO"
The following columns must be present and named in the first line of the parseable block:
- ADDR - DECNET address of host
- NAME - DECNET node name of host
- OWNER - Person who owns the box*
- EMAIL - Contact email for the box's admin*
- HARDWARE - What hardware the box is running*
- OS - What operating system / software stack the system is running*
- LOCATION - Textual location of box, optionally long/lat info in some sane format*
The fields marked with an asterisk can be left empty but must be present in the header.
Example:
.BEGIN-HECNET-INFO
ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES
8.401|CHIMPY|Sampsa Laine |sampsa at mac.com |AlphaServer DS10 |OpenVMS 8.3 |London, England |Main SAMPSACOM system, SMTP gateway (CHIMPYMAIL.COM)
8.400|GORVAX|Sampsa Laine |sampsa at mac.com |SIMH VAX on OSX/Intel |OpenVMS 7.3 |London, England |MULTINET bridge to Area 2, Area router
8.403|RHESUS|Sampsa Laine |sampsa at mac.com |HP rx2600 Dual 900MHz |OpenVMS 8.4E |London, England |File libraries available
8.500|PYFFLE|Sampsa Laine |system at pyffle.com|VMWare |Ubuntu+Pyffle BBS |London, England |Waffle reimplementation BBS, log in as pyffle for access
.END-HECNET-INFO
On 19 May 2013, at 20:07, Sampsa Laine <sampsa at mac.com> wrote:
On 19 May 2013, at 20:03, Cory Smelosky <b4 at gewt.net> wrote:
On Sun, 19 May 2013, Sampsa Laine wrote:
On 19 May 2013, at 19:58, Cory Smelosky <b4 at gewt.net> wrote:
#6 is a provlem I've noticed with INFO.TXT. There's no order.
When me and Steve Davidson originally thought of adding parseable info to INFO.TXT we had the idea that the file itself would be free-form text with a machine parseable block at the end, with delimiters.
If you look at http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com?q=chimpy you'll see what I mean, there's a clearly defined block of machine readable CSV at the end.
How many people followed that though?
No idea - I don't think anyone ever wrote a parser.
But here's a brief outline of how I think this should work:
1. Someone (=me) defines the CSV format formally in a document
2. This document is passed around and corrected until majority is happy with it
3. Someone (=brian) writes a parser
4. People nominate boxes from where their INFO.TXTs should be pulled (one can cover a whole area or even more)
5. This is integrated into the DB using the parser from 3 periodically.
On 19 May 2013, at 20:03, Cory Smelosky <b4 at gewt.net> wrote:
On Sun, 19 May 2013, Sampsa Laine wrote:
On 19 May 2013, at 19:58, Cory Smelosky <b4 at gewt.net> wrote:
#6 is a provlem I've noticed with INFO.TXT. There's no order.
When me and Steve Davidson originally thought of adding parseable info to INFO.TXT we had the idea that the file itself would be free-form text with a machine parseable block at the end, with delimiters.
If you look at http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com?q=chimpy you'll see what I mean, there's a clearly defined block of machine readable CSV at the end.
How many people followed that though?
No idea - I don't think anyone ever wrote a parser.
But here's a brief outline of how I think this should work:
1. Someone (=me) defines the CSV format formally in a document
2. This document is passed around and corrected until majority is happy with it
3. Someone (=brian) writes a parser
4. People nominate boxes from where their INFO.TXTs should be pulled (one can cover a whole area or even more)
5. This is integrated into the DB using the parser from 3 periodically.
On Sun, 19 May 2013, Sampsa Laine wrote:
On 19 May 2013, at 19:58, Cory Smelosky <b4 at gewt.net> wrote:
#6 is a provlem I've noticed with INFO.TXT. There's no order.
When me and Steve Davidson originally thought of adding parseable info to INFO.TXT we had the idea that the file itself would be free-form text with a machine parseable block at the end, with delimiters.
If you look at http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com?q=chimpy you'll see what I mean, there's a clearly defined block of machine readable CSV at the end.
How many people followed that though?
sampsa
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
On 19 May 2013, at 19:58, Cory Smelosky <b4 at gewt.net> wrote:
#6 is a provlem I've noticed with INFO.TXT. There's no order.
When me and Steve Davidson originally thought of adding parseable info to INFO.TXT we had the idea that the file itself would be free-form text with a machine parseable block at the end, with delimiters.
If you look at http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com?q=chimpy you'll see what I mean, there's a clearly defined block of machine readable CSV at the end.
sampsa
On Sun, 19 May 2013, Brian Hechinger wrote:
On Sun, May 19, 2013 at 05:41:43PM -0000, Cory Smelosky wrote:
CSV as a data format is actually quite powerful, flexible and simple.
Let's just use Excel 97!
Shush you.
;)
6) This all needs to be documented somewhere.
#6 is a provlem I've noticed with INFO.TXT. There's no order.
This has been the problem with a lot of things for a long time. "Hey,
let's do this cool thing" comes up a lot, but nothing ever gets
documented so the usefulness of each thing fades as there is no
consistency to it.
I would like to change that this time around.
I would as well. This can go places.
-brian
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
