Which all, in my eye, points to that klh10 decides to drop DECnet packets.
Johnny
Mark Abene wrote:
I admit, the fact that LAT "just works" is very puzzling to me.
Enabling debugging on dpni20 isn't very helpful, as I don't see evidence
of anything failing. The thing just doesn't transmit any DECnet traffic
over ethernet. I can SET HOST to my own machine, so I know at least in
principle the protocol is up, however only locally.
Johnny Billquist wrote:
One important detail you left out Mark, is that LAT traffic is working
fine from your klh10 machine.
Do you see any of those multicast addresses? Otherwise I think that's a
red herring.
Since LAT works, we can really narrow things down quite a lot.
Johnny
Mark Abene skrev:
So, as for my problem with Johnny's bridge, I discovered the write(2) to
bridge 0 was failing because I was compiling and linking to an outdated
libpcap. That was easily remedied and now I have DECnet traffic on my
bridged-tap. Yay. However, the problem I detailed below is still
plaguing me, and still after digging through klh10 source it remains a
mystery. Apparently the DECnet multicast addresses are maintained in
the emulated pdp10's memory, in a table called MCAT. This occurs in the
dpni20's function eth_mcatset() which calls osn_ifmcset() in osdnet.c.
Strangely, it thinks it's succeeding, and though the multicast addresses
don't appear in "netstat -ani", a "vmstat -m | grep ether_multi" shows
the in-use counter is incrementing each time, including when I add them
manually with mtest. I highly suspect that the dpni20 driver is getting
confused somewhere, since with the bridged-tap setup it maintains an
internal "10-side" IP and MAC address which is not visible to the OS's
interface table, and only manifests in the ARP table. Presently,
klh10's "enaddr" command-line utility stopped giving errors on adding
the requisite multicast addresses, but ether_multi is *not* incremented,
and the warning enaddr: No EN addr in iftab for "tap0" is given, telling
me that nothing is really happening. This is telling, since enaddr
exercises the same functions in osdnet.c that the emulator itself uses.
As a test I think I may try setting the dedicated interface to a real
ethernet instead of the virtual tap, to see if I can resolve the
multicast issues. At the moment this seems to be the show stopper.
Mark
Mark Abene wrote:
I wanted to be doing a netstat -ani, (-g only shows multicast for
ipv4/6), but the result is the same. None of the DECnet multicast
addresses are being added, most notably (and absolutely necessary) are:
ab:0:0:3:0:0 - type 6003 - for DECnet Phase IV end node Hello packets
from each host, and
ab:0:0:4:0:0 - type 6003 - for DECnet Phase IV router Hello packets from
the router.
I've tried adding these with both enaddr from KLH10 and FreeBSD's
built-in "mtest", but both return errors. This seems to be a
FreeBSD-specific problem which so far I'm unable to find the reason for.
Mark
Mark Abene wrote:
Mark Abene wrote:
I've actually made a new discovery... looking at "netstat -g", I'm
seeing that none of the multicast addresses exist that DECnet uses and
requires! This would explain why I don't see any DECnet traffic at
all.
I compiled KLH10's enaddr utility in an attempt to add the multicast
addresses manually, and I get failures for all attempts...
"SIOCADDMULTI failed - Can't assign requested address". My server's
kernel wasn't built with multicast routing enabled, which is not a
default. I'm wondering if this is the cause of the error. I'm
going to
do some further testing.
Regards
Mark
Well I was mistaken about the multicast routing, that's only for doing
DVMRP with mrouted (MBONE, etc). Local LAN multicast should work "out
of the box" on FreeBSD. Still trying to track down why this is
failing,
since it's my primary candidate for DECnet not working...
I admit, the fact that LAT "just works" is very puzzling to me.
Enabling debugging on dpni20 isn't very helpful, as I don't see evidence
of anything failing. The thing just doesn't transmit any DECnet traffic
over ethernet. I can SET HOST to my own machine, so I know at least in
principle the protocol is up, however only locally.
Johnny Billquist wrote:
One important detail you left out Mark, is that LAT traffic is working
fine from your klh10 machine.
Do you see any of those multicast addresses? Otherwise I think that's a
red herring.
Since LAT works, we can really narrow things down quite a lot.
Johnny
Mark Abene skrev:
So, as for my problem with Johnny's bridge, I discovered the write(2) to
bridge 0 was failing because I was compiling and linking to an outdated
libpcap. That was easily remedied and now I have DECnet traffic on my
bridged-tap. Yay. However, the problem I detailed below is still
plaguing me, and still after digging through klh10 source it remains a
mystery. Apparently the DECnet multicast addresses are maintained in
the emulated pdp10's memory, in a table called MCAT. This occurs in the
dpni20's function eth_mcatset() which calls osn_ifmcset() in osdnet.c.
Strangely, it thinks it's succeeding, and though the multicast addresses
don't appear in "netstat -ani", a "vmstat -m | grep ether_multi" shows
the in-use counter is incrementing each time, including when I add them
manually with mtest. I highly suspect that the dpni20 driver is getting
confused somewhere, since with the bridged-tap setup it maintains an
internal "10-side" IP and MAC address which is not visible to the OS's
interface table, and only manifests in the ARP table. Presently,
klh10's "enaddr" command-line utility stopped giving errors on adding
the requisite multicast addresses, but ether_multi is *not* incremented,
and the warning enaddr: No EN addr in iftab for "tap0" is given, telling
me that nothing is really happening. This is telling, since enaddr
exercises the same functions in osdnet.c that the emulator itself uses.
As a test I think I may try setting the dedicated interface to a real
ethernet instead of the virtual tap, to see if I can resolve the
multicast issues. At the moment this seems to be the show stopper.
Mark
Mark Abene wrote:
I wanted to be doing a netstat -ani, (-g only shows multicast for
ipv4/6), but the result is the same. None of the DECnet multicast
addresses are being added, most notably (and absolutely necessary) are:
ab:0:0:3:0:0 - type 6003 - for DECnet Phase IV end node Hello packets
from each host, and
ab:0:0:4:0:0 - type 6003 - for DECnet Phase IV router Hello packets from
the router.
I've tried adding these with both enaddr from KLH10 and FreeBSD's
built-in "mtest", but both return errors. This seems to be a
FreeBSD-specific problem which so far I'm unable to find the reason for.
Mark
Mark Abene wrote:
Mark Abene wrote:
I've actually made a new discovery... looking at "netstat -g", I'm
seeing that none of the multicast addresses exist that DECnet uses and
requires! This would explain why I don't see any DECnet traffic at
all.
I compiled KLH10's enaddr utility in an attempt to add the multicast
addresses manually, and I get failures for all attempts...
"SIOCADDMULTI failed - Can't assign requested address". My server's
kernel wasn't built with multicast routing enabled, which is not a
default. I'm wondering if this is the cause of the error. I'm
going to
do some further testing.
Regards
Mark
Well I was mistaken about the multicast routing, that's only for doing
DVMRP with mrouted (MBONE, etc). Local LAN multicast should work "out
of the box" on FreeBSD. Still trying to track down why this is
failing,
since it's my primary candidate for DECnet not working...
One important detail you left out Mark, is that LAT traffic is working fine from your klh10 machine.
Do you see any of those multicast addresses? Otherwise I think that's a red herring.
Since LAT works, we can really narrow things down quite a lot.
Johnny
Mark Abene skrev:
So, as for my problem with Johnny's bridge, I discovered the write(2) to
bridge 0 was failing because I was compiling and linking to an outdated
libpcap. That was easily remedied and now I have DECnet traffic on my
bridged-tap. Yay. However, the problem I detailed below is still
plaguing me, and still after digging through klh10 source it remains a
mystery. Apparently the DECnet multicast addresses are maintained in
the emulated pdp10's memory, in a table called MCAT. This occurs in the
dpni20's function eth_mcatset() which calls osn_ifmcset() in osdnet.c.
Strangely, it thinks it's succeeding, and though the multicast addresses
don't appear in "netstat -ani", a "vmstat -m | grep ether_multi" shows
the in-use counter is incrementing each time, including when I add them
manually with mtest. I highly suspect that the dpni20 driver is getting
confused somewhere, since with the bridged-tap setup it maintains an
internal "10-side" IP and MAC address which is not visible to the OS's
interface table, and only manifests in the ARP table. Presently,
klh10's "enaddr" command-line utility stopped giving errors on adding
the requisite multicast addresses, but ether_multi is *not* incremented,
and the warning enaddr: No EN addr in iftab for "tap0" is given, telling
me that nothing is really happening. This is telling, since enaddr
exercises the same functions in osdnet.c that the emulator itself uses.
As a test I think I may try setting the dedicated interface to a real
ethernet instead of the virtual tap, to see if I can resolve the
multicast issues. At the moment this seems to be the show stopper.
Mark
Mark Abene wrote:
I wanted to be doing a netstat -ani, (-g only shows multicast for
ipv4/6), but the result is the same. None of the DECnet multicast
addresses are being added, most notably (and absolutely necessary) are:
ab:0:0:3:0:0 - type 6003 - for DECnet Phase IV end node Hello packets
from each host, and
ab:0:0:4:0:0 - type 6003 - for DECnet Phase IV router Hello packets from
the router.
I've tried adding these with both enaddr from KLH10 and FreeBSD's
built-in "mtest", but both return errors. This seems to be a
FreeBSD-specific problem which so far I'm unable to find the reason for.
Mark
Mark Abene wrote:
Mark Abene wrote:
I've actually made a new discovery... looking at "netstat -g", I'm
seeing that none of the multicast addresses exist that DECnet uses and
requires! This would explain why I don't see any DECnet traffic at all.
I compiled KLH10's enaddr utility in an attempt to add the multicast
addresses manually, and I get failures for all attempts...
"SIOCADDMULTI failed - Can't assign requested address". My server's
kernel wasn't built with multicast routing enabled, which is not a
default. I'm wondering if this is the cause of the error. I'm going to
do some further testing.
Regards
Mark
Well I was mistaken about the multicast routing, that's only for doing
DVMRP with mrouted (MBONE, etc). Local LAN multicast should work "out
of the box" on FreeBSD. Still trying to track down why this is failing,
since it's my primary candidate for DECnet not working...
--
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, as for my problem with Johnny's bridge, I discovered the write(2) to
bridge 0 was failing because I was compiling and linking to an outdated
libpcap. That was easily remedied and now I have DECnet traffic on my
bridged-tap. Yay. However, the problem I detailed below is still
plaguing me, and still after digging through klh10 source it remains a
mystery. Apparently the DECnet multicast addresses are maintained in
the emulated pdp10's memory, in a table called MCAT. This occurs in the
dpni20's function eth_mcatset() which calls osn_ifmcset() in osdnet.c.
Strangely, it thinks it's succeeding, and though the multicast addresses
don't appear in "netstat -ani", a "vmstat -m | grep ether_multi" shows
the in-use counter is incrementing each time, including when I add them
manually with mtest. I highly suspect that the dpni20 driver is getting
confused somewhere, since with the bridged-tap setup it maintains an
internal "10-side" IP and MAC address which is not visible to the OS's
interface table, and only manifests in the ARP table. Presently,
klh10's "enaddr" command-line utility stopped giving errors on adding
the requisite multicast addresses, but ether_multi is *not* incremented,
and the warning enaddr: No EN addr in iftab for "tap0" is given, telling
me that nothing is really happening. This is telling, since enaddr
exercises the same functions in osdnet.c that the emulator itself uses.
As a test I think I may try setting the dedicated interface to a real
ethernet instead of the virtual tap, to see if I can resolve the
multicast issues. At the moment this seems to be the show stopper.
Mark
Mark Abene wrote:
I wanted to be doing a netstat -ani, (-g only shows multicast for
ipv4/6), but the result is the same. None of the DECnet multicast
addresses are being added, most notably (and absolutely necessary) are:
ab:0:0:3:0:0 - type 6003 - for DECnet Phase IV end node Hello packets
from each host, and
ab:0:0:4:0:0 - type 6003 - for DECnet Phase IV router Hello packets from
the router.
I've tried adding these with both enaddr from KLH10 and FreeBSD's
built-in "mtest", but both return errors. This seems to be a
FreeBSD-specific problem which so far I'm unable to find the reason for.
Mark
Mark Abene wrote:
Mark Abene wrote:
I've actually made a new discovery... looking at "netstat -g", I'm
seeing that none of the multicast addresses exist that DECnet uses and
requires! This would explain why I don't see any DECnet traffic at all.
I compiled KLH10's enaddr utility in an attempt to add the multicast
addresses manually, and I get failures for all attempts...
"SIOCADDMULTI failed - Can't assign requested address". My server's
kernel wasn't built with multicast routing enabled, which is not a
default. I'm wondering if this is the cause of the error. I'm going to
do some further testing.
Regards
Mark
Well I was mistaken about the multicast routing, that's only for doing
DVMRP with mrouted (MBONE, etc). Local LAN multicast should work "out
of the box" on FreeBSD. Still trying to track down why this is failing,
since it's my primary candidate for DECnet not working...
I'll be out today, but I'll change it for you when I get back tonight.
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Sampsa Laine
Sent: Saturday, September 13, 2008 3:43 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] GORVAX MULTINET tunnel and CHIMPY's bridge are moving
IPs soon
Argh,
My DNS wasn't set up correctly so the IP addresses in my previous
message were all wrong:
- CHIMPY's bridge remains on 78.86.123.26 port 4711/UDP
- GORVAX's MULTINET tunnel has been moved to 78.86.123.31, port
700/UDP
Sampsa
PS: The original address for GORVAX's MULTINET tunnel will work as
well until I confirm everyone can connect to the new address.
On 13 Sep 2008, at 11:36, Sampsa Laine wrote:
Well it would impolite to just turn off the old tunnel wouldn't it,
so I've left both port redirections on for now :)
Can you try try to speak to GORVAX's new address in which case I can
turn off the port forward on the old one.
Sampsa
On 13 Sep 2008, at 04:17, Bob Armstrong wrote:
- GORVAX's tunnel will be on port 700/UDP on address 78.86.120.236
(gvax.sampsa.com).
Are you sure? LEGATO appears to be talking to GORVAX now, on
78.86.123.26.
Bob
Argh,
My DNS wasn't set up correctly so the IP addresses in my previous message were all wrong:
- CHIMPY's bridge remains on 78.86.123.26 port 4711/UDP
- GORVAX's MULTINET tunnel has been moved to 78.86.123.31, port 700/UDP
Sampsa
PS: The original address for GORVAX's MULTINET tunnel will work as well until I confirm everyone can connect to the new address.
On 13 Sep 2008, at 11:36, Sampsa Laine wrote:
Well it would impolite to just turn off the old tunnel wouldn't it, so I've left both port redirections on for now :)
Can you try try to speak to GORVAX's new address in which case I can turn off the port forward on the old one.
Sampsa
On 13 Sep 2008, at 04:17, Bob Armstrong wrote:
- GORVAX's tunnel will be on port 700/UDP on address 78.86.120.236
(gvax.sampsa.com).
Are you sure? LEGATO appears to be talking to GORVAX now, on
78.86.123.26.
Bob
Well it would impolite to just turn off the old tunnel wouldn't it, so I've left both port redirections on for now :)
Can you try try to speak to GORVAX's new address in which case I can turn off the port forward on the old one.
Sampsa
On 13 Sep 2008, at 04:17, Bob Armstrong wrote:
- GORVAX's tunnel will be on port 700/UDP on address 78.86.120.236
(gvax.sampsa.com).
Are you sure? LEGATO appears to be talking to GORVAX now, on
78.86.123.26.
Bob
- GORVAX's tunnel will be on port 700/UDP on address 78.86.120.236
(gvax.sampsa.com).
Are you sure? LEGATO appears to be talking to GORVAX now, on
78.86.123.26.
Bob
Gentlemen,
I've finally figured out how to make more use of my range of static IPs so GORVAX and CHIMPY will be changing IP addresses:
- CHIMPY's bridge will be on port 4711/UDP on address 78.86.123.29 (chimpy.sampsa.com)
- GORVAX's tunnel will be on port 700/UDP on address 78.86.120.236 (gvax.sampsa.com).
Sorry about any inconvenience.
Sampsa
I wanted to be doing a netstat -ani, (-g only shows multicast for
ipv4/6), but the result is the same. None of the DECnet multicast
addresses are being added, most notably (and absolutely necessary) are:
ab:0:0:3:0:0 - type 6003 - for DECnet Phase IV end node Hello packets
from each host, and
ab:0:0:4:0:0 - type 6003 - for DECnet Phase IV router Hello packets from
the router.
I've tried adding these with both enaddr from KLH10 and FreeBSD's
built-in "mtest", but both return errors. This seems to be a
FreeBSD-specific problem which so far I'm unable to find the reason for.
Mark
Mark Abene wrote:
Mark Abene wrote:
I've actually made a new discovery... looking at "netstat -g", I'm
seeing that none of the multicast addresses exist that DECnet uses and
requires! This would explain why I don't see any DECnet traffic at all.
I compiled KLH10's enaddr utility in an attempt to add the multicast
addresses manually, and I get failures for all attempts...
"SIOCADDMULTI failed - Can't assign requested address". My server's
kernel wasn't built with multicast routing enabled, which is not a
default. I'm wondering if this is the cause of the error. I'm going to
do some further testing.
Regards
Mark
Well I was mistaken about the multicast routing, that's only for doing
DVMRP with mrouted (MBONE, etc). Local LAN multicast should work "out
of the box" on FreeBSD. Still trying to track down why this is failing,
since it's my primary candidate for DECnet not working...
