For all those who have tunnels to my Cisco 1841, I have switched ISPs and
as such my static IP address has changed. In my configuration I have the
following endpoints configured:
David Moylan (Area 35)
Tomas Prybil (Area 34)
Supratim Sanyal (Area 31)
Brian Hechinger (Area 52)
Ian McLaughlin (Area 42)
Cory Smelosky (Area 9)
Dave McGuire (Area 61)
Peter Lothberg (Area 59)
Mark Darvill (Area 22)
Mark G Thomas (Area 23)
If you are on that list could you please update your tunnel to use my new
address, which is 163.47.57.118.
Mark Berryman, my IPv6 address is unchanged, for the moment.
Regards, Tim.
Recently I have found, and fixed, a number of bugs in the DECnet for Linux kernel module. Some of
these bugs may be relevant for members of this mailing list who are using DECnet for Linux,
especially on a Raspberry Pi.
Major bugs fixed:
- Ethernet Listen Timer was not implemented
In addition, the check for an address change for the designated router (DR) was missing
although there was a check if the DR?s priority had changed.
Note: this code changes the format of /proc/net/decnet_dev to include the listen timer value.
nml/nml2 needs to be rebuilt to understand the changed format.
- System panic when using the loopback device (lo)
The DECnet code was missing a destructor routine which is used to avoid data copying.
- The neighbour (adjacent node) code could be broken by kernel changes
The code made use of a now deprecated feature (zero length array at the end of a structure)
in order to access data in a surrounding structure. This happened to work ?by chance?
until kernel 5.4.42 on 32-bit processors.
- Interrupt message flow control was broken
The flow control was a mixture of using the SEND/DONTSEND status of the data
subchannel and a message count. This seems to work between Linux systems but is broken
when communicating with other systems - during the life of a logical link, the remote system
could only send a single interrupt message while the Linux system could pretty much send
as many interrupts as it wanted possibly overrunning the remote systems buffers.
- Optional data on received connect confirm message was corrupted
The code was getting the optional data from the wrong offset in the message.
- Next hop cache problem
30 seconds after a logical link was taken down, the next hop cache entry was deleted. As
part of this deletion, the link was taken ?down? which caused a neighbour entry to be
created for the same node address but accessed via the loopback device. Sometimes this
would cause the designated router to become accessible via the loopback device and
subsequent connections would fail.
- Intra-ethernet bit ignored
The intra-ethernet bit in the routing flags is ignored on inbound traffic. If there was a neighbour
entry for the remote node at connection time, everything would work correctly. If there wad no
entry, all outbound traffic would be sent through the designated router for the duration of
the logical link.
- Promiscuous mode alters DECnet behaviour
If the ethernet NIC used for DECnet had promiscuous mode enabled (e.g. using tcpdump
for traffic tracing), the DECnet code would start seeing endnode hello?s, populating
neighbour structures and causing the problems described above for the intra-ethernet bit
to go away.
New programs:
DECnet Test Send and DECnet Test Receiver (DTS/DTR)
Test programs created via reverse engineering the protocol exchanges. Used to find a
number of the bugs described above.
NML2
New implementation of the Network Management Listener. Supports SUMMARY, STATUS
and CHARACTERISTICS for NODES, CIRCUITS and AREAS. It does not support LINKS
and OBJECTS which were in the old version but are system specific operations which
were only visible from DECnet-VMS systems.
The old version is still the default during installation. The new version can be installed by:
cd dnprogs/nml2
make
sudo make install
which will overwrite the installed executable and man page.
OS Support:
As of 06/29/2020 the code has been tested with:
Raspbian 2020-05-27 release with kernels 4.19.126 and 5.4.44 (32-bit only)
Pi OS 2020-05-27 32-bit release with kernel 4.19.126 and 5.4.44
pI OS 2020-05-27 (fully updated on 06/26/2020) with kernel 5.4.49
The source code and installation instructions are available at:
<https://github.com/JohnForecast/RaspbianDECnet <https://github.com/JohnForecast/RaspbianDECnet>>
John.
I just made some small changes to the DECnet/E event logger application to fix a Y2K problem. (More precisely, a Y2K.003 problem).
https://github.com/pkoning2/decstuff
This is for RSTS V10.1. Just drop the new evtlog.tsk into [0,16].
paul
Hello All,
I've just cycled one of my old systems which in addition to regular duties also ran my VMS on SIMH system which participated with some of my real VAXen and Alpha systems. I've built v3.11 of simh and I'm having difficulty with the newer Pcap device and wondered if someone else knows the silly obvious thing I'm doing wrong.
Setup:
Ubuntu Server 18.xx LTS. 2x NIC's on the system. One's "eth0" (primary) and a secondary USB one which is obviously called "enx00e04c360059".
Ideally, I'd like to use one NIC for a promiscuous mode Ethernet, the other for regular scheduled programming. I've built SIMH in the usual fashion and dumped the binary's symbol tab via nm and the usual suspects from libpcap seem to be statically linked and present.
I can:
# id
uid=0(root) gid=0(root) groups=0(root)
# /tmp/simh/BIN/vax
VAX simulator V3.11-0
sim> attach xq eth0
Eth: Pcap capable device not found. You may need to run as root
File open error
sim> attach xq enx00e04c360059
File open error
sim> show xq eth
ETH devices:
eth0 udp:sourceport:remotehost:remoteport (Integrated UDP bridge support)
sim>
This seemed to work quite happily in the old O/S combo and with an older simh + pcap.
Can someone please point me in the correct direction?
Thanks in advance.
Regards,
Al Boyanich
Disclaimer
The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. Ifyou are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Limited on 02 9776 4555 or by reply e-mail to the sender and delete the document and all copies thereof.
Whereas Fujitsu Australia Limited would not knowingly transmit a virus within an email communication, it is the receiver's responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Limited does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.
If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Limited, please email unsubscribe at au.fujitsu.com.
Hi, all.
I have an issue with some mail servers/providers that some people use.
I'm open to some suggestions, but also want to point out something to
people who are subscribed.
Sometimes I start getting mails bouncing for some subscribers. I do try
to check why, and occasionally there have been something I could do
about it, but many times it's simply what I would call a broken mail
server for which there isn't much I can do. So occasionally I
unsubscribe people for which I'm just getting bounces all the time.
One such example is one server who claims that 130.238.19.25 don't have
reverse DNS. Which is clearly incorrect. It have had proper DNS setup
for at least 20 years. I have no idea how that mail server is set up,
but I can't do much about it.
Other times mails gets denied because of some blocking service who
thinks the hecnet mails are just spam, or the host (Update) is
untrustworthy, or have a bad reputation or what not. Usually not much I
can do about those either. If people (or companies) decide to make use
of such services, and such services give that kind of information, it
essentially just means that you'll not be getting the hecnet mails any more.
There is only so much I'm willing to do to try and sort such things out.
I do consider such services and solutions to be fundamentally broken to
start with, but I will of course not say that people can't use them if
they want to. But chances are that you'll get dropped from the HECnet
mailing list sooner or later, unless you are using some
service/technology that actually do work (not sure if any such exists).
An example I got today (actual mailbox names redacted):
> <XXXXXX at xs4all.nl> (expanded from <hecnet-list>): host
> mx4.xs4all.nl[194.109.24.139] said: 550 5.7.1 Spam message rejected by
> 06ULCRRd021949 on mxdrop301.xs4all.net, reason=CH (in reply to end of DATA
> command)
reason=CH ?
What does that mean. The mail is rejected because it came from
Switzerland? (Yes, I do live in Switzerland, and yes, it was a mail I
sent to the list, but really? Is all mail from Switzerland suspect now?)
> <XXXXXX at me.com> (expanded from <hecnet-list>): host
> mx01.mail.icloud.com[17.57.152.9] said: 554 5.7.1 [CS01] Message rejected
> due to local policy. Please visit https://support.apple.com/en-us/HT204137
> (in reply to end of DATA command)
>
> <XXXXXX at me.com> (expanded from <hecnet-list>): host
> mx01.mail.icloud.com[17.57.152.9] said: 554 5.7.1 [CS01] Message rejected
> due to local policy. Please visit https://support.apple.com/en-us/HT204137
> (in reply to end of DATA command)
Rejected due to local policy?
Following the link don't really give an answer, but just various
recommendation.
Most of those recommendations are already done (and have been the whole
time) by the HECnet list. SPF and DKIM we don't use. I had that setup
for a while on a mail server of my own, and came to realize that it hurt
more than it helped, so I removed it again. I doubt this will be setup
on Update any time soon, but either way, it's not there now, and it's
not even clear if that is the reason for the rejects, or some other
thing. There is also no way to even get in touch with Apple in this
case, to fix this. So there is a fair chance I'll have to unsubscribe a
few more addresses in the near future...
I am not really interested in moving the mailing list to some other
host. Any suggestions from anyone on this topic?
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
Verizon is tightening the screw. I think I will give up now. It was explained to me over a telephone call to their security department that I cannot have any of the following ports open at home.
80
81
554
8xxx
9xxx
> From: Verizon Notification <verizon-notification at verizon.com>
> Date: July 30, 2020 at 12:32:48 PM EDT
> To: thesanyalfamily at gmail.com
> Subject: Security notice
> Reply-To: Verizon Notification <verizon-notification at verizon.com>
>
>
>
> Hi,
>
> Attention Verizon Customer,
>
>
> Our network monitoring tools have detected significant amounts of harmful network traffic coming from your home or office network. It is likely that a device within your home or office is infected with malware; we believe the device could be a network security camera, network video recorder, or similar device.
>
>
> These devices are being targeted by hackers. The hackers are leveraging potential security flaws in the hardware / software to stage large scale attacks against other networks and devices.
>
>
> Pursuant to Verizon's Terms of Service and Acceptable Use Policy, we are asking you to disconnect any such devices from your home or office network. This is an effort to protect your privacy and network. We ask that you contact the manufacturer's support department to determine how to properly secure the device, including closing any network ports on the device(s) exposed to the public Internet. Once fully patched with the most up to date firmware and software, please ensure that you protect access to the device by changing the admin login credentials. Use a strong password for all access points including remote viewing of the cameras. Once that is complete you may return the device to your network.
>
>
> Should these efforts fail and the device is once again found to be leveraged as an attack host, we will ask for the removal of the device until the vendor can devise an acceptable remediation.
>
>
> You must take the necessary steps to remove this device from your network as soon as possible. Failure to remove this device is a violation of the Verizon Online Acceptable Use Policy and may result in the following:
>
>
> - Future suspension and/or termination of your Internet Services.
>
>
> Additional suggestions and precautions can viewed at verizon.com/securityinfo or visit the website of your hardware vendor.
>
>
> You may contact Verizon support at 888-553-1555
>
> Verizon will never ask you to provide or verify personal or account information by email.
>
> Thanks for your prompt attention.
>
> Verizon Internet Abuse Investigations Team
> 22001 Loudoun County Parkway
> Ashburn, VA 20147
>
>
>
> ? 2020 Verizon. All Rights Reserved.
>
> Ensure Verizon emails reach your inbox by adding verizon-notification at verizon.com to your "safe" email list. Your email provider
> can provide instructions on how it works.
>
> This email has been sent from an auto-notification system that cannot accept incoming email.
>
> This email was sent to thesanyalfamily at gmail.com. We respect your privacy. Please review our Privacy Policy If you think this email was sent in error or you'd like to change how you receive your notification, click here
>
We`ll get your website to have Domain Authority 50 or we`ll refund you every
cent
for only 69 usd, you`ll have DA50 for your website, guaranteed
Order it today:
http://www.str8-creative.co/product/moz-da-seo-plan/
thanks
Peter
Increase sales and ranks with our targeted traffic
http://bulkwebtraffic.io
Check the pricelist attached
Regards
Michale Millwood ?
Unsubscribe option is available on the footer of our website