Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multicast not responding to IGMP query #1165

Closed
madsci1016 opened this issue Dec 7, 2015 · 13 comments
Closed

Multicast not responding to IGMP query #1165

madsci1016 opened this issue Dec 7, 2015 · 13 comments
Assignees
Labels
component: network component: SDK type: bug waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.

Comments

@madsci1016
Copy link

madsci1016 commented Dec 7, 2015

I can't directly confirm this because I don't have the right wireless snooping equipment, but based on some tests i think it's a fair claim to say the ESP doesn't respond to IGMP query messages when using multicast mode.

My Christmas light display consists of a dozen ESP8266s driving pixels and dimmers in my front yard. Data is delivered via multicast from a computer on my wired network. For simplicity and traffic segregation i tried to isolate my Christmas lights onto a vLan and use layer 3 switches and routers in between my show computer, the AP and some wired light hardware. It would work, but only for a few minutes before suddenly all the ESPs in multicast mode would all stop receiving data. The few I have that use unicast would continue to work fine. Power cycling an ESP would get me another few minutes before stopping again. I can still access a web config on a dark ESP via http and ping it's normal ip address.

If i remove all the level 3 switches and swap them for dumb ones, everything works fine all night.

I can only conclude that my layer 3 switch waits until a timeout and send an IGMP query message to confirm members in a multicast group are still present on an interface. When it would get no replies, it would stop forwarding multicast data to that interface.

Firmware running on the ESP is here: https://github.com/madsci1016/ESPixelStick

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@igrr
Copy link
Member

igrr commented Dec 7, 2015

Which version of IGMP does your switch use?
Is there a way to reproduce this behaviour without extra equipment?
In theory, IGMP v2 should be supported by the underlying lwIP stack:
https://github.com/kadamski/esp-lwip/blob/esp8266-1.4.1/src/core/ipv4/igmp.c#L389
If it doesn't work for some reason, lwIP may be rebuilt with debug output enabled (LWIP_DEBUGF and IGMP_DEBUG), to see how queries are handled.

@madsci1016
Copy link
Author

Well the L3 switches are responding to the IGMPv2 messages they get initially from the ESPs, so I assume they are v2 or are at least backwards compatible. You can reproduce if you have a PC, and ESP and a L3 switch in between. You might be able to test IGMP messages to an ESP without a L3 switch by handcrafting IGMP packets and looking for a response. That's outside my area of expertise.

I still haven't been able to setup a test and capture an ignored query message, but I have timed the failure. It's exactly 4:20 from power up to data blackout, which is the default Group Membership Interval according to https://tools.ietf.org/html/rfc2236 It's got to be ignoring query messages or my 2 different brands on L3 devices just don't bother sending any. But they are name (ISP) brands, so I'd would image a problem that big would be noticed.

If I disable IGMP snopping the issue goes away, but it hammers my whole network with multicast traffic.

@devyte
Copy link
Collaborator

devyte commented Oct 19, 2017

@madsci1016 this issue is very old. Is it still valid with latest git?

@devyte
Copy link
Collaborator

devyte commented Oct 19, 2017

@d-a-v would this be something relevant to test between lwip 1.4 and lwip2?

@devyte devyte added the waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. label Oct 19, 2017
@bsz0206
Copy link

bsz0206 commented Dec 21, 2017

I am not really sure this is exactly the issue I saw but have a look at the comment on put on #1826

@d-a-v
Copy link
Collaborator

d-a-v commented Dec 21, 2017

@bsz0206 can you please elaborate ?
With what sketch and which version of core are you triggering the crash described in #1826 ?

@bsz0206
Copy link

bsz0206 commented Dec 21, 2017

It is on 2.3.0. I don't know more than this as I am not the developer of the device (https://github.com/OpenGarage/OpenGarage-Firmware).

@d-a-v
Copy link
Collaborator

d-a-v commented Dec 21, 2017

@bsz0206 Are you willing to test this and reproduce the bug with current master = latest git (which is post-2.4.0rc2) ?

@springile
Copy link

Is this issue closed ?

@bsz0206
Copy link

bsz0206 commented Jul 10, 2019 via email

@springile
Copy link

Hi

How did you fix it?

Thanks.

@springile
Copy link

I still have similar issue on using 2 networks cards in the same vlan in linux mint?

@earlephilhower
Copy link
Collaborator

Closing as original issue reported solved.

Yes, I don't experience it any more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: network component: SDK type: bug waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.
Projects
None yet
Development

No branches or pull requests

7 participants