> Google says it's my fault; I say Google has its collective head up
> its ass in marking a valid email as spam. Their official word is
> "Don't act like the bad guys" and you won't have problems. Never
> mind that it's 100% RFC-compliant, they say it's bad guy behaviour.
I agree. Sending mail to google (and also hotmail/outlook) has become
very unreliable. E.g. when using @amsat.org or other forwarding services
like @veron.nl or @vrza.nl (Dutch amateur radio societies) it will usually not work.
I do not really want to use my ISP mail address, so it looks like I have
to register my own domain to get this fixed. For now, I have set an autoreply
(from the ISP mail address) encouraging people to use a different address
and look in their spambox when they expect a reply.
I hear that it is customary in the circles of gmail/hotmail/outlook users
to send a Whatsapp message "I have sent you an e-mail"...
Rob
> Everyone happy with this? Any comments?
It would be nice if the mail had some info about what a gateway is and why you (don't) want it,
e.g. with a pointer to the wiki page.
I have found that some people add a gateway entry because they think this is some form of registration
of their existing (not IPIP mesh) router e.g. connected via radio or via one of the other VPN types
we support. They think it would be useful to be registered in some list. That is how the problematic
gateway came into existance, and there are several others like that registered in the Netherlands,
that did not become problematic only because they had no subnets.
When being listed is what they actually want, of course they should not register a gateway. But it is what
they do, partly because there is a lack of higher-level explanation of concepts. And after receiving
that mail message they probably still don't understand what they are doing wrong.
Maybe a pointer to HamnetDB could be useful. Registering there is probably what they want.
Rob
Hello,
To all amprd users (this does not affect setups using the kernel tunnel
driver and ampr-ripd).
Due to changes in the 4.x kernels, there's a problem with the system
replying with "icmp unreachable" to incoming IPIP traffic.
This will possible drop incoming traffic, including the RIP broadcasts
(resulting in incomplete route tables).
Please switch to an ampr-ripd setup or filter outgoing icmp messages on
your WAN interface, using a rule like the one below:
*iptables -A OUTPUT -o ethX -p icmp --icmp-type destination-unreachable
-m state --state RELATED -j DROP*
I hope I can find a workaround on this issue.
Marius, YO2LOJ
> I don't think folks would add a gateway if they haven't been approved for a block.
Well, actually they do.
The problem is that the visitors of the portal do not know at all what the whole concept
of the IPIP tunnel mesh looks like, how it is relevant within AMPRnet, and that it is
only one of the options for getting connected.
As there is no walk-through explanation of concepts like a registered subnet, a gateway,
the resulting IPIP tunnel mesh, etc, people just blindly click on menu items and fill
out forms.
Then they have a gateway but the still don't understand how that all works.
So they close the site and continue to look elsewhere for information, and when they find
it they never come back to delete what they created.
That is why it is good to remove that crud, but also it would be good to have some more
explanatory text and/or pointers to where that can be found. And some warnings that
this is not a system to voluntarily register some information about one's station, but
that it is actually used for something and that you can actually break things by entering
information.
(of course we should strive for a situation where one cannot break the network for other
users, but still one could break the routing of one's own subnet)
Rob
> I would replace DROP by REJECT. DROP means the system will wait till the packet times out.
> For outgoing connections this may cause issues as the daemon that sends the unreachable will also wait till the packet times out before continuing
No, outgoing ICMP "destination unreachable" is not an outgoing connect and it makes no sense to REJECT them...
(this kind of packet should not be replied to)
Rob
>
> Given this, perhaps you could add a note suggesting that one or the list
> of blocks should be added when they reregister their gateway, that would
> eliminate any confusion... just my two cents.
This better:
—8< SNIP >8---
Hello {givenName},
This is a system generated email from the AMPRNet Portal.
This is a courtesy notice to advise you that your gateway entry has been removed.
Your gateway was removed by an automated process that looks for gateways that have had no attached subnets for at least one week.
Your gateway has met this criteria and has thus been removed.
It is important that the Portal data is kept up to date and accurate.
If you still want to run a gateway, please feel free to add your gateway back to the Portal.
Your gateway's details were:
Title: {gwTitle}
IP: {gwIP}
Host: {gwHost}
Notes: {gwNotes}
You have the following subnets allocated to you:
{listOfSubnets}
If you add your gateway back, please ensure that you allocate at least one subnet to it, otherwise this process will remove your gateway again in a week!
Kind Regards,
The AMPRNet Team
—8< SNIP >8—
What is the final outcome of the discussion?
Will any changes be made to the Portal to validate user input for default users?
Will there be a change in functionality w.r.t. having gateways with external address within AMPRnet?
Will incomplete gateway entries be deleted?
I hope we can have some outcome of the bad situation and following discussion, instead of leaving
everything as it is.
Rob
Although I wanted to provide a freely accessible demo for ALL ham
operators as an configuration example on an EdgeRouter, I'm starting to
have my doubts.
Especially to w6ray...
What is the use of hanging on a router web interface for 24h now? What
new information could it give you by watching its interface?
Marius, YO2LOJ
