On 06/14/2019 06:11 PM, Allen Wilkinson wrote:

I use ZM version 1.30.4 on Leap 15.0,  20 1280x780 pixel 10 fps IP cameras outdoors, 2 Gbps bonded network port. All works very well. Biggest challenge is dancing shadows of leafed out trees giving false triggers of motion clips. If anyone has solved that problem, I'd be glad to know. ZM help is rich with help, even talking about dancing shadows. But no guidance given works well.

Chuckling... Doesn't AI solve everything now? Since it is apparently good enough to do facial scans and be able to determine your propensity to commit crimes and your level of depression from a simple capture, surely it knows what a leaf is and can discriminate between shadows :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 6/14/19 6:11 PM, Allen Wilkinson wrote:

I use ZM version 1.30.4 on Leap 15.0,  20 1280x780 pixel 10 fps IP cameras outdoors, 2 Gbps bonded network port. All works very well. Biggest challenge is dancing shadows of leafed out trees giving false triggers of motion clips. If anyone has solved that problem, I'd be glad to know. ZM help is rich with help, even talking about dancing shadows. But no guidance given works well.

Allen Wilkinson

Video surveillance is my day job and most of the newer systems include some type of AI anti-falsing code to address that issue. Some work better than others. ZM is ok and free but like most things in life, you get what you pay for. Fred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 16/06/2019 21.08, Dave Howorth wrote:

On Sun, 16 Jun 2019 13:18:08 -0500 Stevens wrote:

These days when I look at reviews of consumer products in this area, they all seem to concentrate on the apps and the cloud storage, neither of which I need or want. Indeed stopping IoT devices from phoning home is something I'm trying to learn about. If you know of any good products that include proprietary algorithms, I'm open to ideas.

The only IoT gadget I own doesn't phone home till it gets an account. Ie, till I register it. Which means, the phone applet can not connect to it without registration. But there is no problem controlling it with a computer inside the LAN, which is perferct. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 17/06/2019 00.28, Dave Howorth wrote:

On Sun, 16 Jun 2019 22:41:08 +0200 "Carlos E. R." <> wrote:

...

On 16/06/2019 21.08, Dave Howorth wrote:

...

On Sun, 16 Jun 2019 13:18:08 -0500 Stevens <> wrote:

...

These days when I look at reviews of consumer products in this area, they all seem to concentrate on the apps and the cloud storage, neither of which I need or want. Indeed stopping IoT devices from phoning home is something I'm trying to learn about. If you know of any good products that include proprietary algorithms, I'm open to ideas.

The only IoT gadget I own doesn't phone home till it gets an account. Ie, till I register it. Which means, the phone applet can not connect to it without registration. But there is no problem controlling it with a computer inside the LAN, which is perferct.

Well that's a nice well-behaved IoT-bot then. But how can you know that in advance (if you don't trust the supplier) or deal with devices that are known to phone home?

It is mostly an educated guess on my part: their server can not store the data my gadget may send because it doesn't know where to store it, without an account name (well, they might use a serial number, but they wouldn't know the person, only approximate location). I think they mention this on the instructions. And of course, there is no way for an application on the phone to contact my gadget (and only my gadget) till it knows the account outside to contact. This is true for any gadget that says can be controlled from anywhere, inside or outside the house. Maybe with IPv6 the need for an external intermediate server could be obviated. It needs careful reading of the specifications before purchase to know if the gadget can be controlled from the LAN only without outside intervention. The Google Chromecast device bypasses some of this, using identification via bluetooth, I think. But it does need to know the account, later. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On Mon, 17 Jun 2019 13:10:32 -0500 Stevens wrote:

On 6/17/19 4:29 AM, Carlos E. R. wrote:

...

On 17/06/2019 00.28, Dave Howorth wrote:

...

On Sun, 16 Jun 2019 22:41:08 +0200 "Carlos E. R." <> wrote:

...

On 16/06/2019 21.08, Dave Howorth wrote:

...

On Sun, 16 Jun 2019 13:18:08 -0500 Stevens <> wrote:

...

These days when I look at reviews of consumer products in this area, they all seem to concentrate on the apps and the cloud storage, neither of which I need or want. Indeed stopping IoT devices from phoning home is something I'm trying to learn about. If you know of any good products that include proprietary algorithms, I'm open to ideas.

I never got an answer from anybody in this thread about any software or other technique for detecting and/or thwarting IoT devices that try to phone home without asking permission. Just for interest, here's an open-source project that enables exactly this kind of bad behaviour: https://www.dataplicity.com/ Held out as a good thing. o o ~

...

...

...

The only IoT gadget I own doesn't phone home till it gets an account. Ie, till I register it. Which means, the phone applet can not connect to it without registration. But there is no problem controlling it with a computer inside the LAN, which is perferct.

Well that's a nice well-behaved IoT-bot then. But how can you know that in advance (if you don't trust the supplier) or deal with devices that are known to phone home?

It is mostly an educated guess on my part: their server can not store the data my gadget may send because it doesn't know where to store it, without an account name (well, they might use a serial number, but they wouldn't know the person, only approximate location). I think they mention this on the instructions. And of course, there is no way for an application on the phone to contact my gadget (and only my gadget) till it knows the account outside to contact.

This is true for any gadget that says can be controlled from anywhere, inside or outside the house. Maybe with IPv6 the need for an external intermediate server could be obviated.

It needs careful reading of the specifications before purchase to know if the gadget can be controlled from the LAN only without outside intervention.

The Google Chromecast device bypasses some of this, using identification via bluetooth, I think. But it does need to know the account, later.

The NVR systems that I deal with aren't usually consumer grade - or priced - and although many use some form of DDNS and offsite (and off shore?) servers, others do not. One I installed recently allowed the programming of specific phone numbers so it could call and/or text alert messages. The LAN also can be configured with port forwarding with the dedicated port numbers for remote viewing. Using the DDNS server also lets you skip over the LAN configuration in case the client is overly paranoid (and ignorant) about remote access. As far as proprietary algorithms are concerned, most systems have those embedded in the NVR OS and each manufacturer has their own take on what is important. They are all in China and all are market driven (odd for a communist gov't to be controlling such a thriving capitalist system) so what is included now may not be around tomorrow.

(A side note about China, Inc. - I smile when thinking about how difficult it must be for central planners to control a system where the citizenry sees the gov't as just another cost of doing business in one of the most cutthroat market economies on the planet. Oh, yeah - off topic so don't reply on list!)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 24 Jun 2019 00:12:21 +0200 "Carlos E. R." wrote:

On 23/06/2019 16.05, Dave Howorth wrote:

...

I never got an answer from anybody in this thread about any software or other technique for detecting and/or thwarting IoT devices that try to phone home without asking permission.

If you are interested in that, you should ask a question about that, with an appropriate subject line ;-)

I don't think it is possible, if they work hard at going out... At least not easy.

You need an egress firewall, placed at the gateway to internet or at the WiFi Access Point. SuSEfirewall ain't that. It has to block outgoing connections coming from the IP of the IoT gadget in particular, and you have to know it, and fix it using DHCP.

I think I've got the first half of a solution. I just upgraded my internet connection (to a measurable fraction of yours) and part of the upgrade was a new router. It's a Fritz!Box 7530 and it appears it has parental controls that allow me to block devices from the internet. When a new device is added to the network, it is automatically allocated to the 'Standard' profile, so I just changed that to block all internet traffic. I moved all my existing devices that need internet to an 'Unrestricted' profile and left some devices, like my data logger, on Standard. It seems to work. My PC can still acess the web, and my data logger gets 'packet filtered' reports if I try to ping an external host. So that should stop things phoning home. Now I need to figure the best way to see what they're trying to do. Presumably wireshark or somesuch can do that?

That's what I can think about, without reading the link below.

Or, you can configure for them an special AP that has no connection to internet. No route. At worst, no cable.

...

Just for interest, here's an open-source project that enables exactly this kind of bad behaviour: https://www.dataplicity.com/ Held out as a good thing. o o ~

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 24 Jun 2019 18:44:58 +0200 "Carlos E. R." wrote:

On 24/06/2019 17.32, Dave Howorth wrote:

...

On Mon, 24 Jun 2019 00:12:21 +0200 "Carlos E. R." <> wrote:

...

On 23/06/2019 16.05, Dave Howorth wrote:

...

I never got an answer from anybody in this thread about any software or other technique for detecting and/or thwarting IoT devices that try to phone home without asking permission.

If you are interested in that, you should ask a question about that, with an appropriate subject line ;-)

I don't think it is possible, if they work hard at going out... At least not easy.

You need an egress firewall, placed at the gateway to internet or at the WiFi Access Point. SuSEfirewall ain't that. It has to block outgoing connections coming from the IP of the IoT gadget in particular, and you have to know it, and fix it using DHCP.

I think I've got the first half of a solution. I just upgraded my internet connection (to a measurable fraction of yours) and part of the upgrade was a new router. It's a Fritz!Box 7530 and it appears it has parental controls that allow me to block devices from the internet. When a new device is added to the network, it is automatically allocated to the 'Standard' profile, so I just changed that to block all internet traffic. I moved all my existing devices that need internet to an 'Unrestricted' profile and left some devices, like my data logger, on Standard.

It seems to work. My PC can still acess the web, and my data logger gets 'packet filtered' reports if I try to ping an external host.

Not even your guests

Well, the router offers two SSIDs - the standard one and a 'guest' one. The guest one has a different profile, that allows connection to the internet but not to my home network. So when friends connect, I will tell them to connect to that network and they will be fine. If/when I buy an IoT device I will have to tell it which SSID to connect to, and I will tell it to use the standard one, and they will be blocked from internet access.

...

So that should stop things phoning home.

I think so, unless they use some "clever" trick I can't think about.

For instance, an evil someone could listen to the traffic, see an IP that is authorized to get out, and when that IP is not running, pose as it.

I don't know what happens if a device tries to spoof an IP address. I'll ask them if I can't find an answer in the docs.

...

Now I need to figure the best way to see what they're trying to do. Presumably wireshark or somesuch can do that?

Yes.

I'll have to have a bit of a play to see how it works then :)

And others, like iptop, can tell a bit.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 25/06/2019 15.34, Dave Howorth wrote:

On Mon, 24 Jun 2019 18:44:58 +0200 "Carlos E. R." <> wrote:

...

...

...

So that should stop things phoning home.

I think so, unless they use some "clever" trick I can't think about.

For instance, an evil someone could listen to the traffic, see an IP that is authorized to get out, and when that IP is not running, pose as it.

I don't know what happens if a device tries to spoof an IP address. I'll ask them if I can't find an answer in the docs.

Them who? :-? In the scenario I related, as the "bad thing" uses that IP when it sees the machine that owns it is off the LAN, it would probably achieve its goal. You would not be able to stop it. It might spoof both the IP and the MAC. Perhaps by using a proxy and some authorization method. Of course, when the correct machine goes back on the LAN there would be problems. The router would see the collision. But so might the rogue device, which would then go back to the correct MAC/IP to avoid corrective action. Detecting the collision when an isolating switch is used might not be possible by the clients, because they don't see the full traffic, only their own. On WiFi things may be different, I'm unsure. And of course, the router might try to tell the clients that there is a collision (how, I do not know for sure), or it might close the port (the cable) connected to one of the two or both. If the router knows the rogue machine is on DHCP, it would try to assign another IP. You would see nothing, only that when the good machine connects again DHCP would simply give it another address. The problem would be if the bad machine also spoofs the MAC. But I'm not a "bad hacker", this is not my stuff ;-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Dave Howorth wrote:

Ah, I hadn't realized how easy it is to spoof a MAC address. When did that happen? How did I miss it? (the last is rhetorical of course) :)

Some network cards have had it forever. Sun Happy-Meal cards for instance. TMK, it doesn't work in general, the hardware has to support it. -- Per Jessen, Zürich (33.4°C) member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2019-06-25 11:59 AM, Dave Howorth wrote:

...

Some network cards have had it forever. Sun Happy-Meal cards for instance. TMK, it doesn't work in general, the hardware has to support it. Ah, after my time then. Ethernet was bee sting transducers and the very earliest UTP interfaces came out all at 10 Mbps when I was using Suns. I remember there was some special card for HA machines to allow hot standby but the god-given rule was generally MACs are for life, and the manufacturer prefix was jealously guarded.

As far as I know, locally assigned MACs have always been around, but cloning is more recent.  The difference is that LAAs are supposed to set a bit (2 IIRC), whereas cloning does not set that bit. Then again, with the old ARCnet cards, the 8 bit MAC was always manually configured with switches or jumpers.  ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 25/06/2019 à 19:20, Per Jessen a écrit :

With the Sun HMA, you specify the MACs when the driver is loaded :-) If

I had SUN pizza boxes with plain zero mac (to be setup later), sure a mess on the network :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 25/06/2019 16.44, Dave Howorth wrote:

On Tue, 25 Jun 2019 16:12:45 +0200 "Carlos E. R." wrote:

...

On 25/06/2019 15.34, Dave Howorth wrote:

...

On Mon, 24 Jun 2019 18:44:58 +0200 "Carlos E. R." <> wrote:

...

...

...

...

So that should stop things phoning home.

I think so, unless they use some "clever" trick I can't think about.

For instance, an evil someone could listen to the traffic, see an IP that is authorized to get out, and when that IP is not running, pose as it.

I don't know what happens if a device tries to spoof an IP address. I'll ask them if I can't find an answer in the docs.

Them who? :-?

AVM

¿the router manufacturer? Just force two machines (even two virtual ones) to the same IP and watch the router log. Possibly also watch traffic on both machines with wireshark.

...

In the scenario I related, as the "bad thing" uses that IP when it sees the machine that owns it is off the LAN, it would probably achieve its goal. You would not be able to stop it. It might spoof both the IP and the MAC. Perhaps by using a proxy and some authorization method.

Ah, I hadn't realized how easy it is to spoof a MAC address. When did that happen? How did I miss it? (the last is rhetorical of course) :)

Long ago. MsDOS. Apparently there were good reasons to support it - maybe to replace the card on a machine that connected on a corporate network that authorized only the known MAC. I'm not sure if I ever used the feature on real machines. On virtual machines, yes, often. Each time I replicate a machine, for instance.

...

Of course, when the correct machine goes back on the LAN there would be problems. The router would see the collision. But so might the rogue device, which would then go back to the correct MAC/IP to avoid corrective action.

Detecting the collision when an isolating switch is used might not be possible by the clients, because they don't see the full traffic, only their own. On WiFi things may be different, I'm unsure. And of course, the router might try to tell the clients that there is a collision (how, I do not know for sure), or it might close the port (the cable) connected to one of the two or both.

If the router knows the rogue machine is on DHCP, it would try to assign another IP. You would see nothing, only that when the good machine connects again DHCP would simply give it another address. The problem would be if the bad machine also spoofs the MAC.

I tend to assign static IP addresses on the LAN so something might notice. I asked AVM what was logged in such circumstances.

...

But I'm not a "bad hacker", this is not my stuff ;-)

Evidently more of a hacker than me ;)

But I invented all the above, I have not read it up. They would know every trick and strategy and counter. Surely they can invent more. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Quoting David C. Rankin : [snip]

The scumbags phoning home have an interest in obscuring the data and until the data exposes some embarrassing facts for some politician costing them an election, I doubt there will be any real push to curtail the problem. (for God sakes, in the US, they are just now trying to tackle the robo-calls that have rendered land-line telephone service more of an annoyance than a useful service)

Robo-calls are not limited to land-lines. They outnumber personal calls by at least 2 to 1. If I or my phone don't recognize the number, I don't answer. Just my 0.02USD, Jeffrey -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

...

...

...

...

...

> storage, neither of which I need or want. Indeed stopping IoT > devices from phoning home

what I understand in the sentence is preventing IOT phoning *to* home, not *from* home. what is the real question? thanks jhdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 24/06/2019 à 16:09, Dave Howorth a écrit :

On Mon, 24 Jun 2019 11:17:59 +0200 "jdd@dodin.org" wrote:

...

...

...

...

...

>>> storage, neither of which I need or want. Indeed stopping IoT >>> devices from phoning home

what I understand in the sentence is preventing IOT phoning *to* home, not *from* home.

the expression is an English idiom, well-described in https://en.wikipedia.org/wiki/Phoning_home and illustrated more simply at https://en.wiktionary.org/wiki/phone_home

...

what is the real question?

exactly. I get the impression that the discussion speaks the contrary jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/06/2019 17.12, jdd@dodin.org wrote:

Le 24/06/2019 à 16:09, Dave Howorth a écrit :

...

On Mon, 24 Jun 2019 11:17:59 +0200 "jdd@dodin.org" wrote:

...

...

...

...

>>>> storage, neither of which I need or want. Indeed stopping IoT >>>> devices from phoning home

what I understand in the sentence  is preventing IOT phoning *to* home, not *from* home.

the expression is an English idiom, well-described in https://en.wikipedia.org/wiki/Phoning_home and illustrated more simply at https://en.wiktionary.org/wiki/phone_home

...

what is the real question?

exactly. I get the impression that the discussion speaks the contrary

No, these things always phone out, phone home, because normally all firewalls permit going out to Internet. For example, assume a power strip, that can power up or down appliances at home, using an Android phone/tabled (for example). Steps: 1) Register the device on a web page. 2) Install application on phone, with that registration. 1&2 could be the same steop. 3) The application searches and finds the device on the local network, and writes the registration data on the power strip. Possibly locks it down with a password from now on. The result now is that the phone can control the power strip, not only at home, but anywhere. It does this by contacting a server on internet with the registered login/password, and telling it the actions to do. The power strip also initiates a connection to internet to this same server. Say it keeps a web page open there, under the registration login/pass. When the application sends an action to do, the power strip (the IoT thing) sees the change and act. There is no direct communication from the smartphone to the gadget. This trick works with default configuration of the firewall, because all participants call out. In this scenario there is no evil. But of course, there can be: the gadget action can be logged. This of itself is not evil, it can be a feature so that the user knows the action done. But some other person could access that log for whatever. Then the gadget can be evil because it contains, say, a microphone, and periodically sends what it hears. Notice that such a gadget can log and send data from day one even without being registered, but the bad guys do not know exactly where it is installed, who it belongs to. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)