I wound up using Dynamic DNS, but I'm not sure that a host name could be parsed there.  Otherwise, you need a static IP. Your second example is interesting.  I don't suppose it would accept something clever like: circuit mul-123 Multinet 207.123.123.*0*:15001:listen --cost 8 --t3 120 Or circuit mul-123 Multinet 207.123.123.*0/24*:15001:listen --cost 8 --t3 120 On 4/26/22 12:04 PM, Iain Hardcastle wrote: _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

PyDECnet rechecks the name resolution every hour. It doesn't close existing connections, but if a node moves and its DNS entry is updated to reflect that, PyDECnet will find it again and reconnect within an hour.

No, but we're not talking about socket address binding -- the address used in that syntax is the other side address. You're correct that it doesn't do subnet (prefix length) syntax.

The answer is in the documentation. When you install a new version, remember to check CHANGES.txt which lists significant changes -- in particular, those that affect what you put into config files. Quoting from there: 1.0-575: Correct documentation omission: in rev 570, the circuit configuration spec was changed so "0.0.0.0" is no longer recognized as "any address allowed". Instead, use an empty address or the special value "*".

And the detailed documentation for config files is in doc/config.txt which has this to say: --remote-address: Remote IP address. If omitted or specified as "*", for inbound TCP modes, any destination address is accepted. For UDP and GRE, this is not yet allowed, a specific address must be specified.

Johnny, Funny you should say that. As soon as you responded below, I had a look at bridge.c. Basically it looks like I'd just need to do a cfork(). That child process would wake up ever so often and do a gethostbyname() on each name field in the BRIDGE structure and compare that IP address with what was in the corresponding addr field.  Any difference would mean it would send the parent a SIGHUP to reparse the bridge.conf file, which would rebuild the BRIDGE structure with the correct IP addresses. If we wanted to keep the accumulated totals (rcount, zcount, Etc.) correct for SIGUSR1, then maybe those could be saved before the SIGHUP and added back after this was complete. That doesn't sound too awful, unless I'm missing something (haven't really gotten into that code for a year or two).

--T _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

------------------------------------------------------------------------ On 4/26/22 8:05 PM, Thomas DeBellis wrote: I'll have a look some more, then; I haven't crashed any of my Unix boxes in a while. I finally found the pernicious bug I that introduced into TTYSRV when I was updating it to make my life in the Access Control Job easier.  In short, you will sometimes get what deserve if you dereference an index register that you naively thought somebody else set up for you.  If you happen to do this in Exec mode, then you will be ever-so-more richly rewarded. What a rabbit hole...  Still, now PANDA can remark on who is looking over who's shoulder. Nice to finally come up for air, anyway. > ------------------------------------------------------------------------ > > On 4/26/22 6:47 PM, Johnny Billquist wrote: > > Hi. > > No. You are right. That could definitely be done. I've just been to > lazy to ever start polishing things... > >   Johnny >> ------------------------------------------------------------------------ >> >> On 2022-04-26 23:03, Thomas DeBellis wrote: >> >> Johnny, >> >> Funny you should say that. >> >> As soon as you responded below, I had a look at bridge.c.   >> Basically it looks like I'd just need to do a fork().  That child >> process would wake up ever so often and do a gethostbyname() on each >> host field in the BRIDGE structure and compare that IP address with >> what was in the corresponding addr field.  Any difference would mean >> it would send the parent a SIGHUP to reparse the bridge.conf file, >> which would rebuild the BRIDGE structure with the correct IP addresses. >> >> If we wanted to keep the accumulated totals (rcount, zcount, Etc.) >> correct for SIGUSR1, then maybe those could be saved before the >> SIGHUP and added back after this was complete. >> >> That doesn't sound too awful, unless I'm missing something (haven't >> really gotten into that code for a year or two). >> >> --T >> >>> ------------------------------------------------------------------------ >>> On 4/26/22 3:45 PM, Johnny Billquist wrote: >>> >>> Well. The thing is, this was/is a listening socket. So there is no >>> reconnecting. It's just about binding. >>>> ------------------------------------------------------------------------ >>>> On 2022-04-26 19:40, Paul Koning wrote: >>>> >>>> PyDECnet rechecks the name resolution every hour.  It doesn't >>>> close existing connections, but if a node moves and its DNS entry >>>> is updated to reflect that, PyDECnet will find it again and >>>> reconnect within an hour. >>>> >>>>> ------------------------------------------------------------------------ >>>>> On Apr 26, 2022, at 1:22 PM, Johnny Billquist <bqt(a)softjar.se> >>>>> wrote: >>>>> >>>>> The problem is that dynamic dns don't necessarily solve any >>>>> problems. The address is bound at start, and if the resolution in >>>>> DNS changes at some later point, that won't get reflected unless >>>>> pydecnet would redo the name lookup, close and reopen the >>>>> listening socket bound to the new address.

On Apr 26, 2022, at 6:03 PM, Iain Hardcastle <iain(a)qseco.fr> wrote: RTFM! There's a new one.... ok mea culpa :) I did miss the '--remote-address' line in config.txt and did not read the changes.txt thinking config.txt would be authoritative.