From gil at cs.technion.ac.il  Tue Nov  8 10:24:32 2016
From: gil at cs.technion.ac.il (Gili Granot)
Date: Tue, 8 Nov 2016 10:24:32 +0200
Subject: =?UTF-8?Q?[Job]_Broadcom_=e2=80=93_software_team_leader?=
Message-ID: <58218BC0.5080605@cs.technion.ac.il>


Broadcom is looking for a software team leader in our site in Yakum, located between Herzliya and Netanya.
The software infrastructure team leader will a team of 5-6 engineers.

We are looking for Exceptional candidates with good university grades, having wide-ranging experience.
Expected to use professional concepts and company objectives to resolve complex issues in creative and effective ways.
Expected to determine methods and procedures for new assignments and coordinate activities of other personnel.
Advantage: experience in team management, with Python, with build/make environment, with Linux.

CVs may be sent to gili at broadcom.com .


From w1 at zak.co.il  Tue Nov  8 21:45:10 2016
From: w1 at zak.co.il (Omer Zak)
Date: Tue, 08 Nov 2016 21:45:10 +0200
Subject: Experience with USB 3.0 Port Replicators for laptops?
Message-ID: <1478634310.2665.34.camel@zak.co.il>

I am again planning to buy hardware, and am looking again for the
collective experience of the community with the hardware being
considered for purchase.

I have a Lenovo Y700 laptop, which was purchased less than a year ago.
It runs Linux (Debian Jessie) with backported kernel 4.7.8
(linux-image-4.7.0-0.bpo.1-amd64, version 4.7.8-1~bpo8+1).

I would like to select an USB 3.0 Port Replicator for it and connect two
additional monitors (to have total of three monitors - laptop's own
monitor + two extra ones).

It was suggested that I'll buy ThinkPad Basic USB 3.0 Dock
(http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:item.detail?hide_menu_area=true&GroupID=460&Code=4X10A06687).
It uses DisplayLink chips, which have Linux support for a while (see:
https://github.com/AdnanHodzic/displaylink-debian).


This port replicator can drive only one external monitor in addition to
the laptop's own monitor.

However, the ThinkPad USB 3.0 Dock
(https://support.lenovo.com/il/en/documents/pd023761) supports two
external monitors.

Does anyone have experience with any of the above?
Are there other non-Lenovo USB 3.0 Port Replicators, which work with
Lenovo Y700?

Thanks,
--- Omer


-- 
What happens if one mixes together evolution with time travel to the
past?  See: http://www.zak.co.il/a/stuff/opinions/eng/evol_tm.html
My own blog is at http://www.zak.co.il/tddpirate/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html



From uri at speedy.net  Tue Nov  8 22:10:17 2016
From: uri at speedy.net (Uri Even-Chen)
Date: Tue, 8 Nov 2016 22:10:17 +0200
Subject: Experience with USB 3.0 Port Replicators for laptops?
In-Reply-To: <1478634310.2665.34.camel@zak.co.il>
References: <1478634310.2665.34.camel@zak.co.il>
Message-ID: <CAMQ2MsE2qv9gN_8imJqbzGF7eFyJEQZ+Mosqw8ykRwWQNf+kaQ@mail.gmail.com>

I would only recommend not to buy anything made in China, because of human
rights, Tibet, and also quality. Isn't Lenovo a Chinese company? Is it made
in China? But I also have stuff made in China because sometimes all the
alternatives are made there. Personally I like South Korea and Samsung,
give it a try (although they are not perfect).


*Uri Even-Chen*
[image: photo] Phone: +972-54-3995700
Email: uri at speedy.net
Website: http://www.speedysoftware.com/uri/en/
<http://www.facebook.com/urievenchen>  <http://plus.google.com/+urievenchen>
  <http://www.linkedin.com/in/urievenchen>  <http://twitter.com/urievenchen>

On Tue, Nov 8, 2016 at 9:45 PM, Omer Zak <w1 at zak.co.il> wrote:

> I am again planning to buy hardware, and am looking again for the
> collective experience of the community with the hardware being
> considered for purchase.
>
> I have a Lenovo Y700 laptop, which was purchased less than a year ago.
> It runs Linux (Debian Jessie) with backported kernel 4.7.8
> (linux-image-4.7.0-0.bpo.1-amd64, version 4.7.8-1~bpo8+1).
>
> I would like to select an USB 3.0 Port Replicator for it and connect two
> additional monitors (to have total of three monitors - laptop's own
> monitor + two extra ones).
>
> It was suggested that I'll buy ThinkPad Basic USB 3.0 Dock
> (http://shop.lenovo.com/SEUILibrary/controller/e/web/
> LenovoPortal/en_US/catalog.workflow:item.detail?hide_
> menu_area=true&GroupID=460&Code=4X10A06687).
> It uses DisplayLink chips, which have Linux support for a while (see:
> https://github.com/AdnanHodzic/displaylink-debian).
>
>
> This port replicator can drive only one external monitor in addition to
> the laptop's own monitor.
>
> However, the ThinkPad USB 3.0 Dock
> (https://support.lenovo.com/il/en/documents/pd023761) supports two
> external monitors.
>
> Does anyone have experience with any of the above?
> Are there other non-Lenovo USB 3.0 Port Replicators, which work with
> Lenovo Y700?
>
> Thanks,
> --- Omer
>
>
> --
> What happens if one mixes together evolution with time travel to the
> past?  See: http://www.zak.co.il/a/stuff/opinions/eng/evol_tm.html
> My own blog is at http://www.zak.co.il/tddpirate/
>
> My opinions, as expressed in this E-mail message, are mine alone.
> They do not represent the official policy of any organization with which
> I may be affiliated in any way.
> WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161108/98cac1a5/attachment-0001.html>

From shlomo.solomon at gmail.com  Sun Nov 20 07:01:10 2016
From: shlomo.solomon at gmail.com (Shlomo Solomon)
Date: Sun, 20 Nov 2016 07:01:10 +0200
Subject: strange ping and traceroute results
Message-ID: <20161120070110.0d2f0616@shlomo1.solomon>

When I try ping or traceroute to www.google.com, I get strange results.
Both utilities "think" that www.google.com is at 213.57.*.*, but those
addresses belong to my Internet provider - Hotnet.

What am I missing?

[solomon at shlomo1]$ ping www.google.com
PING www.google.com (213.57.23.29) 56(84) bytes of data.
64 bytes from 213.57.23.29: icmp_seq=1 ttl=59 time=17.1 ms
64 bytes from 213.57.23.29: icmp_seq=2 ttl=59 time=16.8 ms
64 bytes from 213.57.23.29: icmp_seq=3 ttl=59 time=17.1 ms

[solomon at shlomo1]$ sudo traceroute www.google.com
traceroute to www.google.com (213.57.24.55), 30 hops max, 60 byte packets 
1  router-1.solomon (10.0.0.138)  1.010 ms  1.007 ms  1.006 ms
2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.379 ms  15.741 ms  16.551 ms 
3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 36.177 ms  36.182 ms  36.178 ms 
4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.736 ms  17.736 ms  17.733 ms 
5  * * *
6  * * *
7  * * *
8  * * *


-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5



From d.s at daniel.shahaf.name  Sun Nov 20 07:15:04 2016
From: d.s at daniel.shahaf.name (Daniel Shahaf)
Date: Sun, 20 Nov 2016 05:15:04 +0000
Subject: strange ping and traceroute results
In-Reply-To: <20161120070110.0d2f0616@shlomo1.solomon>
References: <20161120070110.0d2f0616@shlomo1.solomon>
Message-ID: <20161120051504.GA689@fujitsu.shahaf.local2>

Shlomo Solomon wrote on Sun, Nov 20, 2016 at 07:01:10 +0200:
> When I try ping or traceroute to www.google.com, I get strange results.
> Both utilities "think" that www.google.com is at 213.57.*.*, but those
> addresses belong to my Internet provider - Hotnet.
> 
> What am I missing?
> 

Try with a trailing dot?

% ping www.google.com.


Try other domains?

% ping www.$(pwgen).com


From shlomo.solomon at gmail.com  Sun Nov 20 07:42:40 2016
From: shlomo.solomon at gmail.com (Shlomo Solomon)
Date: Sun, 20 Nov 2016 07:42:40 +0200
Subject: strange ping and traceroute results
In-Reply-To: <20161120051504.GA689@fujitsu.shahaf.local2>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <20161120051504.GA689@fujitsu.shahaf.local2>
Message-ID: <20161120074240.730e62f5@shlomo1.solomon>

This seems to be specific to www.google.com. Other addresses work as
expected.

Trailing dot does not change anything.

On Sun, 20 Nov 2016 05:15:04 +0000
Daniel Shahaf <d.s at daniel.shahaf.name> wrote:

> Shlomo Solomon wrote on Sun, Nov 20, 2016 at 07:01:10 +0200:
> > When I try ping or traceroute to www.google.com, I get strange
> > results. Both utilities "think" that www.google.com is at
> > 213.57.*.*, but those addresses belong to my Internet provider -
> > Hotnet.
> > 
> > What am I missing?
> > 
> 
> Try with a trailing dot?
> 
> % ping www.google.com.
> 
> 
> Try other domains?
> 
> % ping www.$(pwgen).com



-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5



From shlomo.solomon at gmail.com  Sun Nov 20 07:43:10 2016
From: shlomo.solomon at gmail.com (Shlomo Solomon)
Date: Sun, 20 Nov 2016 07:43:10 +0200
Subject: strange ping and traceroute results
In-Reply-To: <CAMNrpNObJF4d_ss8L3wS-7yarLZpnJ+eE6Vu5BF3M9-PGnXojw@mail.gmail.com>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <CAMNrpNObJF4d_ss8L3wS-7yarLZpnJ+eE6Vu5BF3M9-PGnXojw@mail.gmail.com>
Message-ID: <20161120074310.52ee1f67@shlomo1.solomon>

Thanks. Any way to get around this? 
I just tried pinging Google-UK (www.google.co.uk) and Google-Canada
(www.google.ca) and I see the same behaviour.



On Sun, 20 Nov 2016 05:13:29 +0000
Geoffrey Mendelson <geoffreymendelson at gmail.com> wrote:

> Google.com resolves to addresses routed to Google.co.il and 8.8.4.4
> and 8.8.8.8 are routed to a local nameserver.
> 
> It is all part of a local cache system.
> 
> Geoff.
> 
> On Sun, Nov 20, 2016, 07:02 Shlomo Solomon <shlomo.solomon at gmail.com>
> wrote:
> 
> > When I try ping or traceroute to www.google.com, I get strange
> > results. Both utilities "think" that www.google.com is at
> > 213.57.*.*, but those addresses belong to my Internet provider -
> > Hotnet.
> >
> > What am I missing?
> >
> > [solomon at shlomo1]$ ping www.google.com
> > PING www.google.com (213.57.23.29) 56(84) bytes of data.
> > 64 bytes from 213.57.23.29: icmp_seq=1 ttl=59 time=17.1 ms
> > 64 bytes from 213.57.23.29: icmp_seq=2 ttl=59 time=16.8 ms
> > 64 bytes from 213.57.23.29: icmp_seq=3 ttl=59 time=17.1 ms
> >
> > [solomon at shlomo1]$ sudo traceroute www.google.com
> > traceroute to www.google.com (213.57.24.55), 30 hops max, 60 byte
> > packets 1  router-1.solomon (10.0.0.138)  1.010 ms  1.007 ms  1.006
> > ms 2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.379 ms
> > 15.741 ms 16.551 ms
> > 3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 36.177 ms
> > 36.182 ms  36.178 ms
> > 4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.736 ms
> > 17.736 ms  17.733 ms
> > 5  * * *
> > 6  * * *
> > 7  * * *
> > 8  * * *
> >
> >
> > --
> > Shlomo Solomon
> > http://the-solomons.net
> > Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5
> >
> >
> > _______________________________________________
> > Linux-il mailing list
> > Linux-il at cs.huji.ac.il
> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
> >



-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5



From linux-il at shimi.net  Sun Nov 20 08:25:18 2016
From: linux-il at shimi.net (shimi)
Date: Sun, 20 Nov 2016 08:25:18 +0200
Subject: strange ping and traceroute results
In-Reply-To: <20161120070110.0d2f0616@shlomo1.solomon>
References: <20161120070110.0d2f0616@shlomo1.solomon>
Message-ID: <CAKnt4U8x=FpQ0x9D+qdr+0C8Y_6EsTVSzgKnH8+2Decmkn+Qpg@mail.gmail.com>

On 20 Nov 2016 07:02, "Shlomo Solomon" <shlomo.solomon at gmail.com> wrote:
>
> When I try ping or traceroute to www.google.com, I get strange results.
> Both utilities "think" that www.google.com is at 213.57.*.*, but those
> addresses belong to my Internet provider - Hotnet.
>
> What am I missing?
>
> [solomon at shlomo1]$ ping www.google.com
> PING www.google.com (213.57.23.29) 56(84) bytes of data.
> 64 bytes from 213.57.23.29: icmp_seq=1 ttl=59 time=17.1 ms
> 64 bytes from 213.57.23.29: icmp_seq=2 ttl=59 time=16.8 ms
> 64 bytes from 213.57.23.29: icmp_seq=3 ttl=59 time=17.1 ms
>
> [solomon at shlomo1]$ sudo traceroute www.google.com
> traceroute to www.google.com (213.57.24.55), 30 hops max, 60 byte packets
> 1  router-1.solomon (10.0.0.138)  1.010 ms  1.007 ms  1.006 ms
> 2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.379 ms  15.741 ms
16.551 ms
> 3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 36.177 ms  36.182
ms  36.178 ms
> 4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.736 ms  17.736
ms  17.733 ms
> 5  * * *
> 6  * * *
> 7  * * *
> 8  * * *

I believe it's called a CDN and/or local compute clusters and the purpose
of it is to give you a better user experience, which is a Good Thing (TM).

There are other similar POPs I saw at least in BezeqInt.

The question really is:

Why do you think it's a problem and are trying to avoid it?

If your reply includes the letters M-I-T-M, please consider that without
installing a fake CA cert on your host, MITMing an SSL/TLS connection WILL
cause a connection set up error from your browser.

HTH,

-- Shimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161120/e48435ef/attachment-0001.html>

From shlomo.solomon at gmail.com  Sun Nov 20 09:38:31 2016
From: shlomo.solomon at gmail.com (Shlomo Solomon)
Date: Sun, 20 Nov 2016 09:38:31 +0200
Subject: strange ping and traceroute results
In-Reply-To: <CAKnt4U8x=FpQ0x9D+qdr+0C8Y_6EsTVSzgKnH8+2Decmkn+Qpg@mail.gmail.com>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <CAKnt4U8x=FpQ0x9D+qdr+0C8Y_6EsTVSzgKnH8+2Decmkn+Qpg@mail.gmail.com>
Message-ID: <20161120093831.363b0a3a@shlomo1.solomon>

On Sun, 20 Nov 2016 08:25:18 +0200
shimi <linux-il at shimi.net> wrote:

> I believe it's called a CDN and/or local compute clusters and the
> purpose of it is to give you a better user experience, which is a
> Good Thing (TM).
> 
snip ... snip ... snip
> 
> Why do you think it's a problem and are trying to avoid it?
> 

Thanks. I agree that this is "normally" a Good Thing (TM). So I guess I
have to explain my problem. For a course I'm doing, I had to write
traceroute in Python   -   re-invent the wheel :-) 

My program works, but I noticed it never reaches www.google.com so I
checked the "real" traceroute and found the same behaviour. 

It seems that neither my program nor the real traceroute handle this
properly - i.e. they never report that they've reached the final hop.
I've included traceroute www.godaddy.com and traceroute www.google.com
for comparison. You can see that traceroute www.google.com never
reaches the address it's trying to reach - 213.57.24.49




[solomon at shlomo1 ~]$ sudo traceroute www.godaddy.com
traceroute to www.godaddy.com (23.44.253.116), 30 hops max, 60 byte
packets 
1  router-1.solomon (10.0.0.138)  0.610 ms  0.979 ms  0.977 ms
2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.370 ms  15.753
ms  16.148 ms 
3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 16.544 ms
16.543 ms  16.553 ms 
4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.345 ms
18.132 ms  18.524 ms 
5  207.232.21.146 (207.232.21.146)  20.941 ms  20.948 ms  20.944 ms 
6 core1-TenGigE0-4-0-1.hfa.nv.net.il (212.143.8.226)  21.311 ms
core1-0-5-0-21-edge1.hfa.nv.net.il (212.143.7.173)  22.651 ms  22.379 ms 
7  cdn-sw1-1-35-core1-2-5-hfa.hfa.nv.net.il (212.143.7.252)  21.129 ms
cdn-sw1-1-45-core1.hfa.nv.net.il (212.143.7.209)  18.333 ms cdn-sw1-1-43-core1.hfa.nv.net.il (212.143.7.201)  19.097 ms 
8 a23-44-253-116.deploy.static.akamaitechnologies.com (23.44.253.116)
18.299 ms  18.290 ms  18.703 ms



[solomon at shlomo1 ~]$ sudo traceroute www.google.com
traceroute to www.google.com (213.57.24.49), 30 hops max, 60 byte
packets 
1 router-1.solomon (10.0.0.138)  0.943 ms  0.937 ms  0.934 ms 
2 core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.313 ms  15.720 ms
16.114 ms 
3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 16.128 ms
16.526 ms  16.526 ms 
4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  21.311 ms
21.692 ms  21.675 ms 
5  * * * 
6  * * * 
7  * * * 
8  * * * 
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[solomon at shlomo1 ~]$ 



-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5



From linux-il at shimi.net  Sun Nov 20 10:18:37 2016
From: linux-il at shimi.net (shimi)
Date: Sun, 20 Nov 2016 10:18:37 +0200
Subject: strange ping and traceroute results
In-Reply-To: <20161120093831.363b0a3a@shlomo1.solomon>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <CAKnt4U8x=FpQ0x9D+qdr+0C8Y_6EsTVSzgKnH8+2Decmkn+Qpg@mail.gmail.com>
 <20161120093831.363b0a3a@shlomo1.solomon>
Message-ID: <CAKnt4U-oL6n=QfRaRSiuUQgVfCJGZ9cdYS4s7k7XfzqxJ+4_tw@mail.gmail.com>

On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon <shlomo.solomon at gmail.com>
wrote:

> On Sun, 20 Nov 2016 08:25:18 +0200
> shimi <linux-il at shimi.net> wrote:
>
> > I believe it's called a CDN and/or local compute clusters and the
> > purpose of it is to give you a better user experience, which is a
> > Good Thing (TM).
> >
> snip ... snip ... snip
> >
> > Why do you think it's a problem and are trying to avoid it?
> >
>
> Thanks. I agree that this is "normally" a Good Thing (TM). So I guess I
> have to explain my problem. For a course I'm doing, I had to write
> traceroute in Python   -   re-invent the wheel :-)
>
> My program works, but I noticed it never reaches www.google.com so I
> checked the "real" traceroute and found the same behaviour.
>
> It seems that neither my program nor the real traceroute handle this
> properly - i.e. they never report that they've reached the final hop.
> I've included traceroute www.godaddy.com and traceroute www.google.com
> for comparison. You can see that traceroute www.google.com never
> reaches the address it's trying to reach - 213.57.24.49
>
>
I do not believe the fact that you "can't reach it" has anything to do with
www.google.com resolving to an IP in Israel.

Since I am assuming that for your re-inventing the wheel exercise, you did
learn and understood what traceroute does; But let me explain it anyway for
the answer to your question lies within...

What traceroute does is essentially send packets to the destination IP by
certain protocol. Popular choices include UDP (I believe that's what the
Linux one does by default), ICMP (I believe that's what the Windows one
does by default) and TCP.

However, it doesn't send the packet as one normally would, with a large TTL
(Time To Live) value which is expected to reach anywhere on the Internet
(typical values: >= 64), rather than it starts of with setting a minimal
value for TTL, for the purpose of _not_ getting into the target IP, rather
than the packet being dropped by the very first router (hop) on the chain,
resulting in error in packet  delivery.

Per the IP specification, such a packet discarding SHOULD produce an
ICMP (Internet
Control Message Protocol) message being sent by the hop that has discarded
the packet towards the originator of the original packet, telling it that
"TTL expired in transit". The original idea was to avoid packets travelling
to infinitum in routing loops - by decreasing the TTL by 1 on every hop the
packet passes, eventually it will zero out, and the packet will be
discarded, not causing a bandwidth storm.

So, I said SHOULD. Does it always? Well, no. Some hosts on the Internet
employ something called "a firewall", which blocks ICMP for various reasons
(you'll hear the word "security" in some places); As a regular user who
opens his browser and types in 'https://www.google.com/' - you don't really
care. ICMP is not typically used when establishing a connection to a server
on the Internet (well, that's not accurate; lack of PMTU discovery is an
excellent way to get your IT people to pull some hairs out when any tunnel
is involved, including dialup and Israeli "MPLS" connections, a.k.a.
"dialer-less HOT"... but for the sake of discussion and to explain how did
they ended up deciding to filter those packets and affect you - probably
not knowing what else they break - then "it's not typically used")

Sometimes the filtering is not of ICMP at all, rather than the original
protocol you're trying to probe with; A random UDP port at the area of
30,000 typically has no business traversing their network, so your original
packet (if you're using UDP packets for your traceroute program) may have
been firewalled and never reached a router to lower its TTL by 1 and expire
it in transit to produce the ICMP message you're expecting... In that case,
where ICMP is not actually block, rather your UDP connection is, you might
find out that running:

traceroute -I 213.57.24.49

(I for ICMP Echo based traceroute)

Does actually get you to the target. However, you'll have to run this as
root, because generating ICMP packets is not something the regular user can
do. Of course, you can opt to chmod +s your traceroute binary...

Hope this helps,

-- Shimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161120/eefb61ba/attachment-0001.html>

From amos.shapira at gmail.com  Sun Nov 20 13:03:54 2016
From: amos.shapira at gmail.com (Amos Shapira)
Date: Sun, 20 Nov 2016 22:03:54 +1100
Subject: strange ping and traceroute results
In-Reply-To: <CAKnt4U-oL6n=QfRaRSiuUQgVfCJGZ9cdYS4s7k7XfzqxJ+4_tw@mail.gmail.com>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <CAKnt4U8x=FpQ0x9D+qdr+0C8Y_6EsTVSzgKnH8+2Decmkn+Qpg@mail.gmail.com>
 <20161120093831.363b0a3a@shlomo1.solomon>
 <CAKnt4U-oL6n=QfRaRSiuUQgVfCJGZ9cdYS4s7k7XfzqxJ+4_tw@mail.gmail.com>
Message-ID: <CAF9n_WVECVQX_G3Quwbqe-vDnq+eu0T-_QH72hYpmeqD8O3aVg@mail.gmail.com>

Google.com is not one computer. Google spreads their locations all over the
world including pops in many ISP's.

https://peering.google.com/#/

On 20 November 2016 at 19:18, shimi <linux-il at shimi.net> wrote:

>
>
> On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon <shlomo.solomon at gmail.com>
> wrote:
>
>> On Sun, 20 Nov 2016 08:25:18 +0200
>> shimi <linux-il at shimi.net> wrote:
>>
>> > I believe it's called a CDN and/or local compute clusters and the
>> > purpose of it is to give you a better user experience, which is a
>> > Good Thing (TM).
>> >
>> snip ... snip ... snip
>> >
>> > Why do you think it's a problem and are trying to avoid it?
>> >
>>
>> Thanks. I agree that this is "normally" a Good Thing (TM). So I guess I
>> have to explain my problem. For a course I'm doing, I had to write
>> traceroute in Python   -   re-invent the wheel :-)
>>
>> My program works, but I noticed it never reaches www.google.com so I
>> checked the "real" traceroute and found the same behaviour.
>>
>> It seems that neither my program nor the real traceroute handle this
>> properly - i.e. they never report that they've reached the final hop.
>> I've included traceroute www.godaddy.com and traceroute www.google.com
>> for comparison. You can see that traceroute www.google.com never
>> reaches the address it's trying to reach - 213.57.24.49
>>
>>
> I do not believe the fact that you "can't reach it" has anything to do
> with www.google.com resolving to an IP in Israel.
>
> Since I am assuming that for your re-inventing the wheel exercise, you did
> learn and understood what traceroute does; But let me explain it anyway for
> the answer to your question lies within...
>
> What traceroute does is essentially send packets to the destination IP by
> certain protocol. Popular choices include UDP (I believe that's what the
> Linux one does by default), ICMP (I believe that's what the Windows one
> does by default) and TCP.
>
> However, it doesn't send the packet as one normally would, with a large
> TTL (Time To Live) value which is expected to reach anywhere on the
> Internet (typical values: >= 64), rather than it starts of with setting a
> minimal value for TTL, for the purpose of _not_ getting into the target IP,
> rather than the packet being dropped by the very first router (hop) on the
> chain, resulting in error in packet  delivery.
>
> Per the IP specification, such a packet discarding SHOULD produce an ICMP (Internet
> Control Message Protocol) message being sent by the hop that has discarded
> the packet towards the originator of the original packet, telling it that
> "TTL expired in transit". The original idea was to avoid packets travelling
> to infinitum in routing loops - by decreasing the TTL by 1 on every hop the
> packet passes, eventually it will zero out, and the packet will be
> discarded, not causing a bandwidth storm.
>
> So, I said SHOULD. Does it always? Well, no. Some hosts on the Internet
> employ something called "a firewall", which blocks ICMP for various reasons
> (you'll hear the word "security" in some places); As a regular user who
> opens his browser and types in 'https://www.google.com/' - you don't
> really care. ICMP is not typically used when establishing a connection to a
> server on the Internet (well, that's not accurate; lack of PMTU discovery
> is an excellent way to get your IT people to pull some hairs out when any
> tunnel is involved, including dialup and Israeli "MPLS" connections, a.k.a.
> "dialer-less HOT"... but for the sake of discussion and to explain how did
> they ended up deciding to filter those packets and affect you - probably
> not knowing what else they break - then "it's not typically used")
>
> Sometimes the filtering is not of ICMP at all, rather than the original
> protocol you're trying to probe with; A random UDP port at the area of
> 30,000 typically has no business traversing their network, so your original
> packet (if you're using UDP packets for your traceroute program) may have
> been firewalled and never reached a router to lower its TTL by 1 and expire
> it in transit to produce the ICMP message you're expecting... In that case,
> where ICMP is not actually block, rather your UDP connection is, you might
> find out that running:
>
> traceroute -I 213.57.24.49
>
> (I for ICMP Echo based traceroute)
>
> Does actually get you to the target. However, you'll have to run this as
> root, because generating ICMP packets is not something the regular user can
> do. Of course, you can opt to chmod +s your traceroute binary...
>
> Hope this helps,
>
> -- Shimi
>
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>


-- 
<http://au.linkedin.com/in/gliderflyer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161120/005b87d6/attachment-0001.html>

From shlomo.solomon at gmail.com  Sun Nov 20 15:20:14 2016
From: shlomo.solomon at gmail.com (Shlomo Solomon)
Date: Sun, 20 Nov 2016 15:20:14 +0200
Subject: strange ping and traceroute results
In-Reply-To: <CAKnt4U-oL6n=QfRaRSiuUQgVfCJGZ9cdYS4s7k7XfzqxJ+4_tw@mail.gmail.com>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <CAKnt4U8x=FpQ0x9D+qdr+0C8Y_6EsTVSzgKnH8+2Decmkn+Qpg@mail.gmail.com>
 <20161120093831.363b0a3a@shlomo1.solomon>
 <CAKnt4U-oL6n=QfRaRSiuUQgVfCJGZ9cdYS4s7k7XfzqxJ+4_tw@mail.gmail.com>
Message-ID: <20161120152014.1f00d988@shlomo1.solomon>

On Sun, 20 Nov 2016 10:18:37 +0200
shimi <linux-il at shimi.net> wrote:

Thanks for your very detailed reply. As you correctly assumed, I did
learn about traceroute before re-inventing the wheel, so most of what
you wrote was familiar. But I didn't know about the -I parameter.
 
traceroute -I www.google.com does, as you wrote, get to the target. 

Since I think that that's more than I'm expected to emulate, I
added a more "friendly" error message to my program in the case of a
(FW caused) timeout.




-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5



From shachar at shemesh.biz  Mon Nov 21 09:20:45 2016
From: shachar at shemesh.biz (Shachar Shemesh)
Date: Mon, 21 Nov 2016 09:20:45 +0200
Subject: strange ping and traceroute results
In-Reply-To: <20161120070110.0d2f0616@shlomo1.solomon>
References: <20161120070110.0d2f0616@shlomo1.solomon>
Message-ID: <de054c58-7a11-850a-2595-7c152cd04fc4@shemesh.biz>

On 20/11/16 07:01, Shlomo Solomon wrote:
> When I try ping or traceroute to www.google.com, I get strange results.
> Both utilities "think" that www.google.com is at 213.57.*.*, but those
> addresses belong to my Internet provider - Hotnet.
>
> What am I missing?
>
> [solomon at shlomo1]$ ping www.google.com
> PING www.google.com (213.57.23.29) 56(84) bytes of data.
> 64 bytes from 213.57.23.29: icmp_seq=1 ttl=59 time=17.1 ms
> 64 bytes from 213.57.23.29: icmp_seq=2 ttl=59 time=16.8 ms
> 64 bytes from 213.57.23.29: icmp_seq=3 ttl=59 time=17.1 ms
>
> [solomon at shlomo1]$ sudo traceroute www.google.com
> traceroute to www.google.com (213.57.24.55), 30 hops max, 60 byte packets 
> 1  router-1.solomon (10.0.0.138)  1.010 ms  1.007 ms  1.006 ms
> 2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.379 ms  15.741 ms  16.551 ms 
> 3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 36.177 ms  36.182 ms  36.178 ms 
> 4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.736 ms  17.736 ms  17.733 ms 
The DNS resolving google.com guesses your gegraphical location, and
gives you an answer that is nearest where you are. If you use another
DNS to query the domain, you will get a different IP:


216.58.218.196 from
http://mxtoolbox.com/SuperTool.aspx?action=a%3awww.google.com&run=toolpage
74.125.22.103 from https://www.ultratools.com/tools/dnsLookupResult
216.58.209.68 from http://ping.eu/nslookup/

If you are dead set on using a different IP than your local one, you can
use this trick to do this.

Shachar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161121/840e48da/attachment-0001.html>

From amos.shapira at gmail.com  Tue Nov 22 02:19:36 2016
From: amos.shapira at gmail.com (Amos Shapira)
Date: Tue, 22 Nov 2016 11:19:36 +1100
Subject: strange ping and traceroute results
In-Reply-To: <de054c58-7a11-850a-2595-7c152cd04fc4@shemesh.biz>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <de054c58-7a11-850a-2595-7c152cd04fc4@shemesh.biz>
Message-ID: <CAF9n_WW=V43FgSvvVS34qZhrFHh0m1uYOZON2Rtpsc0wCjJZsg@mail.gmail.com>

On 21 November 2016 at 18:20, Shachar Shemesh <shachar at shemesh.biz> wrote:

> The DNS resolving google.com guesses your gegraphical location, and gives
> you an answer that is nearest where you are. If you use another DNS to
> query the domain, you will get a different IP:
>

It's not always a "guess your geographic location". The smarter ones use
Anycast to advertise the same IP address from multiple locations on the
Internet and let BGP do its magic to route your packets to the nearest
server, taking into account any congestion or other transient connection
speed changes. This is how Google's DNS 8.8.8.8 works, or Akamai's CDN. The
nice thing about it is that you get optimal response even at the host
resolution stage. The DNS server can then take its knowledge of the DNS
query source address into account when it decides which IP address to
resolve to.

It's pretty neat, personally I find it a fascinating trick:
https://en.wikipedia.org/wiki/Anycast

--Amos
-- 
<http://au.linkedin.com/in/gliderflyer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161122/774b7888/attachment-0001.html>

From shachar at shemesh.biz  Wed Nov 23 19:06:54 2016
From: shachar at shemesh.biz (Shachar Shemesh)
Date: Wed, 23 Nov 2016 19:06:54 +0200
Subject: strange ping and traceroute results
In-Reply-To: <CAF9n_WW=V43FgSvvVS34qZhrFHh0m1uYOZON2Rtpsc0wCjJZsg@mail.gmail.com>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <de054c58-7a11-850a-2595-7c152cd04fc4@shemesh.biz>
 <CAF9n_WW=V43FgSvvVS34qZhrFHh0m1uYOZON2Rtpsc0wCjJZsg@mail.gmail.com>
Message-ID: <72497916-7737-e884-344f-a3789ddb4ca5@shemesh.biz>

On 22/11/16 02:19, Amos Shapira wrote:
> On 21 November 2016 at 18:20, Shachar Shemesh <shachar at shemesh.biz
> <mailto:shachar at shemesh.biz>> wrote:
>
>     The DNS resolving google.com <http://google.com> guesses your
>     gegraphical location, and gives you an answer that is nearest
>     where you are. If you use another DNS to query the domain, you
>     will get a different IP:
>
>
> It's not always a "guess your geographic location". The smarter ones
> use Anycast to advertise the same IP address from multiple locations
> on the Internet and let BGP do its magic to route your packets to the
> nearest server, taking into account any congestion or other transient
> connection speed changes. This is how Google's DNS 8.8.8.8 works, or
> Akamai's CDN. The nice thing about it is that you get optimal response
> even at the host resolution stage. The DNS server can then take its
> knowledge of the DNS query source address into account when it decides
> which IP address to resolve to.
>
> It's pretty neat, personally I find it a fascinating trick:
> https://en.wikipedia.org/wiki/Anycast
>
It is, quite fascinating. It is not, unfortunately, as useful as you
make it out to be. Neither Google nor Akamai use it for web traffic, for
example.

The reason is twofold. First, anycast is poorly equipted to handle TCP
connections. There is a (remote) possibility that the handler of your IP
would change mid-request, which would not play nice with your connection.

The second, more pertinent, reason is that , at least for Akamai, they
would like to be able to control which server you reach when you make a
request. The would like to be able to re-route your in case something
bad happens to that server. DNS TTL can be set as low as 30 or 60
seconds. BGP routes have much longer settle times.

Shachar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161123/678a802f/attachment.html>

From dronkin at gmail.com  Wed Nov 23 20:24:51 2016
From: dronkin at gmail.com (David Ronkin)
Date: Wed, 23 Nov 2016 20:24:51 +0200
Subject: fax spam malware
Message-ID: <CAGq1vfFWN6j1EBQ=QDAUC3k3qCpBtMTO2qbSMuL-1G-WNp2mcg@mail.gmail.com>

Security related, sorry not linux but important also to warn others..

Last few days i get plenty of similar junk mails but they are NOT filtered
and not sent to the junk folder! They're also from different aliases of
course.. and a bit different subject strings (nice attack :( )

So i wonder:

1. If somebody still not sure i believe it it's not only a spam but  a
virus! (found it googling)
2. Why gmail not able to filter them correctly and block/put into spam
(clicked few times spam but no helped..)
3. Any way to get rid of them?

Tnx,
David



-- 
?????,
??? ??????

*?? ???? ????? ??*?: http://dronkin.blogspot.com
*?????*: http://www.youtube.com/user/ronkinim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161123/8eb0d3dd/attachment.html>

From amos.shapira at gmail.com  Fri Nov 25 00:14:48 2016
From: amos.shapira at gmail.com (Amos Shapira)
Date: Fri, 25 Nov 2016 09:14:48 +1100
Subject: strange ping and traceroute results
In-Reply-To: <72497916-7737-e884-344f-a3789ddb4ca5@shemesh.biz>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <de054c58-7a11-850a-2595-7c152cd04fc4@shemesh.biz>
 <CAF9n_WW=V43FgSvvVS34qZhrFHh0m1uYOZON2Rtpsc0wCjJZsg@mail.gmail.com>
 <72497916-7737-e884-344f-a3789ddb4ca5@shemesh.biz>
Message-ID: <CAF9n_WV4VMdX=dL8S6WjipA=fDCT9ES=v--PygzkDCN0PdnAcg@mail.gmail.com>

Anycast is not suitable for TCP.
It IS fantastic for DNS (which uses UDP), which is the first thing a client
does most of the time to find the server.
Akamai control server groups by allocating per-customer per-object host
names, then these can be resolved using their very highly customised DNS
servers to the right server (also taking into account dynamic changes like
server cluster load or failure).
Since DNS uses UDP and the traffic consists on one packet in each
direction, Anycast is ideal for that scenario.
The actual content transfer (e.g. move streams, which is where I with
Akamai for stan.com.au) doesn't use Anycast.

On 24 November 2016 at 04:06, Shachar Shemesh <shachar at shemesh.biz> wrote:

> On 22/11/16 02:19, Amos Shapira wrote:
>
> On 21 November 2016 at 18:20, Shachar Shemesh <shachar at shemesh.biz> wrote:
>
>> The DNS resolving google.com guesses your gegraphical location, and
>> gives you an answer that is nearest where you are. If you use another DNS
>> to query the domain, you will get a different IP:
>>
>
> It's not always a "guess your geographic location". The smarter ones use
> Anycast to advertise the same IP address from multiple locations on the
> Internet and let BGP do its magic to route your packets to the nearest
> server, taking into account any congestion or other transient connection
> speed changes. This is how Google's DNS 8.8.8.8 works, or Akamai's CDN. The
> nice thing about it is that you get optimal response even at the host
> resolution stage. The DNS server can then take its knowledge of the DNS
> query source address into account when it decides which IP address to
> resolve to.
>
> It's pretty neat, personally I find it a fascinating trick:
> https://en.wikipedia.org/wiki/Anycast
>
> It is, quite fascinating. It is not, unfortunately, as useful as you make
> it out to be. Neither Google nor Akamai use it for web traffic, for example.
>
> The reason is twofold. First, anycast is poorly equipted to handle TCP
> connections. There is a (remote) possibility that the handler of your IP
> would change mid-request, which would not play nice with your connection.
>
> The second, more pertinent, reason is that , at least for Akamai, they
> would like to be able to control which server you reach when you make a
> request. The would like to be able to re-route your in case something bad
> happens to that server. DNS TTL can be set as low as 30 or 60 seconds. BGP
> routes have much longer settle times.
>
> Shachar
>



-- 
<http://au.linkedin.com/in/gliderflyer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161125/af833c62/attachment.html>

From tewner at gmail.com  Fri Nov 25 10:42:55 2016
From: tewner at gmail.com (Michael Tewner)
Date: Fri, 25 Nov 2016 10:42:55 +0200
Subject: strange ping and traceroute results
In-Reply-To: <CAF9n_WV4VMdX=dL8S6WjipA=fDCT9ES=v--PygzkDCN0PdnAcg@mail.gmail.com>
References: <20161120070110.0d2f0616@shlomo1.solomon>
 <de054c58-7a11-850a-2595-7c152cd04fc4@shemesh.biz>
 <CAF9n_WW=V43FgSvvVS34qZhrFHh0m1uYOZON2Rtpsc0wCjJZsg@mail.gmail.com>
 <72497916-7737-e884-344f-a3789ddb4ca5@shemesh.biz>
 <CAF9n_WV4VMdX=dL8S6WjipA=fDCT9ES=v--PygzkDCN0PdnAcg@mail.gmail.com>
Message-ID: <CAPxava-=xqB24=4hVp9Z+0KHckm1V3Kunz7qc+rdN+pq+zBakw@mail.gmail.com>

Heh - You _learn_ that Anycast isn't good for TCP, but LinkedIn proved
differently. Their website uses TCP (obviously), works almost always, and
gracefully recovers when Anycast throws a curve.

There's a great interview on Packet Pushers with LinkedIn Global
Engineering:

Packet Pushers: Show 286: Busting Anycast TCP Myths
http://packetpushers.net/podcast/podcasts/show-286-busting-anycast-tcp-myths/

...and a blog post:
https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality

-Mike Tewner



On Fri, Nov 25, 2016 at 12:14 AM, Amos Shapira <amos.shapira at gmail.com>
wrote:

> Anycast is not suitable for TCP.
> It IS fantastic for DNS (which uses UDP), which is the first thing a
> client does most of the time to find the server.
> Akamai control server groups by allocating per-customer per-object host
> names, then these can be resolved using their very highly customised DNS
> servers to the right server (also taking into account dynamic changes like
> server cluster load or failure).
> Since DNS uses UDP and the traffic consists on one packet in each
> direction, Anycast is ideal for that scenario.
> The actual content transfer (e.g. move streams, which is where I with
> Akamai for stan.com.au) doesn't use Anycast.
>
> On 24 November 2016 at 04:06, Shachar Shemesh <shachar at shemesh.biz> wrote:
>
>> On 22/11/16 02:19, Amos Shapira wrote:
>>
>> On 21 November 2016 at 18:20, Shachar Shemesh <shachar at shemesh.biz>
>> wrote:
>>
>>> The DNS resolving google.com guesses your gegraphical location, and
>>> gives you an answer that is nearest where you are. If you use another DNS
>>> to query the domain, you will get a different IP:
>>>
>>
>> It's not always a "guess your geographic location". The smarter ones use
>> Anycast to advertise the same IP address from multiple locations on the
>> Internet and let BGP do its magic to route your packets to the nearest
>> server, taking into account any congestion or other transient connection
>> speed changes. This is how Google's DNS 8.8.8.8 works, or Akamai's CDN. The
>> nice thing about it is that you get optimal response even at the host
>> resolution stage. The DNS server can then take its knowledge of the DNS
>> query source address into account when it decides which IP address to
>> resolve to.
>>
>> It's pretty neat, personally I find it a fascinating trick:
>> https://en.wikipedia.org/wiki/Anycast
>>
>> It is, quite fascinating. It is not, unfortunately, as useful as you make
>> it out to be. Neither Google nor Akamai use it for web traffic, for example.
>>
>> The reason is twofold. First, anycast is poorly equipted to handle TCP
>> connections. There is a (remote) possibility that the handler of your IP
>> would change mid-request, which would not play nice with your connection.
>>
>> The second, more pertinent, reason is that , at least for Akamai, they
>> would like to be able to control which server you reach when you make a
>> request. The would like to be able to re-route your in case something bad
>> happens to that server. DNS TTL can be set as low as 30 or 60 seconds. BGP
>> routes have much longer settle times.
>>
>> Shachar
>>
>
>
>
> --
> <http://au.linkedin.com/in/gliderflyer>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161125/36e14f15/attachment-0001.html>

From elazarl at gmail.com  Tue Nov 29 08:41:59 2016
From: elazarl at gmail.com (Elazar Leibovich)
Date: Tue, 29 Nov 2016 08:41:59 +0200
Subject: Interop with Windows zeroconf/LLMNR
Message-ID: <CAHNTFmLnTOSkF5fqJfVGbGf+86dHgtZEdEAr761c8L2wWv57MQ@mail.gmail.com>

Hi,

It's really convenient that two Linux computers usuallly have mDNS
installed by default.
I can then do scp x moshe.local, to my friend's laptop.

In order for that to work with Windows, one can enable Window's zeroconf
standard, LLMNR. The easiest way is by configuring systemd-resolved to
support LLMNR.

Alas, when I did that, two Windows laptop I examined had LLMNR turned off.
The owners were not sure why.

Can anyone estimate why this happened?

Is LLMNR really a good way to interop with Windows, or would half of the
Windows machine would have it turned off?

Anyone has experience with that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161129/1bef9528/attachment.html>

From govershay at gmail.com  Tue Nov 29 15:21:09 2016
From: govershay at gmail.com (Shay Gover)
Date: Tue, 29 Nov 2016 15:21:09 +0200
Subject: Interop with Windows zeroconf/LLMNR
In-Reply-To: <CAHNTFmLnTOSkF5fqJfVGbGf+86dHgtZEdEAr761c8L2wWv57MQ@mail.gmail.com>
References: <CAHNTFmLnTOSkF5fqJfVGbGf+86dHgtZEdEAr761c8L2wWv57MQ@mail.gmail.com>
Message-ID: <CANM5d8edMGOA0ziWwktCpFivFmEYtowmMT81VUecKBJYvw2vKA@mail.gmail.com>

Once upon a time I was a Windows sysadmin. Anyway, there was a nice site,
called blackviper.com that listed windows services default state. However
it's appears it's down now. Maybe tomorrow it'll be up?

Shay

On Tue, Nov 29, 2016 at 8:41 AM, Elazar Leibovich <elazarl at gmail.com> wrote:

> Hi,
>
> It's really convenient that two Linux computers usuallly have mDNS
> installed by default.
> I can then do scp x moshe.local, to my friend's laptop.
>
> In order for that to work with Windows, one can enable Window's zeroconf
> standard, LLMNR. The easiest way is by configuring systemd-resolved to
> support LLMNR.
>
> Alas, when I did that, two Windows laptop I examined had LLMNR turned off.
> The owners were not sure why.
>
> Can anyone estimate why this happened?
>
> Is LLMNR really a good way to interop with Windows, or would half of the
> Windows machine would have it turned off?
>
> Anyone has experience with that?
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161129/df74f077/attachment.html>

From elazarl at gmail.com  Tue Nov 29 15:23:11 2016
From: elazarl at gmail.com (Elazar Leibovich)
Date: Tue, 29 Nov 2016 15:23:11 +0200
Subject: Interop with Windows zeroconf/LLMNR
In-Reply-To: <CANM5d8edMGOA0ziWwktCpFivFmEYtowmMT81VUecKBJYvw2vKA@mail.gmail.com>
References: <CAHNTFmLnTOSkF5fqJfVGbGf+86dHgtZEdEAr761c8L2wWv57MQ@mail.gmail.com>
 <CANM5d8edMGOA0ziWwktCpFivFmEYtowmMT81VUecKBJYvw2vKA@mail.gmail.com>
Message-ID: <CAHNTFmLBZ7gUYkT5Eq_y29wwWSCmmJOz2xioSV9xvYSGC2wUmw@mail.gmail.com>

Thanks,

Even if it's up by default, which seems to be the case at least for some
Windows versions, I still want to know from people's experience, how common
it is to have someone shut it down.
Is it a good practice?
Are organization do that as a security hardening measure?
Etc.

On Tue, Nov 29, 2016 at 3:21 PM, Shay Gover <govershay at gmail.com> wrote:

> Once upon a time I was a Windows sysadmin. Anyway, there was a nice site,
> called blackviper.com that listed windows services default state. However
> it's appears it's down now. Maybe tomorrow it'll be up?
>
> Shay
>
> On Tue, Nov 29, 2016 at 8:41 AM, Elazar Leibovich <elazarl at gmail.com>
> wrote:
>
>> Hi,
>>
>> It's really convenient that two Linux computers usuallly have mDNS
>> installed by default.
>> I can then do scp x moshe.local, to my friend's laptop.
>>
>> In order for that to work with Windows, one can enable Window's zeroconf
>> standard, LLMNR. The easiest way is by configuring systemd-resolved to
>> support LLMNR.
>>
>> Alas, when I did that, two Windows laptop I examined had LLMNR turned
>> off. The owners were not sure why.
>>
>> Can anyone estimate why this happened?
>>
>> Is LLMNR really a good way to interop with Windows, or would half of the
>> Windows machine would have it turned off?
>>
>> Anyone has experience with that?
>>
>> _______________________________________________
>> Linux-il mailing list
>> Linux-il at cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161129/239669d3/attachment.html>

From govershay at gmail.com  Tue Nov 29 15:29:23 2016
From: govershay at gmail.com (Shay Gover)
Date: Tue, 29 Nov 2016 15:29:23 +0200
Subject: Interop with Windows zeroconf/LLMNR
In-Reply-To: <CAHNTFmLBZ7gUYkT5Eq_y29wwWSCmmJOz2xioSV9xvYSGC2wUmw@mail.gmail.com>
References: <CAHNTFmLnTOSkF5fqJfVGbGf+86dHgtZEdEAr761c8L2wWv57MQ@mail.gmail.com>
 <CANM5d8edMGOA0ziWwktCpFivFmEYtowmMT81VUecKBJYvw2vKA@mail.gmail.com>
 <CAHNTFmLBZ7gUYkT5Eq_y29wwWSCmmJOz2xioSV9xvYSGC2wUmw@mail.gmail.com>
Message-ID: <CANM5d8dK+LgRXb-bz3=rBa_Ugr9o6nrx+=5Fp9hqcOUiVHmNgw@mail.gmail.com>

As hardening maybe.
Windows users don't venture into the services area. PC technicians don't
either.

On Tue, Nov 29, 2016 at 3:23 PM, Elazar Leibovich <elazarl at gmail.com> wrote:

> Thanks,
>
> Even if it's up by default, which seems to be the case at least for some
> Windows versions, I still want to know from people's experience, how common
> it is to have someone shut it down.
> Is it a good practice?
> Are organization do that as a security hardening measure?
> Etc.
>
> On Tue, Nov 29, 2016 at 3:21 PM, Shay Gover <govershay at gmail.com> wrote:
>
>> Once upon a time I was a Windows sysadmin. Anyway, there was a nice site,
>> called blackviper.com that listed windows services default state.
>> However it's appears it's down now. Maybe tomorrow it'll be up?
>>
>> Shay
>>
>> On Tue, Nov 29, 2016 at 8:41 AM, Elazar Leibovich <elazarl at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> It's really convenient that two Linux computers usuallly have mDNS
>>> installed by default.
>>> I can then do scp x moshe.local, to my friend's laptop.
>>>
>>> In order for that to work with Windows, one can enable Window's zeroconf
>>> standard, LLMNR. The easiest way is by configuring systemd-resolved to
>>> support LLMNR.
>>>
>>> Alas, when I did that, two Windows laptop I examined had LLMNR turned
>>> off. The owners were not sure why.
>>>
>>> Can anyone estimate why this happened?
>>>
>>> Is LLMNR really a good way to interop with Windows, or would half of the
>>> Windows machine would have it turned off?
>>>
>>> Anyone has experience with that?
>>>
>>> _______________________________________________
>>> Linux-il mailing list
>>> Linux-il at cs.huji.ac.il
>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161129/ce835840/attachment.html>