Send Motion-user mailing list submissions to
        motion-user@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
        motion-user-requ...@lists.sourceforge.net

You can reach the person managing the list at
        motion-user-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."


Today's Topics:

   1. Re: Negative impact on wifi connectivity (Richard Bown)
   2. Re: Negative impact on wifi connectivity (Damian)
   3. Re: Negative impact on wifi connectivity (Damian)
   4. Re: Negative impact on wifi connectivity (Dave Howorth)
   5. Re: Negative impact on wifi connectivity (Damian)
   6. Re: Negative impact on wifi connectivity (Damian)


----------------------------------------------------------------------

Message: 1
Date: Sun, 25 Oct 2020 14:25:30 +0000
From: Richard Bown <rich...@g8jvm.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <a7933946-8542-a745-f150-4f069a8bc...@g8jvm.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Try thinking outside of the box !

cause and effect.

you have seen the effect , you have the tools to find the cause.

If the wlan dies, find the last data that was sent and analyse it, and 
look at the motion logs, set logging at 7.

and at all the system logs, including syslog and kern.log, they are all 
timestamped .

take a print out of all the logs at the time of failure and read, its as 
the Meerkats say .


no more posts from me

GL

Richard

On 25/10/2020 11:22, Damian via Motion-user wrote:
>> You are looking for the instance when motion is turned on, so tcpdump 
>> WILL show this up to the point your wlan goes down.
>
> How is this even relevant? The interface *stays* disassociated as long 
> as motion runs. The time period of *staying* disassociated correlates 
> strongly with motion still being run. I can shorten or widen this time 
> period arbitrarily.
>
> So I do not know what you expect to find in the dump. Are you 
> suggesting that motion is susceptible to some packet of death, which 
> makes the wifi interface disassociate?
>
>
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user

-- 
  Best wishes /73
  Richard Bown
  
  Email : rich...@g8jvm.com

  HTTP  :  http://www.g8jvm.com
  
  ######################################################################

  Ham Call: G8JVM . QRV: 50-432 MHz + Microwave
  Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
  QRV 6mtrs 200W, 4mtrs 150W, 2mtrs 300W, 70cms 200W,
  Microwave 1296MHz 110W, 2320MHz 100W, 5760MHz 10W & 10368MHz 5W
  OS: Linux Mint 20, on a Dell Inspiron 3580 laptop
  ######################################################################




------------------------------

Message: 2
Date: Sun, 25 Oct 2020 20:17:58 +0100
From: Damian <motion-u...@arcsin.de>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <5c26b065-de60-201d-031e-da8eaf855...@arcsin.de>
Content-Type: text/plain; charset=utf-8; format=flowed

> Try thinking outside of the box !
> 
> cause and effect.

You did not tell what you expected to see that could cause the issue, so these 
are just catch phrases.

> you have seen the effect , you have the tools to find the cause.

tcpdump is not one of those tools. I can start motion in an isolated network 
namespace which only has a private lo, nothing else. 
And guess what happens shortly after: The motion process disassociates an 
interface that is not even part of its network stack!

> root@z:~ iwconfig wlan0
> wlan0     IEEE 802.11  ESSID:"XXXXXXXXXXXX"  
>           Mode:Managed  Frequency:2.462 GHz  Access Point: XX:XX:XX:XX:XX:XX  
>  
>           Bit Rate=24 Mb/s   Tx-Power=31 dBm   
>           Retry short limit:7   RTS thr:off   Fragment thr:off
>           Encryption key:off
>           Power Management:on
>           Link Quality=26/70  Signal level=-84 dBm  
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:2  Invalid misc:0   Missed beacon:0
> root@z:~ ip netns exec motion bash
> root@z:~ # inside fresh network namespace
> root@z:~ iwconfig 
> lo        no wireless extensions.
> root@z:~ ip a
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> root@z:~ tcpdump -ni lo
> tcpdump: lo: That device is not up
> root@z:~ sudo -u motion motion -m > /dev/null 2>&1 &
> [1] 15628
> root@z:~ exit
> root@z:~ # back in default network namespace                                  
>                                                                               
>                                                                               
>                                                             
> root@z:~ ps aux | grep motion
> root     15628  0.6  0.7  10240  3364 pts/0    S    20:00   0:00 sudo -u 
> motion motion -m
> motion   15644 52.6 16.3 240028 72312 pts/0    SLl  20:00   0:04 motion -m
> root     15653  0.0  0.4   7332  1828 pts/0    S+   20:01   0:00 grep motion
> root@z:~ # wait several seconds
> root@z:~ iwconfig wlan0
> wlan0     IEEE 802.11  ESSID:off/any  
>           Mode:Managed  Access Point: Not-Associated   Tx-Power=31 dBm
>           Retry short limit:7   RTS thr:off   Fragment thr:off
>           Encryption key:off
>           Power Management:on
> root@z:~ ping 8.8.8.8
> connect: Network is unreachable
If I thought this to be a pure software issue that can be triggered by some 
tcpdump-able packets I would have posted this on LKML 
instead.

> no more posts from me

Right, thank you for trying though.



------------------------------

Message: 3
Date: Sun, 25 Oct 2020 21:53:56 +0100
From: Damian <motion-u...@arcsin.de>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <e46ad382-2992-652d-b3ea-0fbb13c08...@arcsin.de>
Content-Type: text/plain; charset=utf-8; format=flowed

>> My main guess would be around interference to the wireless signal from
>> the camera or USB connection - poorly designed, poorly connected,
>> faulty cable - that type of thing. Or another possibility would be
>> power-supply borne crosstalk. If your supply is not a good quality one
>> with enough power it may be allowing the camera's power draw to
>> interfere with the wireless.
> 
> If this were so, then it would be very subtle. I can replace my motion's 
> current functionality by
> 
>> fswebcam -l 5 --save /my-tmpfs/%S.jpg -r 1920x1080 --exec 'mv 
>> /my-tmpfs/%S.jpg /my-tmpfs/lastsnap.jpg'
> No wifi disruptions then, and I can access lastsnap.jpg via nginx without 
> problems. I would like to stick with motion though, 
> because fswebcam's illumination correction is far from optimal.

The power draw hypothesis is still on the table. I just realized a subtle 
difference between motion and fswebcam.

motion opens the video device, issues an VIDIOC_STREAMON ioctl request on 
startup and keeps it this way until termination, where 
it issues VIDIOC_STREAMOFF and closes the device.

fswebcam however opens the video device, issues VIDIOC_STREAMON, captures a 
frame, closes the device, sleeps, and starts all over.

So if a VIDIOC_STREAMON is responsible for an increased power draw, the draw is 
constantly present while motion is running, while 
fswebcam only produces spikes now and then. So maybe in between those spikes 
the wifi can continue to work, while with motion it 
cannot.



------------------------------

Message: 4
Date: Sun, 25 Oct 2020 21:05:11 +0000
From: Dave Howorth <d...@howorth.org.uk>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <20201025210511.2c9f7...@acer-suse.lan>
Content-Type: text/plain; charset=US-ASCII

On Sun, 25 Oct 2020 10:29:55 +0100
Damian via Motion-user <motion-user@lists.sourceforge.net> wrote:

> > As well as swapping parts around, it might
> > be worth testing using the other pi.  
> 
> I had the same issue with another Zero W which I then swapped with a
> Pi-3 which was closer to the AP at that time.

What you don't say is whether the pi3 suffered the same problem or not?
And/or whether the relative position of the computers is/was actually
relevant?

> > My main guess would be around interference to the wireless signal
> > from the camera or USB connection - poorly designed, poorly
> > connected, faulty cable - that type of thing. Or another
> > possibility would be power-supply borne crosstalk. If your supply
> > is not a good quality one with enough power it may be allowing the
> > camera's power draw to interfere with the wireless.  
> 
> If this were so, then it would be very subtle. I can replace my
> motion's current functionality by
> 
> > fswebcam -l 5 --save /my-tmpfs/%S.jpg -r 1920x1080 --exec
> > 'mv /my-tmpfs/%S.jpg /my-tmpfs/lastsnap.jpg'  
> No wifi disruptions then, and I can access lastsnap.jpg via nginx
> without problems. I would like to stick with motion though, because
> fswebcam's illumination correction is far from optimal.

Well I know next to nothing about motion's internals and I've never
even heard of fswebcam, so I've no idea what the difference implies.

I do note that you haven't responded to my and Tosiara's suggestion to
change the power supply though. Have you done that?

And MrDave is a key developer. You haven't responded to his suggestion
either. Doing so might be a good way to solicit extra help.

I will also note that your posts haven't produced anybody else who's
experienced similar symptoms, so it seems likely that whatever your
problem is it is particular to your specific hardware and software
configuration. Maybe providing a detailed inventory will prompt a
response from somebody?



------------------------------

Message: 5
Date: Sun, 25 Oct 2020 22:36:12 +0100
From: Damian <motion-u...@arcsin.de>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <739ae755-652b-5b45-bad9-2feb6a21d...@arcsin.de>
Content-Type: text/plain; charset=utf-8; format=flowed

> The webcontrol and stream are implemented in Motion using the libmicrohttpd 
> library.? You can deactivate it from being started by 
> specifying the webcontrol_port and stream_port to zero.? This would at least 
> help in identification of whether it in that library 
> or if it is with opening of the USB camera.

Deactivated them now, the issue still exists.



------------------------------

Message: 6
Date: Sun, 25 Oct 2020 22:57:40 +0100
From: Damian <motion-u...@arcsin.de>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <972d23a0-d210-f29f-38dc-403868f00...@arcsin.de>
Content-Type: text/plain; charset=utf-8; format=flowed

> What you don't say is whether the pi3 suffered the same problem or not?

No, the Pi3 does not have the issue, at least not at the spot the Zero has been 
previously.

> And/or whether the relative position of the computers is/was actually
> relevant?

In principle every physical constellation can be relevant to the overall wifi 
reception. The key is that some unprivileged 
software can influence the reception to the worse.

> Well I know next to nothing about motion's internals and I've never
> even heard of fswebcam, so I've no idea what the difference implies.

I replied to your power draw hypothesis a few minutes before, and I think it is 
plausible.

> I do note that you haven't responded to my and Tosiara's suggestion to
> change the power supply though. Have you done that?

I cannot, I am far away.

> And MrDave is a key developer. You haven't responded to his suggestion
> either. Doing so might be a good way to solicit extra help.

Did now.

> I will also note that your posts haven't produced anybody else who's
> experienced similar symptoms, so it seems likely that whatever your
> problem is it is particular to your specific hardware and software
> configuration. Maybe providing a detailed inventory will prompt a
> response from somebody?

Yes, as I wrote to Richard Bown, this cannot be a software-only issue. If it 
were, the impact would be huge. I'll see if I can 
manage to build a small executable which keeps the camera on continuous 
VIDIOC_STREAMON as does motion.

Thanks



------------------------------



------------------------------

Subject: Digest Footer

_______________________________________________
Motion-user mailing list
Motion-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/motion-user


------------------------------

End of Motion-user Digest, Vol 172, Issue 16
********************************************

Reply via email to