netdev - Re: [PATCH net 1/2] ipv4: igmp: use alarmtimer to prevent delayed reports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Jun 2018 16:44:37 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Tejaswi Tanikella <tejaswit@...eaurora.org>
Cc:     netdev@...r.kernel.org, f.fainelli@...il.com, davem@...emloft.net
Subject: Re: [PATCH net 1/2] ipv4: igmp: use alarmtimer to prevent delayed
 reports

> I'll try to explain my scenario. This was observed on a arm64 device.
> An application registers for a mcast group, and just listens to mcast
> packets. The connection is setup and mcast packets are being forwarded
> by the router. Multicast packets are sent out every few minutes.
> Not a very busy connection.
> 
> After some time the router sends out a IGMPv2 query. The max delay in
> the header is set to 10s. The system starts a timer to send out the
> response at 9s. But the device suspends and wakes up after 60s.
>
> The response is sent out 50s late.
> 
> ftrace logs with boottime trace_clock and my igmp_logs:
> 
> 4740693      kworker/0:3-395   [000] ..s2  4716.425695: igmp_log: skbaddr=ffffffc156fe6600 daddr=224.0.0.1, id=0, rc=4295217721
> 4740694      kworker/0:3-395   [000] d.s4  4716.425717: timer_start:timer=ffffffc217763140 function=igmp_timer_expire expires=4295218678 [timeout=957] flags=0x00000000
>         timer set for 9.57 seconds.  957 jiffies
> 
> < device suspends >
> 
> < wakes up after ~60s >
> 4781289           <idle>-0     [000] .ns2  4779.170886: timer_expire_entry: timer=ffffffc217763140 function=igmp_timer_expire now=4295218678
> 4781290           <idle>-0     [000] .ns2  4779.171045: igmp_log: skbaddr=ffffffc1559d0e00 daddr=227.226.228.225, id=0, rc=4295218678
> 
> Since the response was delayed, mcast packets are not forwarded by the
> router.

While it has been asleep, it has also been dropping any multicast
traffic in the stream. So it does not really matter it has left the
group. You were not receiving the packets anyway.

Thing about this from another angle. I have an NTP client running on
my laptop, using multicast address 224.0.1.1. I suspend my laptop and
walk away for two hours. When i come back, i find that 20 seconds
after i suspended it, it resumed and send an group response
message. And an hour later, since it was still running, the battery
went flat.

It seems to me, the change you are proposing cannot be the default
behaviour.

I actually think you need to be looking at some sort of WoL feature.
You need the multicast stream data packets to wake you, and you also
need to wake up the IGMP query message. And you need to wake up to
send the group membership. Does your hardware have this sort of WoL
support? You can then explicitly enable this WoL for your application.

	Andrew