it needs to maintain a session table to keep track of which
IP addresses and port numbers map to which systems and port numbers
locally.
I guess that's the issue - you (or your router) really needs a way to
statically define these associations (at least in some specific cases). I
sort of assumed all routers could do that, but maybe I expect too much.
Bob
With my connection, I noticed that the circuit would disconnect and
reconnect periodically. It corresponded to the timeout in my firewall
causing the UDP association to be lost. When I increased the timeout
in my firewall for these port 700 UDP "connections", that made my
circuit much more stable.
Like Peter said, Peter and I had a big debate about this at lunch today.
UDP is, by definition (or so I thought), both stateless and connectionless.
I can't understand what state or connection is being timed out in this
case....
Yes, a UDP session is connectionless, however when a firewall is doing NAT and/or PAT (remember I mentioned that my firewall is randomizing the source port number, so the LAN port numbers are different from the ones sent over the internet), it needs to maintain a session table to keep track of which IP addresses and port numbers map to which systems and port numbers locally. Those connections time out after a while, and then subsequent UDP packets wouldn't be recognized.
--Marc
Marc Chametzky wrote:
With my connection, I noticed that the circuit would disconnect and
reconnect periodically. It corresponded to the timeout in my firewall
causing the UDP association to be lost. When I increased the timeout
in my firewall for these port 700 UDP "connections", that made my
circuit much more stable.
Like Peter said, Peter and I had a big debate about this at lunch today.
UDP is, by definition (or so I thought), both stateless and connectionless.
I can't understand what state or connection is being timed out in this
case....
Bob
The Internet between two end-systems is by arkitekture completely state less when it comes to
knewing anything about what the packets are all about... Unfortenly people love to break that
model to *add value*... -:)
-P
Marc Chametzky wrote:
With my connection, I noticed that the circuit would disconnect and
reconnect periodically. It corresponded to the timeout in my firewall
causing the UDP association to be lost. When I increased the timeout
in my firewall for these port 700 UDP "connections", that made my
circuit much more stable.
Like Peter said, Peter and I had a big debate about this at lunch today.
UDP is, by definition (or so I thought), both stateless and connectionless.
I can't understand what state or connection is being timed out in this
case....
Bob
and Bob A has a home gw (forgot what it
was) that he claims do the right thing, (not decnet routing..)
Well, I have a Netgear FVS338. It's a "SOHO" box - somewhere between a
turnkey home router and a fancy Cisco box. I never thought of it as all
that great, but it does allow me to set up static routes. In particular I
can map specific external ports/Internet IPs to internal ports/IPs
independent of the NAT.
Bob
With my connection, I noticed that the circuit would disconnect and
reconnect periodically. It corresponded to the timeout in my firewall
causing the UDP association to be lost. When I increased the timeout in
my firewall for these port 700 UDP "connections", that made my circuit
much more stable.
Unfortunately, my firewall (a SonicWALL NSA 240) is also stupid in that
it *must* randomize the source port for outgoing packets, so I'm not
able to connect to HECnet because MultiNet insists that the source port
must also be 700 and mine are coming through with random port numbers.
--Marc
IP and UDP is connection-less.. -:)
Throw the firewall away. Find a real router that can do DECnet routing
and NAT and Firewall somwhere. ..
We had this discussion at DCL, and Bob A has a home gw (forgot what it
was) that he claims do the right thing, (not decnet routing..)
-P
Do you know what is the equivalent file for TOPS-10? Is that
SYSJOB.INI?
opr.ato
Understood.
Now I've got another problem. The TOPS-10 node goes yo-yo:
$
%%%%%%%%%%% OPCOM 9-JUN-2012 13:58:58.19 %%%%%%%%%%%
Message from user DECNET on BITXOV
DECnet event 4.18, adjacency down
=46rom node 7.60 (BITXOV), 9-JUN-2012 13:58:58.19
Circuit QNA-0, Adjacent node listener receive timeout
Adjacent node =3D 7.80 (BITXT1)
$
%%%%%%%%%%% OPCOM 9-JUN-2012 13:59:09.10 %%%%%%%%%%%
Message from user DECNET on BITXOV
DECnet event 4.15, adjacency up
=46rom node 7.60 (BITXOV), 9-JUN-2012 13:59:05.04
Circuit QNA-0, Adjacent node =3D 7.80 (BITXT1)
=20
The TOPS-20 one is connected to the same virtual bridge and it is =
running in the same virtual machine, but it runs OK. Any idea? (My =
suspect is the NI configuration in the KHL ini file...)
It's outside tops10, I guess, and I'm completely lost there. If my
braincells starts to work I will rember how to log all the DECnet
packets on the -10 side.
--P
I see these message about every 20 minutes from random nodes. The error
message is almost always:
"Unexpected packet type"
A: Something is corrupting the packet, or they are out of order or a
packet disapeared.
B: Someone is sending packets to you that looks like Multinet Decnet,
but not one of your "peers".
So where do we go from here?
We need more information, and if we can se a pattern.
A: Is there any Multinet link that is stable?
B: Is it related to a site?
If we could do TCPDUMP on this wire with NTP based timestaps on both
sides, we can se what get's corrupted or disappears?
As per subject:
6.3 ITANIC (OpenVMS 8.4 I64)
6.11 BGATES (Windows XP Pro / Pathworks32)
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
