xSchedule Internet Usage

[RStack76]

Hello!

First off - props to the dev's!  Love using XLights.  Thank you for all your continued efforts.

I am using the latest release on the 32-bit platform (v2020.44).  It would seem that while the xSchedule application is open it is uploading a consistent data stream of 2.3Mbps to somewhere.   I haven't gone as far as running wireshark to get an exact look at the network traffic, but I can say that when I closed the xSchedule application the stream dropped almost instantly so I'm pretty confident that the events are linked.

Unfortunately I have a monthly data cap so I have to watch these things.

Any insight, or is there a setting that perhaps I didn't notice, to stop xSchedule from communicating over the WAN?

Thank you!

[nmiller0113]

Where are you measuring the usage and how do you know it is internet destined? Sounds like it's broadcasting starting to stream data/broadcasting across your network, but 2.3Mbps seems like a bit much. Just my first thought.

[RStack76]

I'm going off what my router is showing me.  It has the ability to tell me on the amount of outbound & inbound traffic device connected to it in live time.

I did a bunch of poking at this tonight.  Switched to a refreshed PC that has Win7 64-bit so I can jump to the latest release of XLigjts to see if that made any difference.  Interestingly, it seems the amount of outbound traffic actually went up to about 4.0Mbps which I agree is a bit too high.  Just a little bit...  ;-)

Using Wireshark I can see that when I start xSchedule it does broadcast traffic on the network.  It seems this is related to the option on xSchedule - "send data when not running sequence" is checked and my "output to lights" is enabled.  As far as I know, this has not been an issue in the past.  If I uncheck the option to "send data when not running sequence" and enable the light output I then do not see any outbound traffic on the WAN.

Only thing I don't know is the why it is registering as outbound traffic to the WAN actually making it out of the router even if it has an invalid destination.  I do have two separate NIC adapters on my PC that runs xLights.  One adapter to connect to my network and the internet, and another that has a completely different IP/subnet that aligns with my pixel network.  The networks are separated, but some how when that option to send data when not running sequence is sending data on both NIC adapters. 

Does this make sense?  Is there (or could there be) a way to tell xSchedule to send data on a selected adapter?  Perhaps in the options menu?  I do see the drop down menu under options that says "Force Local IP", but it only lists the one adapter that is connected to my WAN and not the adapter that is to my pixel network.

Thanks for your time & attention

[keithsw1111]

If xSchedule is sending data to the internet then it is because the target IP domain you have configured is not present on the network and thus the computer sends it to the gateway which forwards it to the internet. Go to xLights and run check sequence and look for IP related errors. If there are none then review your network settings or pop into zoom and get a 2nd opinion. Something is not right with how you have set it up.

[nmiller0113]

I'm assuming your router is reading it as outbound based on the destination being considered something "off net" even though it is not forwarding it...routers don't route broadcasts. It's likely a processing order and your router UI displays it even if it never makes it past the local/incoming interface.

The broadcast going out all interfaces is normal behavior unless you bound the service to a specific interface. The Force Local IP option is the only thing I know of that can do that, but I'm not sure why it isn't showing both in the drop-down...does the interface for your show network not have an IP address?

[RStack76]

Finally figured it out.   Apparently I need to play the lottery because the odds would have to be really slim.

Short version - issue is resolved.

Long version -

Couple things I noted.  With the latest release or software when I go into options on scheduler and look under the "Force Local IP" drop down I now have both of my NIC adapters listed so I was able to pick the adapter that speaks to my pixel network and that seemed to resolve my outbound traffic issue.  I didn't read the readme so I'm not sure if that was an intentional fix, but either way it works now - THANK YOU!  :-)

What caused my issues in the first place is that my pixel network is on the 172.30.1.x/24 subnet.  One of my controllers had an address of 172.30.1.10.  Well, coincidentally, as a Mediacom subscriber, Mediacom apparently has a managed device on their network of the SAME address.  Something is wrong on their end because I shouldn't be able to ping an address on their network - it's very possible, but a huge security vulnerability for them.  What flagged it for me that scheduler kept saying one of my controllers was online when I knew it wasn't.   Did a trace route command on the address in question and sure enough after 6 different hops I was getting a reply from some other device on the WAN with that same IP address.  I changed it to a different address that is not reachable via WAN, reset Force Local IP back to nothing, and now I no longer have outbound traffic on my network.

As a techie - that is actually kind of funny.  :-)   End of the day - all is good!

Anyway - thank you for the time & the responses.   

[Gilrock]

Yes Force Local IP is meant to direct the traffic.  Some people had traffic going out wireless when they really wanted their wired adapter.  Most everyone uses the 192.168.x.x subnets and never has an issue.

[nmiller0113]

Finally figured it out.   Apparently I need to play the lottery because the odds would have to be really slim.

Short version - issue is resolved.

What caused my issues in the first place is that my pixel network is on the 172.30.1.x/24 subnet.  One of my controllers had an address of 172.30.1.10.  Well, coincidentally, as a Mediacom subscriber, Mediacom apparently has a managed device on their network of the SAME address.  Something is wrong on their end because I shouldn't be able to ping an address on their network - it's very possible, but a huge security vulnerability for them.  What flagged it for me that scheduler kept saying one of my controllers was online when I knew it wasn't.   Did a trace route command on the address in question and sure enough after 6 different hops I was getting a reply from some other device on the WAN with that same IP address.  I changed it to a different address that is not reachable via WAN, reset Force Local IP back to nothing, and now I no longer have outbound traffic on my network.

As a techie - that is actually kind of funny.  :-)   End of the day - all is good!

Anyway - thank you for the time & the responses.

Glad you got it working! Definitely an interesting story as to why you had outbound traffic

As for ping being allowed, not really a security risk, and a lot of providers allow it as a troubleshooting tool when customers have issues. If they were allowing more than ICMP echo requests then yeah...I'd actually run an nmap to see what really responds

You may also want to block external routing of RFC1918 space on your gateway.