from:"rainer"

[swinog] Re: Research project on Sustainable Networking

2024-06-21 Diskussionsfäden Rainer Duffner via swinog


Am 2024-06-21 16:48, schrieb Romain Jacob via swinog:

Dear Urs,

Let me keep the list on to reply to some questions, as you are not the
first to ask:

* Most routers we are interested in have multiple power supply. Our
strategy is to use one measurement unit per PSU. That demands extra
hardware, but we wouldn't want to have two PSU connected to the same
power meter anyway as this would create a potential single point of
failure.
* Network connectivity for the Pi is required but DOES WORK BEHIND A
FIREWALL. The only requirement is that the Pi must be able to connect
to the Internet.

Thanks again to those who already reached out!




"the Internet" - you mean Port 443, any IP?


___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Any users of SCION here?

2024-03-28 Diskussionsfäden Rainer Duffner via swinog

Hi,

and specifically the hardware the company behind it (anapaya) sells.





Best Regards
Rainer
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: strange failure from online.de MX

2023-03-23 Diskussionsfäden Rainer Duffner via swinog


Am 2023-03-23 09:41, schrieb Michael Righter via swinog:

Hi

A mail to @online.de is blocked on their site with this error. Never
seen such an error.
Anyone seen this before or knows a contact to them?

2023-03-21T09:00:04Z;EMIG;mx01.emig.kundenserver.de[217.72.192.66];400
EmiG fingerprint mismatch
2023-03-21T09:30:04Z;EMIG;mx00.emig.kundenserver.de[212.227.15.40];400
EmiG fingerprint mismatch
2023-03-21T10:00:04Z;EMIG;mx00.emig.kundenserver.de[212.227.15.40];400
EmiG fingerprint mismatch
2023-03-21T10:30:04Z;EMIG;mx01.emig.kundenserver.de[217.72.192.66];400
EmiG fingerprint mismatch
2023-03-21T11:00:03Z;EMIG;mx00.emig.kundenserver.de[212.227.15.40];400
EmiG fingerprint mismatch
2023-03-21T11:30:02Z;EMIG;mx01.emig.kundenserver.de[217.72.192.66];400
EmiG fingerprint mismatch

Thanks Michael
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch



Seems to be this:

https://www.e-mail-made-in-germany.de/index.html

Is it a forwarded mail?

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: DNSSEC issue with swizzonic DNS servers?

2022-12-30 Diskussionsfäden Rainer Duffner via swinog


Am 2022-12-30 11:21, schrieb Benoît Panizzon via swinog:

Hi Markus


the name server from swizzonic is not supposed to provide you with a
answer to all the queries.


I guess if I point to our recursive validating caching NS and it does
not possess this data in it's cache, it will start by following from
the root by asking for _.numberportability.ch to avoid revealing which
host it is exactly looking for until it reaches the authoritative DNS
for that zone and then ask this one directly for the desired RR.

I guess this is where something is breaking the chain.

I also don't see why the swizzonic DNS which is the authoritative
primary should not answer to all queries.



If I want to or need to ask the (supposedly) authoritative server(s) 
about a domain, I add +norecurs.


I believe, if you disable recursive queries on the authoritative-server, 
it will not answer them, even if it technically could.


Does DNSSEC change that?

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Contact: geoiplookup.net

2022-10-13 Diskussionsfäden rainer

Am 2022-10-13 08:46, schrieb Benoit Panizzon:

Short update on that issue...

Does anyone know who operates geoiplookup.net and how to contact them?

It looks like they source their Data from MaxMind but are solver
implementing corrections and therefore lacking behind corrections
published there.

The issue we have is not with content, but with services.

There is one SIP telephone service provider which fences his customers
to Swiss IP addresses only and provides services to businesses.

So if the static routed IP addresses of the business customer is locate
outside Switzerland, this is an effective denial of service to the
telephony of that customer.

This happens for the 3rd time within only a couple of weeks to the
same customer of us now.

The TSP in question blames us for assigning foreign ip addresses to the
customer in question and recommends the customer should get a new
Swiss ip range from us. This of course is not feasible, as this would
require lots of changes on the customer side.

Customer in question has an own transparent RIPE entry with country: ch
since 2016!
The range in question was never (since 2003, ripe does not provide
prior data) assigned to an ISP or customer outside Switzerland.

What I am trying to do now, is set up an ISP bulk location feed to
MaxMind and trying to persuade them to put a lock on our ip ranges
so only we can provide locations for those and noone else. (Has anyone
done this successfully?)

I am also pressing them to disclose how the same ip ranges now
repeatedly got put back to Germany shortly after we successfully
submitted corrections.

But all I get now is:

* Please use the online correction form.

* Thank you for submitting the correction, which we will push in our
next update.

We also had a case like this, except it was gambling (and Zattoo, IIRC).

A single IP in our AS was assigned to Germany, for whatever reason.

I think we contacted the gambling-company's geo-fence provider (it was
some other outfit than Maxmind, specializing in gambling and stuff like
that) via Twitter who seemed to have a better connection to Maxmind (the
original source of the data) and it got fixed, eventually.

59 matches

Mail list logo