Re: Widespread Firefox issues

[Karl Auer]

On Fri, 2019-05-03 at 21:38 -0600, Brielle Bruns wrote:
> On 5/3/2019 8:58 PM, Adrian Minta wrote:
> > My temporary solution was to set "xpinstall.signatures.required"
> > to "false".
> Unfortunately only works if you are using the Dev version :(

Or, apparently, if you are using the Linux version. I'm on 66.0.3 Linux
64-bit. I think the Android version still allows it, too.

I dislike this trend to remove features "for our own good", yet
everyone seems to be doing it.

Regards, K.


-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
Old fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75

Re: Widespread Firefox issues

[Brielle Bruns]

On 5/3/2019 8:58 PM, Adrian Minta wrote:
My temporary solution was to set "xpinstall.signatures.required" to 
"false".


Unfortunately only works if you are using the Dev version :(

They totally removed ability to bypass that in the standard distribution 
of Firefox.  Ugh



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Widespread Firefox issues

[Brielle Bruns]

On 5/3/2019 8:48 PM, Keith Medcalf wrote:


Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing 
whatsoever happened to my Firefox browser, and all the extensions are still 
working just fine.


Clearly you are not reading the bug reports and paying attention.

Its not happening to everyone, but a large enough group of people are 
experiencing it.  My desktop for example, is having the issue, my laptop 
is not.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Widespread Firefox issues

[Brielle Bruns]

On 5/3/2019 9:10 PM, Karl Auer wrote:

The diagnosis in the OP's message may be false, but there is most
definitely a widespread FF issue (or was, maybe fixed now). It affected
me and numerous others.


I'm just repeating what was mentioned elsewhere - don't shoot the 
messenger.  We'll have to wait for them to tell us what exactly happened 
(if they do) to know for sure.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

RE: Widespread Firefox issues

[Keith Medcalf]

HTTPS: has nothing to do with the website being "secure".  https: means that 
transport layer security (encryption) is in effect.  https: is a PRIVACY 
measure, not a SECURITY measure.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Constantine
>A. Murenin
>Sent: Friday, 3 May, 2019 21:02
>To: Brielle Bruns
>Cc: NANOG list
>Subject: Re: Widespread Firefox issues
>
>On Fri, 3 May 2019 at 20:57, Brielle Bruns  wrote:
>
>
>   Just an FYI since this is bound to impact users:
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
>
>   Basically, Mozilla forgot to renew an intermediate cert, and
>people's
>   Firefox browsers have mass-disabled addons.
>
>   Whoops.
>
>
>
>This is why it's important that every single website on the internet
>is available ONLY over HTTPS.  Don't forget to install an HSTS
>policy, too, so, if anyone ever visits Kazakhstan or a security-
>conscious corporate office, they'll be prevented from accessing the
>cute pictures of cats on your fully static website.  Of course, don't
>forget to abandon HTTP, too, and simply issue 301 Moved Permanently
>redirects from all HTTP targets to HTTPS, to cover all the bases.
>
>Backwards compatibility?  Don't you worry — no browser lets anyone
>remove HSTS, once installed, so, you're golden.  And HTTPS links
>won't fallback to HTTP, either, so, you're good there, too — your
>cute cats are safe and secure, and once folks link to your new site
>under https://, your future self will be safe and secure from ever
>having the option to go insecure again.  I mean, why would anyone go
>"insecure"?  Especially now with LetsEncrypt?
>
>
>Oh, wait…
>
>
>Wait a moment, and who's the biggest player behind the HTTPS-only
>movement?  Oh, and Mozilla's one of the biggest backers of
>LetsEncrypt, too?  I see…  Well, nothing to see here, move along!
>#TooBigToFail.
>
>
>C.

Re: Widespread Firefox issues

[Karl Auer]

On Fri, 2019-05-03 at 20:48 -0600, Keith Medcalf wrote:
> Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing
> whatsoever happened to my Firefox browser, and all the extensions are
> still working just fine.

The diagnosis in the OP's message may be false, but there is most
definitely a widespread FF issue (or was, maybe fixed now). It affected
me and numerous others.

Simple temporary fix is to browse to "about:config" and change the
value for "xpinstall.signatures.required" to false. Well, that worked
for me, anyway. When Mozilla fixes whatever the issue is, I'll set it
back to true. 

BTW it hit at midnight UTC,so different people saw the effect at
different times depending on their timezone.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
Old fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75

Re: Widespread Firefox issues

[Constantine A. Murenin]

On Fri, 3 May 2019 at 20:57, Brielle Bruns  wrote:

> Just an FYI since this is bound to impact users:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
>
> Basically, Mozilla forgot to renew an intermediate cert, and people's
> Firefox browsers have mass-disabled addons.
>
> Whoops.
>

This is why it's important that every single website on the internet is
available ONLY over HTTPS.  Don't forget to install an HSTS policy, too,
so, if anyone ever visits Kazakhstan or a security-conscious corporate
office, they'll be prevented from accessing the cute pictures of cats on
your fully static website.  Of course, don't forget to abandon HTTP, too,
and simply issue 301 Moved Permanently redirects from all HTTP targets to
HTTPS, to cover all the bases.

Backwards compatibility?  Don't you worry — no browser lets anyone remove
HSTS, once installed, so, you're golden.  And HTTPS links won't fallback to
HTTP, either, so, you're good there, too — your cute cats are safe and
secure, and once folks link to your new site under https://, your future
self will be safe and secure from ever having the option to go insecure
again.  I mean, why would anyone go "insecure"?  Especially now with
LetsEncrypt?

Oh, wait…

Wait a moment, and who's the biggest player behind the HTTPS-only
movement?  Oh, and Mozilla's one of the biggest backers of LetsEncrypt,
too?  I see…  Well, nothing to see here, move along!  #TooBigToFail.

C.

RE: Widespread Firefox issues

[Keith Medcalf]

Besides which, if something was signed AT THE TIME when the certificate chain 
was valid, then that signature will be a valid signature forever (unless one of 
the certificates in the chain is revoked).  The future or current expiry of a 
certificate or an intermediary has no effect whatsoever on the validity of a 
signature IF THE CERTIFICATE CHAIN WAS VALID at the time the signature was 
made, and the chain can be verified TO HAVE BEEN VALID at the time the 
signature was made.

In other words, the fact that subsequent to making a signature the pen ran out 
of ink does not make the signature invalid.  If it did so then there would be 
no point in having signatures.  It may be impossible to make a valid signature 
with a pen that is out of ink, but that does not invalidate signatures made 
before the ink ran out.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG [mailto:nanog-bounces+kmedcalf=dessus@nanog.org] On
>Behalf Of Keith Medcalf
>Sent: Friday, 3 May, 2019 20:48
>To: NANOG list
>Subject: RE: Widespread Firefox issues
>
>
>Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing
>whatsoever happened to my Firefox browser, and all the extensions are
>still working just fine.
>
>---
>The fact that there's a Highway to Hell but only a Stairway to Heaven
>says a lot about anticipated traffic volume.
>
>
>>-Original Message-
>>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brielle
>>Bruns
>>Sent: Friday, 3 May, 2019 19:56
>>To: NANOG list
>>Subject: Widespread Firefox issues
>>
>>Just an FYI since this is bound to impact users:
>>
>>https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
>>
>>Basically, Mozilla forgot to renew an intermediate cert, and
>people's
>>Firefox browsers have mass-disabled addons.
>>
>>Whoops.
>>--
>>Brielle Bruns
>>The Summit Open Source Development Group
>>http://www.sosdg.org/ http://www.ahbl.org
>
>

Re: Widespread Firefox issues

[Adrian Minta]

My temporary solution was to set "xpinstall.signatures.required" to "false".


On 5/4/19 4:55 AM, Brielle Bruns wrote:

Just an FYI since this is bound to impact users:

https://bugzilla.mozilla.org/show_bug.cgi?id=1548973

Basically, Mozilla forgot to renew an intermediate cert, and people's 
Firefox browsers have mass-disabled addons.


Whoops.


--
Best regards,
Adrian Minta

RE: Widespread Firefox issues

[Keith Medcalf]

Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing 
whatsoever happened to my Firefox browser, and all the extensions are still 
working just fine.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brielle
>Bruns
>Sent: Friday, 3 May, 2019 19:56
>To: NANOG list
>Subject: Widespread Firefox issues
>
>Just an FYI since this is bound to impact users:
>
>https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
>
>Basically, Mozilla forgot to renew an intermediate cert, and people's
>Firefox browsers have mass-disabled addons.
>
>Whoops.
>--
>Brielle Bruns
>The Summit Open Source Development Group
>http://www.sosdg.org/ http://www.ahbl.org

Widespread Firefox issues

[Brielle Bruns]

Just an FYI since this is bound to impact users:

https://bugzilla.mozilla.org/show_bug.cgi?id=1548973

Basically, Mozilla forgot to renew an intermediate cert, and people's 
Firefox browsers have mass-disabled addons.


Whoops.
--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Looking for audiovisual resources on Clos topologies

[Ben Maddison via NANOG]

Get Outlook for Android


From: NANOG  on behalf of Valdis Klētnieks 

Sent: Friday, May 3, 2019 7:22:52 PM
To: Sadiq Saif
Cc: nanog@nanog.org
Subject: Re: Looking for audiovisual resources on Clos topologies

On Fri, 03 May 2019 13:08:55 -0400, Sadiq Saif said:
> I recently read a APNIC blog post about LINE's network redesign [0] into
> a Clos topology. That lead to me RFC7938 [1] which has a fairly minimal
> explanation of the topology design itself.

>From the APNIC blog:

"In the case of LINE's network, where all servers in the data centre are
identified by eBGP, more than 10,000 ASNs are required."

They've traded L2 VLAN complexity for L3 ASN complexity.  What's the old
saying in computer science?  "All problems can be solved by adding a level
of redirection"?

> https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/

Apparently, "simplicity" is the new euphemism for "let's push all the surprising
emergent effects of our design to someplace new..."

Re: NTP question

[william manning]

well, if they all go down, here is my backup clock.


On Fri, May 3, 2019 at 10:04 AM Seth Mattinen  wrote:

>
> On 5/1/19 8:35 PM, Mel Beckman wrote:
> > But wait. What is the GPS constellation goes down? THEN we have bigger
> problems
>
>
> For timing if we lose the WWV stations and CDMA, then it seems the
> diversity plan is going to be a combination of US GPS, Galileo, and
> GLONASS disciplined sources.
>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 04 May, 2019

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  749324
Prefixes after maximum aggregation (per Origin AS):  287369
Deaggregation factor:  2.61
Unique aggregates announced (without unneeded subnets):  360025
Total ASes present in the Internet Routing Table: 64054
Prefixes per ASN: 11.70
Origin-only ASes present in the Internet Routing Table:   55085
Origin ASes announcing only one prefix:   23745
Transit ASes present in the Internet Routing Table:8969
Transit-only ASes present in the Internet Routing Table:278
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  41
Max AS path prepend of ASN ( 22394)  38
Prefixes from unregistered ASNs in the Routing Table:25
Number of instances of unregistered ASNs:29
Number of 32-bit ASNs allocated by the RIRs:  26816
Number of 32-bit ASNs visible in the Routing Table:   21880
Prefixes from 32-bit ASNs in the Routing Table:   96358
Number of bogon 32-bit ASNs visible in the Routing Table:22
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:247
Number of addresses announced to Internet:   2849998464
Equivalent to 169 /8s, 223 /16s and 134 /24s
Percentage of available address space announced:   77.0
Percentage of allocated address space announced:   77.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.2
Total number of prefixes smaller than registry allocations:  251361

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   201228
Total APNIC prefixes after maximum aggregation:   58486
APNIC Deaggregation factor:3.44
Prefixes being announced from the APNIC address blocks:  197671
Unique aggregates announced from the APNIC address blocks:82489
APNIC Region origin ASes present in the Internet Routing Table:9671
APNIC Prefixes per ASN:   20.44
APNIC Region origin ASes announcing only one prefix:   2706
APNIC Region transit ASes present in the Internet Routing Table:   1448
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 29
Number of APNIC region 32-bit ASNs visible in the Routing Table:   4684
Number of APNIC addresses announced to Internet:  773599104
Equivalent to 46 /8s, 28 /16s and 47 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-139577
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:223479
Total ARIN prefixes after maximum aggregation:   104656
ARIN Deaggregation factor: 2.14
Prefixes being announced from the ARIN address blocks:   222695
Unique aggregates announced from the ARIN address blocks:105382
ARIN Region origin ASes present in the Internet Routing Table:18450
ARIN Prefixes per ASN:12.07
ARIN Regio

Re: Looking for audiovisual resources on Clos topologies

[Sadiq Saif]

On Fri, 3 May 2019, at 13:32, Hugo Slabbert wrote:
> 
> 
> Some notes from Facebook and Google network architecture 
> evolution/designs 
> Google: http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf
> Facebook: 
> https://code.fb.com/production-engineering/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/
> 
> Some other related presentations:
> 
> Doug Hanks on multi-stage Clos architectures:
> https://www.youtube.com/watch?v=HeTitZdcHB4
> 
> TeamNANOG: Building Scalable Data Centers: BGP is the Better IGP  
> https://www.youtube.com/watch?v=yJbqnOdD3cg
> 
> TeamNANOG: Building a smallish DC...for the rest of us  
> https://www.youtube.com/watch?v=4yL6_tKfIfk
> 
> UKNOFconf: UKNOF32 - Google datacentre networking  
> https://www.youtube.com/watch?v=Thc7Muu9SHc
> 
> 
> -- 
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal

Thank you very much Hugo, I'll give these a look.
-- 
Sadiq Saif
https://sadiqsaif.com

Re: any interesting/useful resources available to IPv6 only?

[James R Cutler]

> On May 3, 2019, at 11:47 AM, Doug Barton  wrote:
> 
> On 5/3/19 8:14 AM, Brian J. Murrell wrote:
>> Hi,
>> I am trying to make a case (to old fuddy-duddies, which is why I even
>> need to actually make a case) for IPv6 for my own selfish reasons.  :-)
>> I wonder if anyone has any references to interesting/useful/otherwise
>> resources on are only available to IPv6 users that they can forward to
>> me.
> 
> This type of marketing approach was pursued doggedly for many of the early 
> years of IPv6 rollout. It was as misguided then as it was ineffective.
> 
> If you have plenty of IPv4 space, you have no case for IPv6. (And I say that 
> as one of the most enthusiastic proponents of it.) OTOH, if you 
> are/might/will be approach(ing) any kind of IPv4 capacity limitation, then 
> you want to start deploying IPv6 ASAP.
> 
> The other case that makes business sense is a content provider with a lot of 
> traffic. You can get different, and often better, peering relationships over 
> IPv6; and there are a lot of eyeball networks, especially mobile providers, 
> who are using it natively nowadays.
> 
> hope this helps,
> 
> Doug

The most valuable/useful network resource available today using IPv6 is a 
mobile network customer. (Not necessarily IPV6 only, but IPv4 requires extra 
effort.)

- 
James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: Looking for audiovisual resources on Clos topologies

[Hugo Slabbert]

On Fri 2019-May-03 13:08:55 -0400, Sadiq Saif  wrote:


Hi all,

I recently read a APNIC blog post about LINE's network redesign [0] 
into a Clos topology. That lead to me RFC7938 [1] which has a fairly 
minimal explanation of the topology design itself.


I was wondering if there are any NANOG or other *NOG talks explaining 
the Clos topology in a more audiovisual format. I figured I ask here 
before I go looking on a search engine.


Thanks in advance.


Some notes from Facebook and Google network architecture evolution/designs 
Google: http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf
Facebook: 
https://code.fb.com/production-engineering/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/


Some other related presentations:

Doug Hanks on multi-stage Clos architectures:
https://www.youtube.com/watch?v=HeTitZdcHB4

TeamNANOG: Building Scalable Data Centers: BGP is the Better IGP  
https://www.youtube.com/watch?v=yJbqnOdD3cg


TeamNANOG: Building a smallish DC...for the rest of us  
https://www.youtube.com/watch?v=4yL6_tKfIfk


UKNOFconf: UKNOF32 - Google datacentre networking  
https://www.youtube.com/watch?v=Thc7Muu9SHc




[0] - 
https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/

[1] - https://tools.ietf.org/html/rfc7938
--
Sadiq Saif
https://sadiqsaif.com


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Looking for audiovisual resources on Clos topologies

[Valdis Klētnieks]

On Fri, 03 May 2019 13:08:55 -0400, Sadiq Saif said:
> I recently read a APNIC blog post about LINE's network redesign [0] into 
> a Clos topology. That lead to me RFC7938 [1] which has a fairly minimal 
> explanation of the topology design itself.

>From the APNIC blog:

"In the case of LINE's network, where all servers in the data centre are
identified by eBGP, more than 10,000 ASNs are required."

They've traded L2 VLAN complexity for L3 ASN complexity.  What's the old
saying in computer science?  "All problems can be solved by adding a level
of redirection"?

> https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/

Apparently, "simplicity" is the new euphemism for "let's push all the surprising
emergent effects of our design to someplace new..."



pgpcDwghKdYYl.pgp
Description: PGP signature

Looking for audiovisual resources on Clos topologies

[Sadiq Saif]

Hi all,

I recently read a APNIC blog post about LINE's network redesign [0] into 
a Clos topology. That lead to me RFC7938 [1] which has a fairly minimal 
explanation of the topology design itself.


I was wondering if there are any NANOG or other *NOG talks explaining 
the Clos topology in a more audiovisual format. I figured I ask here 
before I go looking on a search engine.


Thanks in advance.

[0] - 
https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/


[1] - https://tools.ietf.org/html/rfc7938
--
Sadiq Saif
https://sadiqsaif.com

Re: NTP question

[Seth Mattinen]

On 5/1/19 8:35 PM, Mel Beckman wrote:

But wait. What is the GPS constellation goes down? THEN we have bigger problems



For timing if we lose the WWV stations and CDMA, then it seems the 
diversity plan is going to be a combination of US GPS, Galileo, and 
GLONASS disciplined sources.

Re: is dnswl dead?

[Valdis Klētnieks]

On Fri, 03 May 2019 00:55:17 -0500, Jose Manuel Vazquez Castro said:

> And check first connectivity ping and telnet tcp ports 22 , 873 to ips
> destination's from your linuxbox:
>
> Record A rsync2.dnswl.org
> 139.162.192.198
> 142.44.243.216
>
> Or use in the command directly the ip.
> You are behinds a router, proxy , Nat device. May cause problems or deny
> filter traffic. If share a Wireshark capture will see what's happens  ..

>From here, tcpdump/wireshark indicate that something is indeed amiss.
rsync gets through the 3-packet handshake, and then about 20 packets
ending thusly:

11:34:52.749962 IP 192.168.1.73.42138 > 139.162.192.198.rsync: Flags [.], ack 
32, win 502, options [nop,nop,TS val 3218474733 ecr 1658500094], length 0
11:34:52.750309 IP 192.168.1.73.42138 > 139.162.192.198.rsync: Flags [P.], seq 
79:87, ack 32, win 502, options [nop,nop,TS val 3218474733 ecr 1658500094], 
length 8
11:34:52.851104 IP 139.162.192.198.rsync > 192.168.1.73.42138: Flags [.], ack 
87, win 227, options [nop,nop,TS val 1658500119 ecr 3218474733], length 0
11:34:53.162604 IP 139.162.192.198.rsync > 192.168.1.73.42138: Flags [R.], seq 
32, ack 87, win 227, options [nop,nop,TS val 1658500197 ecr 3218474733], length 0

The far end tosses an ACK for the packet, and then an ACK/RST rather than a FIN.
Rather anti-social - usually indicative of the daemon at the far end crashing 
and
closing the socket.

(Side note - is it me, or does the rsync dissector for wireshark do a less than 
optimal job?)

(And yes, I know for a fact that my router doesn't bork rsync, as it works
for other stuff on a regular basis..)


pgpu5ouhJcsD5.pgp
Description: PGP signature

Re: any interesting/useful resources available to IPv6 only?

[Doug Barton]

On 5/3/19 8:14 AM, Brian J. Murrell wrote:

Hi,

I am trying to make a case (to old fuddy-duddies, which is why I even
need to actually make a case) for IPv6 for my own selfish reasons.  :-)

I wonder if anyone has any references to interesting/useful/otherwise
resources on are only available to IPv6 users that they can forward to
me.


This type of marketing approach was pursued doggedly for many of the 
early years of IPv6 rollout. It was as misguided then as it was 
ineffective.


If you have plenty of IPv4 space, you have no case for IPv6. (And I say 
that as one of the most enthusiastic proponents of it.) OTOH, if you 
are/might/will be approach(ing) any kind of IPv4 capacity limitation, 
then you want to start deploying IPv6 ASAP.


The other case that makes business sense is a content provider with a 
lot of traffic. You can get different, and often better, peering 
relationships over IPv6; and there are a lot of eyeball networks, 
especially mobile providers, who are using it natively nowadays.


hope this helps,

Doug

Re: any interesting/useful resources available to IPv6 only?

[Jeroen Massar]

On 2019-05-03 17:14, Brian J. Murrell wrote:
> Hi,
> 
> I am trying to make a case (to old fuddy-duddies, which is why I even
> need to actually make a case) for IPv6 for my own selfish reasons.  :-)
> 
> I wonder if anyone has any references to interesting/useful/otherwise
> resources on are only available to IPv6 users that they can forward to
> me.

IPv6 is not a darknet, you won't find something hidden and unique there.

If you want to make a case for having IPv6, google a bit there are lots of 
reasons.

One good one is presented by Rabobank:

https://ripe74.ripe.net/wp-content/uploads/presentations/3-That-is-why-Rabobank-has-IPv6.pdf

TLDR: customers behind CGN and thus harder to separate them as you suddenly get 
multiple from the same IPv4 instead of more information with one per IPv6

Greets,
 Jeroen

Re: is dnswl dead?

[Christopher Morrow]

/subscribe

On Fri, May 3, 2019 at 11:28 AM Jose Manuel Vazquez Castro
 wrote:
>
> And check first connectivity ping and telnet tcp ports 22 , 873 to ips 
> destination's from your linuxbox:
>
> Record A rsync2.dnswl.org
> 139.162.192.198
> 142.44.243.216
>
> Or use in the command directly the ip.
> You are behinds a router, proxy , Nat device. May cause problems or deny 
> filter traffic. If share a Wireshark capture will see what's happens  ..
>
> El vie., 3 de mayo de 2019 0:23, Randy Bush  escribió:
>>
>> % /usr/local/bin/rsync --times rsync2.dnswl.org::dnswl/bind-dnswl-nons.zone 
>> /var/dns/primary/org.dnswl
>> rsync: read error: Connection reset by peer (54)
>> rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3]
>>
>> this has been going on for a while.  admins do not respond to email.
>> and yes, i paid.
>>
>> would be a bummer.  was useful.
>>
>> randy

Re: is dnswl dead?

[Jose Manuel Vazquez Castro]

And check first connectivity ping and telnet tcp ports 22 , 873 to ips
destination's from your linuxbox:

Record A rsync2.dnswl.org
139.162.192.198
142.44.243.216

Or use in the command directly the ip.
You are behinds a router, proxy , Nat device. May cause problems or deny
filter traffic. If share a Wireshark capture will see what's happens  ..

El vie., 3 de mayo de 2019 0:23, Randy Bush  escribió:

> % /usr/local/bin/rsync --times rsync2.dnswl.org::dnswl/bind-dnswl-nons.zone
> /var/dns/primary/org.dnswl
> rsync: read error: Connection reset by peer (54)
> rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3]
>
> this has been going on for a while.  admins do not respond to email.
> and yes, i paid.
>
> would be a bummer.  was useful.
>
> randy
>

Re: is dnswl dead?

[Jose Manuel Vazquez Castro]

Hi

List files:

rsync rsync2.dnswl.org::dnswl


Try exactly this command

BIND: rsync --times rsync2.dnswl.org::dnswl/bind-* /some/path/


El vie., 3 de mayo de 2019 0:23, Randy Bush  escribió:

> % /usr/local/bin/rsync --times rsync2.dnswl.org::dnswl/bind-dnswl-nons.zone
> /var/dns/primary/org.dnswl
> rsync: read error: Connection reset by peer (54)
> rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3]
>
> this has been going on for a while.  admins do not respond to email.
> and yes, i paid.
>
> would be a bummer.  was useful.
>
> randy
>

any interesting/useful resources available to IPv6 only?

[Brian J. Murrell]

Hi,

I am trying to make a case (to old fuddy-duddies, which is why I even
need to actually make a case) for IPv6 for my own selfish reasons.  :-)

I wonder if anyone has any references to interesting/useful/otherwise
resources on are only available to IPv6 users that they can forward to
me.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: is dnswl dead?

[Randy Bush]

> List files:
> rsync rsync2.dnswl.org::dnswl

sorry.  i am a little confused.  are you trying to tell me how to use
rsync or that dnswl is not broken for you?

i am an rsync addict, and i still fear dnswl is broken.

# rsync rsync2.dnswl.org::dnswl
rsync: read error: Connection reset by peer (54)
rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3]

randy