Announcement

Collapse
No announcement yet.

Flaky SolarEdge Ethernet?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by ButchDeal View Post

    Just because you havent doesnt mean that others, perhaos others with more exoerience in lan work havent. I didnt say it was a security feature, i said it was buggy code, yu lept to that assumption.

    In any case the double NAT/ DHCP is most likely the issue. I have seen that repeatedly.

    It sounds like you didnt inderstand that sentance to me.

    I also have considerable eperience with networking equipment, way more than with solar equipment.
    How does buggy DHCP prevent the NAT from translating your packets? A buggy DHCP should, at worst, double-lease IPs or not renew them properly, or at all.

    Breaking down your sentence, I gather the following info:

    "Static addresses work as it does its own arp table updates"; true, the arp table on the router can get updates from the DHCP leases or by just picking-up the broadcast arp messages from an unknown client (which a static IP client would be until it's first traffic to the gateway).

    "and all the traffic is outbound,"; using NAT without any port forwarding or DMZ enabled, this is a requirement, though it should be "all traffic should be *originated* from the internal subnet", but once a TCP connection is made, or once a UDP packet is sent to a remote host then inbound traffic can commence.

    "The arp table updates are broadcast and the router updates its NAT table based on them."; the first part is correct, but NAT tables aren't updated by arp broadcasts. These get updated once a non-local subnet packet is received from an internal IP address. There's no need to update the NAT table until a packet from an internal host is sent to the gateway to be routed to an external host, and at that point it will cache the MAC/IP of the internal host so it knows where to send the response from the remote host.

    I guess the point is... routers may not intentionally block internally generated traffic from static hosts, but some might just because their firmware is crap. I'll agree with that.
    https://pvoutput.org/list.jsp?sid=54099

    Comment


    • #17
      Originally posted by NukeEngineer View Post

      How does buggy DHCP prevent the NAT from translating your packets? A buggy DHCP should, at worst, double-lease IPs or not renew them properly, or at all.

      Breaking down your sentence, I gather the following info:

      "Static addresses work as it does its own arp table updates"; true, the arp table on the router can get updates from the DHCP leases or by just picking-up the broadcast arp messages from an unknown client (which a static IP client would be until it's first traffic to the gateway).

      "and all the traffic is outbound,"; using NAT without any port forwarding or DMZ enabled, this is a requirement, though it should be "all traffic should be *originated* from the internal subnet", but once a TCP connection is made, or once a UDP packet is sent to a remote host then inbound traffic can commence.

      "The arp table updates are broadcast and the router updates its NAT table based on them."; the first part is correct, but NAT tables aren't updated by arp broadcasts. These get updated once a non-local subnet packet is received from an internal IP address. There's no need to update the NAT table until a packet from an internal host is sent to the gateway to be routed to an external host, and at that point it will cache the MAC/IP of the internal host so it knows where to send the response from the remote host.

      I guess the point is... routers may not intentionally block internally generated traffic from static hosts, but some might just because their firmware is crap. I'll agree with that.
      some cheap devices use a combination of DHCP and ARP tables for the NAT. If it is in DHCP but not complete (the bug) then the NAT doesn't work....

      When you have TWO devices as is the case for OP with a wireless gateway then you have two devices doing DHCP/NAT There are many bugs that can pop up one is that the two devices reduce the size of the packets (poor implementation of nature of NAT), doing it twice reduces it more, but often the internet router is hard coded to the size it allows instead of calculating the reduction on top of the other reduction. This causes random missed packets.
      The other bugs are around the DHCP/ARP protocols and NAT tricks of the one device all working together to keep the internet router from fully registering the address of the gateway devices. Sometimes you can put the wireless gateway into bridge mode instead of NAT and things will work much better but many of them are not configurable.
      Another common problem is a leaky gateway device which leaks some packets through but NATs the rest. This very much confuses the (and rightfully so) the external router.
      Last edited by ButchDeal; 07-31-2018, 01:52 PM.
      OutBack FP1 w/ CS6P-250P http://bit.ly/1Sg5VNH

      Comment


      • #18
        If his wireless bridge is performing NAT of it's own, then he needs to configure it into pure bridge mode, layer 1 only. No need to NAT into your own internal network.

        Still, though, if he would set static IPs on the inverter(s), I'm pretty sure his issues will go away.
        https://pvoutput.org/list.jsp?sid=54099

        Comment


        • #19
          Originally posted by NukeEngineer View Post
          If his wireless bridge is performing NAT of it's own, then he needs to configure it into pure bridge mode, layer 1 only. No need to NAT into your own internal network.

          Still, though, if he would set static IPs on the inverter(s), I'm pretty sure his issues will go away.
          I agree it is likely to go away with a static IP, but it is just as likely to go away and have better reliability if he removes the wireless gateway. granted that involves pulling a cat 5 wire to the inverter.
          OutBack FP1 w/ CS6P-250P http://bit.ly/1Sg5VNH

          Comment


          • #20
            Well, one other option would be to temporarily run a <300 ft (~90M) ethernet cable between your router and the inverter and see if the problem goes away. Amazon has several (from reputable vendors) in the $15-40 range.

            But, given that the inverter caches some of the data anyway, I would think that if it were the bridge or router acting up, power cycling them (and not the inverter) should restore the connection. If data upload only resumes following an inverter restart (or when it cools off) then it would seems like something internal to the inverter.

            Comment


            • #21
              Also, call or chat with SolarEdge and request the latest firmware. That may fix it as well.
              https://pvoutput.org/list.jsp?sid=54099

              Comment


              • #22
                So, last night I was just about to post back that the issue had once again mysteriously disappeared and I was getting consistent data Good thing I didn't because I once again had a dropout today starting at 1:55pm and I got my email notification from SE

                However, I tried something different tonight. I just started pinging the IP address of the inverter (known IP due to reservation in router). The first few pings failed and then it magically sprung to life..... Shortly afterwards I noticed that all my data was present on PVOutput. I'm not quite sure what to make of that

                It does kinda feel like something is timing out on the network (ARP table or something), but I can't say I've seen this type of phenomenon before anywhere. If it was failing to get an IP address, the ping never would have worked. Certainly the ping initiated an ARP request to the router (since it's the gateway and I was crossing VLANs and therefore subnets) and then from the router to the inverter

                FYI - I have quite a bit of networking experience and my network is not composed of simple consumer stuff. I'm running a Ubiquiti Edgerouter for my main router/firewall and it takes care of all DHCP/NAT/Firewall duties (as well as my VPN). I'm also running a managed switch with 7 VLANs running around the house to segregate things like Home Automation (IoT), A/V, Security Cameras, etc. The Edgerouter takes care of inter-VLAN routing. It's more or less a router on a stick design. Most of my stuff is running over the Cat6 I installed throughout the house. Once it cools down a bit and I can actually safely be in my attic, I'll run another Cat6 line to connect the inverter directly instead of the bridge. Just kind of a circuitous route due to where I have pull lines and where the existing line is

                Comment


                • #23
                  Trust me, run a static IP on the inverter. Not a DHCP assigned static IP, but an actual static IP. I had the exact same issue as you, with Ethernet to each inverter, and it went away with the static IP.


                  ​​​​​​It'll save you a wire pull.
                  https://pvoutput.org/list.jsp?sid=54099

                  Comment


                  • #24
                    Thanks. I'll have to wait for an evening before the sun is completely down so I can deenergize and pull the cover off to get to the internal buttons

                    Comment


                    • #25
                      Opened up the inverter this evening and set the static address. Now I'll just wait to see how it behaves over the long run

                      Comment


                      • #26
                        Originally posted by jasonvr View Post
                        Opened up the inverter this evening and set the static address. Now I'll just wait to see how it behaves over the long run
                        How's it running now?
                        https://pvoutput.org/list.jsp?sid=54099

                        Comment


                        • #27
                          Originally posted by NukeEngineer View Post

                          How's it running now?
                          Haven't seen any issues at this point, but since it was totally random in the first place I'll never know if it is truly fixed. Maybe if I go a year with no issues it'll be definitive

                          Comment


                          • #28
                            Well, I unfortunately think the issue is back. Last week I got a notification that I was missing data. I started a ping to the static IP of the inverter and initially got no response and then it once again sprung to life. A couple hours later I got a notification that data had been restored. Unfortunately I wasn't home (ping was done over my VPN), so I didn't have physical access to the inverter.

                            Then, I got another notification today. Once again, I started a ping and got no response and then it sprung to life. I started a wireshark capture on the router and saw the pings but no other traffic. I then went to the inverter and hit the button until it got to the LAN test. It got thru the first 3 tests and then started failing on pings. Looking at the wireshark capture, no packets were ever sent. So I did a safe shutdown of the inverter (really cloudy day anyways so I wasn't producing much). After reboot the inverter immediately passed all the LAN tests and I saw packets going out in the wireshark capture. First a DNS query and then packets out to the address that had been queried for.

                            So, I'm pretty convinced that something in the inverter periodically just get's stuck or maybe the network stack goes belly up and needs a hard reboot to get going again reliably.

                            Comment


                            • #29
                              Same problem; even with static IPs. Inverter loses connection after power outage and produces errors like "No lan connection" or "tcp connect fail" even though I can ping the inverter successfully from a pc on the lan. Restarting the inverter fixes it. Toggle switch off, rotary switch off, circuit breakers off; then back on and voila, instant connection.

                              Comment

                              Working...
                              X