It's fixed, thanks Johnny
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Johnny Billquist
Verzonden: zondag 25 mei 2014 20:23
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] bridge problem area 44
On 2014-05-25 20:16, Hans Vlems wrote:
My bridge program no longer connects to the other end. Did something change?
I had some issues about a week ago where it seemed your end was going
yo-yo all the time, so I disabled it to test things. Forgot to turn it
back on. Fixed now.
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 Sun, 25 May 2014, Dave McGuire wrote:
On 05/25/2014 10:10 AM, Cory Smelosky wrote:
Got bored of copying stuff using (virtual) serial, eh? ;)
Get an M+ system with split I/D space, and use my TCP/IP instead... :-)
If all goes well whenever Dave heads out this way he'll be dropping off
some -11s that HOPEFULLY have split I&D.
I peeked into the side vents of one of them; it has a J11 of some
sort, so you should be good there!
Sweet!
-Dave
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Sun, 25 May 2014, Brian Hechinger wrote:
On Sun, May 25, 2014 at 11:56:20PM +0800, Tim Sneddon wrote:
Thanks for the mention Brian. Yes, I am happy to help out. I'm not sure
what is going on with Cory's tunnel to you, but I certainly have mine
working:
a12rtr#show decnet neigh
Net Node Interface MAC address Flags
0 9.1023 Tunnel52 0000.0000.0000 A
I have compared our tunnel configs and they are both the same, so I'm
guessing it is a Cory's end.
Cory, let me know if you want some help fixing this, although it seems your
up to your eyeballs in it with your 11/23+.
The issue isn't tunnels, exactly. It's the fact that I currently can't
contact Cory's router via SNMP to push the new config to. This doesn't
affect people like you who's tunnel config is still correct but does
affect someone like me who's IP has changed so Cory's router can no
longer talk to me. And I can't update it because his router refuses to
talk to me. :)
Oh, SNMP push works. TFTP doesn't.
-brian
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 05/25/2014 01:13 PM, Johnny Billquist wrote:
Essentially, the MAC address in the actual ethernet controller (or the
MAC address set before boot in simh) is irrelevant. Once DECnet starts
running, that MAC address is not used anymore. It is just a trivia piece
of information so that you can know what the hardware MAC address from
the factory is. It is not used by anything, especially not anything
related to network communication.
The only reason I might find the actual hard-coded MAC address to be
useful is in identifying machines. A lot of Ethernet cabinet kits have
stickers on them with the MAC address printed on them.
Of course nearly every one I've seen has been WRONG, but.. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 05/25/2014 10:10 AM, Cory Smelosky wrote:
Got bored of copying stuff using (virtual) serial, eh? ;)
Get an M+ system with split I/D space, and use my TCP/IP instead... :-)
If all goes well whenever Dave heads out this way he'll be dropping off
some -11s that HOPEFULLY have split I&D.
I peeked into the side vents of one of them; it has a J11 of some
sort, so you should be good there!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2014-05-25 20:22, Jean-Yves Bernier wrote:
At 4:05 PM +0200 25/5/14, Johnny Billquist wrote:
Like I said before. I would start by examining various counters on the
machines to
get more understanding of what the problem is, and then try to solve
it from there.
I know that different network interface speeds mess things up, for
example, and I
have code in my bridge to help get around the problem if the bridge is
sitting
between the systems.
and you would see
49 Data overrun
and growing.
This is on the node running NFT, not FAL.
The plot narrows.
For completeness (feeding Google) : 2 11M+ DECnet nodes running inside
simh inside a same instance of a VirtualBox Linux machine.
More interesting would be to see EXEC COUNTERS, as well as counters for the two nodes, from both sides.
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 2014-05-25 20:16, Hans Vlems wrote:
My bridge program no longer connects to the other end. Did something change?
I had some issues about a week ago where it seemed your end was going yo-yo all the time, so I disabled it to test things. Forgot to turn it back on. Fixed now.
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
At 4:05 PM +0200 25/5/14, Johnny Billquist wrote:
Like I said before. I would start by examining various counters on the machines to
get more understanding of what the problem is, and then try to solve it from there.
I know that different network interface speeds mess things up, for example, and I
have code in my bridge to help get around the problem if the bridge is sitting
between the systems.
and you would see
49 Data overrun
and growing.
This is on the node running NFT, not FAL.
The plot narrows.
For completeness (feeding Google) : 2 11M+ DECnet nodes running inside simh inside a same instance of a VirtualBox Linux machine.
--
Jean-Yves Bernier
Sounds like a good idea. Probably takes less time to do than what I suggested.
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Jean-Yves Bernier
Verzonden: zondag 25 mei 2014 19:40
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Same MAC address on different nodes
At 7:04 PM +0200 25/5/14, Hans Vlems wrote:
Anyway, i'd stop using the same 08-00-2B address on two nodes,
shutdown the simulators the VM host and the real iron.
I have another idea waiting in the queue : virtualize a second NIC
and have each node have it's own. Bridge the virtual NIC's with real
ones, so they communicate over wire.
10.1 -> AA-00-04-00-01-28 -> 08:00:27:DA:68:3D en0 Linux <-> en0 MacPro
10.2 -> AA-00-04-00-02-28 -> 08:00:27:A9:51:87 en1 Linux <-> en1 MacPro
--
Jean-Yves Bernier
