-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Comments
Which version of IGMP does your switch use? |
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. |
@madsci1016 this issue is very old. Is it still valid with latest git? |
@d-a-v would this be something relevant to test between lwip 1.4 and lwip2? |
I am not really sure this is exactly the issue I saw but have a look at the comment on put on #1826 |
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). |
@bsz0206 Are you willing to test this and reproduce the bug with current master = latest git (which is post-2.4.0rc2) ? |
Is this issue closed ? |
Yes, I don't experience it any more.
…On Wed, Jul 10, 2019 at 12:49 PM heyufei2008 ***@***.***> wrote:
Is this issue closed ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1165?email_source=notifications&email_token=ACZ3SNWIBJGWRDV5Y3U5ZODP6Y4MFA5CNFSM4BV7LZZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZUREIQ#issuecomment-510202402>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACZ3SNTDMAULDAQMDW56THLP6Y4MFANCNFSM4BV7LZZA>
.
|
Hi How did you fix it? Thanks. |
I still have similar issue on using 2 networks cards in the same vlan in linux mint? |
Closing as original issue reported solved.
|
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.
The text was updated successfully, but these errors were encountered: