[HECnet] NAT, AT&T U-Verse, and HECnet?

[Julian Wolfe]

We actually got a VPN going, and this solved the problem.   My machine is part of Area 18 now and is called FLIND (18.777).

You can remove BIGBOA (1.42) for the time being.

On Feb 22, 2013, at 2:55 PM, Johnny Billquist <bqt at softjar.se> wrote:

On 2013-02-22 19:37, Julian Wolfe wrote:
HI all,

Registered on HECnet many years ago, but was never able to get on for long or at all in the past.   Now it seems this problem plagues me yet again in a different form.

I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router.   Something is going on with the packet source ports - they are being marked with a randomized source port.

My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?

If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?

Is this something I can fix myself, or do I need to look for another solution?

The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8.   This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode).       I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port.   I tried switching it back to the Mac, and now this problem has cropped up there too.

Phew!   Help!   I just want to hang out with yous guys :)

I've hit the problem with mangled ports in the past. Yes, it certainly do matter for the bridge (or anything else using UDP). Not only a security issue, but you peer needs to know where to send his packets as well.

I have a hack to the bridge, which sortof adapts to this. Ping me sunday, when I have some more time...

	Johnny