I've set up the bridge to start at boot on an OpenBSD machine and I am having some issues getting anything into a log file.
I start it like this:
/var/bridge/bridge -p 4711 -d /var/bridge/ > /var/bridge/bridge.log 2>&1 &
but bridge.log is always empty. At start, after sending SIGUSR1, etc.
Thoughts?
-brian
That's a pity, because I've always wanted to know whether the same trick would apply. The white box trick worked for me on the 3300 and a couple of 5305's. A 7305 owner in Germany made it work too. The DS20L is a different beast, right? Enough not too spend money on it. Hans
-----Original Message-----
From: "John H. Reinhardt" <johnhreinhardt at yahoo.com>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 08:00:18
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation - 1U Alpha systems.
On 8/10/12 2:58 AM, hvlems at zonnet.nl wrote:
If the "fiddling" is similar to what is necessary to run VMS on the white box alphas then have a look at
http://home.zonnet.nl/hvlems
The white box alphas were tergeted at the WNT market. Adding two srm parameters works wonders for VMS. It does not involve hardware mods and AFAIK the mods are completely reversible.
Hans
PS
Sent from my cell phone which will undoubtedly upset some systems. Sorry, I'm 600 kms from home.
Yeah, I don't know. I've got a white box AS1200 (aka 5305) that I
twiddled to run VMS on and I know how that works. All I ever saw was a
vague reference on comp.os.vms once about the DS20L. I was never able
to acquire one so I didn't pursue the issue.
-----Original Message-----
From: "John H. Reinhardt"<johnhreinhardt at yahoo.com>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 01:30:11
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation - 1U Alpha systems.
On 8/9/12 11:00 PM, Dave McGuire wrote:
On 08/09/2012 10:54 PM, Gregg Levine wrote:
Dave did the Alpha family come in a 1U size?
Yes, the DS10L comes to mind. My HECnet node AXPEE:: is one of those.
They are EV6-based (nice and quick!) and are available clocked at
466MHz and 600MHz.
There are other 1U models, but that's the one I'm most familiar with.
If so could said system be considered to be a quiet one?
Eh, so-so.
From DEC, there was only the DS10L, in two processor speeds as Dave
mentioned, and the DS20L which was an 833MHz processor system in the 1U
size. The DS10L was supported for use with any of the DEC O/S while the
DS20L was only supported for Tru64 from DEC and Linux. VMS was not a
supported O/S, although it was purported to be possible to get it to
boot with some fiddling. Unfortunately, I was never privy to the
details of such.
http://h18002.www1.hp.com/alphaserver/archive/ds20l/http://h18000.www1.hp.com/products/quickspecs/10976_na/10976_na.HTML
Alpha Processors Inc (API) also produced a 1U system. Based on the
DS20L platform, they aimed for the HPC cluster market. Also purported
to be possible to boot VMS with some fiddling, but the usual O/S was
some form of Linux. http://youtu.be/RfowtlIk9Uc
All were fairly noisy for their size. Maybe not noticeable in a
computer center, but definitely in a home setting.
John H. Reinhardt
Brian, could you verify that you have the latest version? I did some work to try and get rid of warnings a while back, and even though I'm sure some issues might be because of 64 bit issues, I would have expected some of the warnings you reported to have been fixed already...
Johnny
On 2012-08-09 21:00, Brian Hechinger wrote:
I'm trying to get the bridge built on OpenBSD 5.1 64-bit but it keep
segfaulting. Anyone ever get this working?
# cc -O2 -Wall -o bridge bridge.c -lpcap
bridge.c:65:1: warning: "MAX" redefined
In file included from /usr/include/netdb.h:90,
from bridge.c:32:
/usr/include/sys/param.h:191:1: warning: this is the location of the
previous definition
bridge.c: In function 'add_bridge':
bridge.c:241: warning: implicit declaration of function 'inet_aton'
bridge.c:263: warning: format '%d' expects type 'int', but argument 2
has type 'char *'
bridge.c:263: warning: format '%d' expects type 'int', but argument 3
has type 'char *'
bridge.c: In function 'add_service':
bridge.c:276: warning: format '%s' expects type 'char *', but argument 3
has type 'struct BRIDGE *'
bridge.c: In function 'dump_data':
bridge.c:524: warning: implicit declaration of function 'inet_ntoa'
bridge.c:531: warning: format '%s' expects type 'char *', but argument 4
has type 'int'
bridge.c: In function 'main':
bridge.c:564: warning: unused variable 'port'
bridge.c:561: warning: unused variable 'len'
/tmp//cc69aRp2.o(.text+0x934): In function `add_bridge':
: warning: strcpy() is almost always misused, please use strlcpy()
# cp bridge /var/bridge/
# cd /var/bridge/
# ./bridge 4711
Adding router ''local''. 00000000:0
Adding router ''sampsa''. 0afc2a0a:4711
Adding DECnet bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding DECnet bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Adding LAT bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding LAT bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Host table:
Segmentation fault (core dumped)
-brian
On 2012-08-10 11:55, Sampsa Laine wrote:
Aargh just realised,
Those nodes should've been 52, not 5.
So:
52.555 LABVAX
52.556 KUHAVX
52.600 DEB390
Whoops. :-)
Updated now.
Johnny
Sampsa
On 10 Aug 2012, at 12:48, Sampsa Laine wrote:
I'm talking about the DECNET for Linux MULTINET UDP tunnelling..
Sampsa
On 10 Aug 2012, at 12:47, Rok Vidmar wrote:
3. I assume I need an area for that, or am I incorrect?
With Multinet you can run DECnet over TCP in the same
DECnet area.
--
Regards, Rok
I'm talking about the DECNET for Linux MULTINET UDP tunnelling..
I'm talking about the DECNET for VMS Multinet UDP tunnelling.
Why should be the two different?
--
Regards, Rok
Aargh just realised,
Those nodes should've been 52, not 5.
So:
52.555 LABVAX
52.556 KUHAVX
52.600 DEB390
Sampsa
On 10 Aug 2012, at 12:48, Sampsa Laine wrote:
I'm talking about the DECNET for Linux MULTINET UDP tunnelling..
Sampsa
On 10 Aug 2012, at 12:47, Rok Vidmar wrote:
3. I assume I need an area for that, or am I incorrect?
With Multinet you can run DECnet over TCP in the same
DECnet area.
--
Regards, Rok
On 10 Aug 2012, at 12:52, Johnny Billquist wrote:
Yes, you are incorrect. There is nothing that requires an area here, and it just means you need to deal with a full blown DECnet stack, instead of a simpler endnode.
It might be worth understanding that there is nothing technical added by going to multiple areas. It is just a complication which allows you to have more nodes, but at the cost of more complex routing.
Even within one area, you can have a large number of hops between nodes. Makes no difference to DECnet. The rules for the topological layout is simple:
1. End-nodes needs to be adjacent to atleast one level 1 router.
2. All level 1 routers in an area must be able to talk with all other level 1 routers. And only level 1 routers route messages within an area, which means you cannot have an endnode in the chain.
The layout can be a star, a ring, a line, a combination, hybrid, or whatever. There are absolutely no topology that you can't have.
The type of links can also be anything. Ethernet, multidrop, point-to-point, or something weird. Makes no difference.
Ok, my bad, misunderstood the UDP Mutlinet tunnels :)
Drop that node and add DEB390 with the address 52.600 when you get the chance.
Sampsa
On 2012-08-10 11:42, Sampsa Laine wrote:
OK, my reasoning is this:
1. The z/Arch emulator hasn't got any ethenet support, just a CTC point to point link to the host
Area or not makes no difference for this.
2. I'll run MULTINET on both the Debian S/390 and the host
And? Another area makes no difference for this. (I thought Multinet was a TCP/IP stack in VMS... :-) )
3. I assume I need an area for that, or am I incorrect?
Yes, you are incorrect. There is nothing that requires an area here, and it just means you need to deal with a full blown DECnet stack, instead of a simpler endnode.
It might be worth understanding that there is nothing technical added by going to multiple areas. It is just a complication which allows you to have more nodes, but at the cost of more complex routing.
Even within one area, you can have a large number of hops between nodes. Makes no difference to DECnet. The rules for the topological layout is simple:
1. End-nodes needs to be adjacent to atleast one level 1 router.
2. All level 1 routers in an area must be able to talk with all other level 1 routers. And only level 1 routers route messages within an area, which means you cannot have an endnode in the chain.
The layout can be a star, a ring, a line, a combination, hybrid, or whatever. There are absolutely no topology that you can't have.
The type of links can also be anything. Ethernet, multidrop, point-to-point, or something weird. Makes no difference.
Johnny
Sampsa
On 10 Aug 2012, at 12:40, Johnny Billquist wrote:
On 2012-08-10 09:08, Sampsa Laine wrote:
5.555 LABVAX
5.556 KUHAVX
9.390 DEB390
Done (Although the area 9 thing is silly, and will probably just make your life harder).
Johnny
I'm talking about the DECNET for Linux MULTINET UDP tunnelling..
Sampsa
On 10 Aug 2012, at 12:47, Rok Vidmar wrote:
3. I assume I need an area for that, or am I incorrect?
With Multinet you can run DECnet over TCP in the same
DECnet area.
--
Regards, Rok
