Schneider Combox installation triggers virus warnings

124

Comments

  • Estragon
    Estragon Registered Users Posts: 4,496 ✭✭✭✭✭
    Some context to my thinking...

    The issue occurs with both wireless and wired, suggesting it's likely not a hardware issue per se.

    With the same adapter in different machines, one of which works, it might be worth checking to see if the driver versions are identical. I doubt this is the issue, but worth checking on the remote chance the alienware uses some sort of tweaked version.

    Having tried two different routers, it's unlikely the router is mangling flow control in packets, but if they have any sort of QOS setting, it should be disabled for now.

    The devices are communicating, albeit with errors, so not likely a routing issue (bad subnetting, etc.). The ARP response suggests proper MAC address to IP address.

    You've run Win10pro okay on a non-alienware machine successfully, which suggests either it's not an OS level issue, or the alienware boxes are doing (or not doing) something different at that level.

    The "rules" around networking generally, and TCP in particular (the layer at which the issue appears to be), are done with RFCs (Request For Comments). The thing is, because of the history of internet development, these "rules" really aren't. They become "rules" only if and to the extent they get adopted in the real world. There's RFC1149
    https://tools.ietf.org/html/rfc1149
    "A Standard for the Transmission of IP Datagrams On Avian Carrier". This one wasn't widely adopted, being a suggested method for using carrier pigeons :smiley:

    The RFCs use terms like "Must", "Should", and "May" in describing various parts of a protocol. Companies can and do implement the protocol with minor differences, which often leads to good things, but sometimes to incompatibilities.

    I'll look into the combox sequence thing a bit more, but on it's face it's not surprising. The combox will have much less memory and processor resources than a full-on computer (eg. the small win=4096 in the SYN, ACK response). If ram buffers fill, for example, it can't take more until the queue gets processed. The TCP protocol has means to deal with this, but it's apparently not working properly in this case. When it goes wrong, the problem can compound exponentially. A well known denial of service attack exploits this.

    So that you see the sequence message on both computers isn't surprising. The issue is likely in how the alienware is responding. Using a human example, say I say "Hi there" to you just as a loud truck goes by. You could respond with "Can you repeat that", and the conversation goes from there. If instead, your reply was "Parlez vous francais?", and I don't speak french, we have a problem. I might repeat the Hi louder, and you might shout louder and more often, to the point one of us gives up and walks away. That's sort of what I think may be happening here.

    I believe the CWR in the AW(AlienWare) SYN packet suggests it doesn't see network congestion, and ECN offers a way of handling dropped packets that the combox may not support. Not necessarily the problem, but it could be if AW insists on using it.
    Off-grid.  
    Main daytime system ~4kw panels into 2xMNClassic150 370ah 48v bank 2xOutback 3548 inverter 120v + 240v autotransformer
    Night system ~1kw panels into 1xMNClassic150 700ah 12v bank morningstar 300w inverter
  • Dave Angelini
    Dave Angelini Solar Expert Posts: 6,730 ✭✭✭✭✭✭
    Has Dusty said he was sorry to Bill gates yet ;)  Might help
    "we go where power lines don't" Sierra Nevada mountain area
       htps://offgridsolar1.com/
    E-mail offgridsolar@sti.net

  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    Estragon said:
    Some context to my thinking...

    The issue occurs with both wireless and wired, suggesting it's likely not a hardware issue per se.

    With the same adapter in different machines, one of which works, it might be worth checking to see if the driver versions are identical. I doubt this is the issue, but worth checking on the remote chance the alienware uses some sort of tweaked version.

    Having tried two different routers, it's unlikely the router is mangling flow control in packets, but if they have any sort of QOS setting, it should be disabled for now.

    The devices are communicating, albeit with errors, so not likely a routing issue (bad subnetting, etc.). The ARP response suggests proper MAC address to IP address.

    You've run Win10pro okay on a non-alienware machine successfully, which suggests either it's not an OS level issue, or the alienware boxes are doing (or not doing) something different at that level.

    The "rules" around networking generally, and TCP in particular (the layer at which the issue appears to be), are done with RFCs (Request For Comments). The thing is, because of the history of internet development, these "rules" really aren't. They become "rules" only if and to the extent they get adopted in the real world. There's RFC1149
    https://tools.ietf.org/html/rfc1149
    "A Standard for the Transmission of IP Datagrams On Avian Carrier". This one wasn't widely adopted, being a suggested method for using carrier pigeons :smiley:

    The RFCs use terms like "Must", "Should", and "May" in describing various parts of a protocol. Companies can and do implement the protocol with minor differences, which often leads to good things, but sometimes to incompatibilities.

    I'll look into the combox sequence thing a bit more, but on it's face it's not surprising. The combox will have much less memory and processor resources than a full-on computer (eg. the small win=4096 in the SYN, ACK response). If ram buffers fill, for example, it can't take more until the queue gets processed. The TCP protocol has means to deal with this, but it's apparently not working properly in this case. When it goes wrong, the problem can compound exponentially. A well known denial of service attack exploits this.

    So that you see the sequence message on both computers isn't surprising. The issue is likely in how the alienware is responding. Using a human example, say I say "Hi there" to you just as a loud truck goes by. You could respond with "Can you repeat that", and the conversation goes from there. If instead, your reply was "Parlez vous francais?", and I don't speak french, we have a problem. I might repeat the Hi louder, and you might shout louder and more often, to the point one of us gives up and walks away. That's sort of what I think may be happening here.

    I believe the CWR in the AW(AlienWare) SYN packet suggests it doesn't see network congestion, and ECN offers a way of handling dropped packets that the combox may not support. Not necessarily the problem, but it could be if AW insists on using it.
    Yes, the Ethernet driver versions are the same.  Adapter: Killer E2200 Gigabit Ethernet Controller. Driver provider: Microsoft, Driver date: 9/14/2016, Driver Version: 9.0.0.42, Digital Signer: Microsoft Windows.

    I'm about ready to go back to Carrier Pidgeons!  Even if they are only half-duplex!  Ha ha.

    Thanks for the insight into what is going on. It's a little clearer, but I would think that identical adapter drivers and adapter settings in both machines (AW and MSI) would handshake similarly, if not identically.  But honestly, I'm not an IT guy, so I'm out of my depth.  Thanks again!


    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    Has Dusty said he was sorry to Bill gates yet ;)  Might help
    My Late Father worked for IBM for close to 30 years.  He would have disowned me if I ever said anything nice about Bill Gates.  He was really fuming over the demise of OS2 due to Microsoft's more successful marketing.
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • BB.
    BB. Super Moderators, Administrators Posts: 33,431 admin
    In decades past, checking/adjusting the maximum frame size (MTU) of the packets could fix things (too large of packet, and receiver would fail).

    https://en.wikipedia.org/wiki/IPv4#Data

    I don't remember enough to know if MTU could be a problem here... But given the possibility of a gaming computer doing anything it could to increase communications speed/efficiency, it could be a possible "hack" (large MTU, >1,500 bytes for example).

    -Bill
    Near San Francisco California: 3.5kWatt Grid Tied Solar power system+small backup genset
  • Dave Angelini
    Dave Angelini Solar Expert Posts: 6,730 ✭✭✭✭✭✭
    Just saying....Good Luck! I wish I could tell you what I am working on for Schneider. In the Fall maybe.
    "we go where power lines don't" Sierra Nevada mountain area
       htps://offgridsolar1.com/
    E-mail offgridsolar@sti.net

  • Estragon
    Estragon Registered Users Posts: 4,496 ✭✭✭✭✭
    The driver thing was a bit of a long shot, as I suspect the issue is (mainly) higher up the protocol stack. It's been more years than I care to admit since I've gotten into this level of detail with TCP though. Will have to read through some RFCs etc as there've been lots of newer additions/tweaks/hacks.

    Seems to me OS2 was widely used in bank machines, because it just worked (while MSDOS/Windoze needed a regular cold boot). Maybe some sort of *nix these days? My son gave me a t-shirt a few years back with a penguin (linux "Tux") holding a sword and a caption of "Kill Bill" :smile:
    Off-grid.  
    Main daytime system ~4kw panels into 2xMNClassic150 370ah 48v bank 2xOutback 3548 inverter 120v + 240v autotransformer
    Night system ~1kw panels into 1xMNClassic150 700ah 12v bank morningstar 300w inverter
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    edited August 2018 #99
    BB. said:
    In decades past, checking/adjusting the maximum frame size (MTU) of the packets could fix things (too large of packet, and receiver would fail).

    https://en.wikipedia.org/wiki/IPv4#Data

    I don't remember enough to know if MTU could be a problem here... But given the possibility of a gaming computer doing anything it could to increase communications speed/efficiency, it could be a possible "hack" (large MTU, >1,500 bytes for example).

    -Bill
    Thanks Bill.  Here's what the adapter settings are configured to on the MSI gaming laptop (and the Alienware's settings are identical):

    ARP Offload-Enabled
    ECMA-Disabled
    Energy Efficient Ethernet-Disabled
    Flow Control-Rx & Tx Enabled
    Interrupt Moderation-Enabled
    IPv4 Checksum Offload-Rx & Tx Enabled
    Jumbo Frame- Disabled
    Large Send Offload (IPv4)- Enabled
    Large Send Offoad v2 (IPv4)-Enabled
    Large Send Offload v2 (IPv6)-Enabled
    Max IRQ per Second-10000
    Max # of RSS Queues- 4
    Network address-not present
    NS Offload-Enabled
    Receive Buffers-2048
    Receive Side Scaling-Enabled
    Shutdown Wake Up-Enabled
    Speed & Duplex-Auto Negotiation
    SWOI-Disabled
    TCP Checksum Offload (IPv4)-Rx & Tx Enabled
    TCP Checksum Offload (IPv6)-Rx & Tx Enabled
    Transmit Buffers-1024
    UDP Checksum Offload (IPv4)-Rx & Tx Enabled
    UDP Checksum Offload (IPv6)-Rx & Tx Enabled
    VLAN ID-0
    Wake on magic packet-Enabled
    Wake on pattern match-Enabled

    These are also the exact same settings on the Alienware E2200 Ethernet Adapter, so I haven't changed them since they work on the MSI laptop.  But I'm all for suggestions!




    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    Just saying....Good Luck! I wish I could tell you what I am working on for Schneider. In the Fall maybe.
    Another reason now why I can't wait until Fall gets here!
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    Estragon said:
    The driver thing was a bit of a long shot, as I suspect the issue is (mainly) higher up the protocol stack. It's been more years than I care to admit since I've gotten into this level of detail with TCP though. Will have to read through some RFCs etc as there've been lots of newer additions/tweaks/hacks.

    Seems to me OS2 was widely used in bank machines, because it just worked (while MSDOS/Windoze needed a regular cold boot). Maybe some sort of *nix these days? My son gave me a t-shirt a few years back with a penguin (linux "Tux") holding a sword and a caption of "Kill Bill" :smile:
    Yup, my dad had several banks as clients, but he was a mainframe tech.  OS2 was only coming out in the latter years of his career, so PCs weren't his area of expertise.

    Getting these Alienware computers to play nice with the combox is quite an unanticipated challenge.  I really like the logging capability, so I'm going to keep working on it until I get it figured out.  Thanks again!
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dave Angelini
    Dave Angelini Solar Expert Posts: 6,730 ✭✭✭✭✭✭
    When we lived in the San Jose area in the 80's IBM and HP had plants that manufactured hardware also. They each had about 10 plants in all directions of the compass. Not much going on with hardware for either of these companies. For IBM it was really bad management of their pensions.  HP was smart enough to go early with the adopting the 401K.  HP sold off their instrumentation business that was being managed by computer people. :'( 

    We use to poke fun at IBM with their white shirts and ties and we only dressed up when a customer was around. It is weird how very large companies lose their vision and end up this way.


    "we go where power lines don't" Sierra Nevada mountain area
       htps://offgridsolar1.com/
    E-mail offgridsolar@sti.net

  • Estragon
    Estragon Registered Users Posts: 4,496 ✭✭✭✭✭
    Maybe try disabling the Large Send Offloads. They're meant to let the machine spew forth packets faster by offloading cpu work (splitting buffers into packets) to the nic, but spewing too slow isn't our problem, and it's not hard to imagine something a bit broken in the process gumming things up. Worth a shot?
    Off-grid.  
    Main daytime system ~4kw panels into 2xMNClassic150 370ah 48v bank 2xOutback 3548 inverter 120v + 240v autotransformer
    Night system ~1kw panels into 1xMNClassic150 700ah 12v bank morningstar 300w inverter
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    Estragon said:
    Maybe try disabling the Large Send Offloads. They're meant to let the machine spew forth packets faster by offloading cpu work (splitting buffers into packets) to the nic, but spewing too slow isn't our problem, and it's not hard to imagine something a bit broken in the process gumming things up. Worth a shot?
    I'm in the process of going line by line and changing/enabling/disabling and trying to log in to the combox.  Already tried disabling Large Send Offloads.  I just finished adjusting the RSS queues from 4 down to 1.  No change.  But thanks!  I'll let you know if anything changes, but since it all works as is with the MSI gaming laptop, I don't have much hope.
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    I changed every line item, one at a time.  No joy.
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • mike95490
    mike95490 Solar Expert Posts: 9,583 ✭✭✭✭✭
    Just saying....Good Luck! I wish I could tell you what I am working on for Schneider. In the Fall maybe.
    Always the tease
    Powerfab top of pole PV mount | Listeroid 6/1 w/st5 gen head | XW6048 inverter/chgr | Iota 48V/15A charger | Morningstar 60A MPPT | 48V, 800A NiFe Battery (in series)| 15, Evergreen 205w "12V" PV array on pole | Midnight ePanel | Grundfos 10 SO5-9 with 3 wire Franklin Electric motor (1/2hp 240V 1ph ) on a timer for 3 hr noontime run - Runs off PV ||
    || Midnight Classic 200 | 10, Evergreen 200w in a 160VOC array ||
    || VEC1093 12V Charger | Maha C401 aa/aaa Charger | SureSine | Sunsaver MPPT 15A

    solar: http://tinyurl.com/LMR-Solar
    gen: http://tinyurl.com/LMR-Lister ,

  • Raj174
    Raj174 Solar Expert Posts: 795 ✭✭✭✭
    @Dusty
    Do you happen to have a wireless USB adapter? This could be used to bypass the Alienware adapters. That would be my next step. If you don't have one, Newegg has a good selection for less than 20 bucks. 

    Rick
    4480W PV, MNE175DR-TR, MN Classic 150, Outback Radian GS4048A, Mate3, 51.2V 360AH nominal LiFePO4, Kohler Pro 5.2E genset.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    Raj174 said:
    @Dusty
    Do you happen to have a wireless USB adapter? This could be used to bypass the Alienware adapters. That would be my next step. If you don't have one, Newegg has a good selection for less than 20 bucks. 

    Rick
    Thanks Rick, I'll look into it.  All 4 Alienware computers have a different wireless adapter built onto the motherboard, and they don't work with the combox either.
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    edited August 2018 #109
    A new twist.  I fired up another desktop machine.  This is a home-built unit with an MSI X99a SLI Plus motherboard and a Haswell Extreme CPU identical to the ones in the Alienware desktops (the CPU is identical, not the motherboard, but I think that Alienware uses MSI motherboards too, since the BIOS looks similar but not identical).  It's running Windows 10 Pro 64-bit. The Ethernet adapter built onto the motherboard is different than the Alienware model; it's an Intel I218-V with an Intel driver dated 5/2/2018 (V12.17.10.7).
    It will not log onto the combox either.  Same sluggishness and disconnect problem. 
    Since this machine is not an Alienware, now I have yet another datapoint to compare.  Great.
    I'm checking the BIOS settings now to see if there's anything I can tweak.  There are more options in this Mobo's BIOS than the Alienware mobos.
    Now that I have a non-Alienware computer also having the problem, perhaps it's a CPU incompatibility...
    Is ANYONE using a Haswell-E, Skylake or Kabylake CPU with their combox?  All my other computers work with the combox, but they are Broadwell or older CPUs.  All Intel, however.  I don't have any AMD cpus.
    And I'm not saying for sure that the CPU is the issue, but I'm exploring that option--now that I have a desktop computer that's not an Alienware showing the problem but uses the same CPU as the Alienware desktops.  As far as I know, that's the only hardware common denominator between this home built machine and the Alienware desktop machines since the Ethernet adapters are different. I've ruled out Windows 10 Pro 64-bit, since I have an older machine running it, and it works with the combox.
    I'm just trying to identify what's common to them that could be causing the problem.  Since the Ethernet adapters aren't the same, and I think I proved yesterday that identical adapters (and all the settings were identical too) were tested in both combox-compatible and non-compatible computers, I don't think the adapter is the issue.  
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    Non of the BIOS settings in the MSI mobo had any effect.
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • MrM1
    MrM1 Registered Users Posts: 487 ✭✭✭✭
    All the more reason to try an external usb wifi device.  I was going to suggest that too.  Try an alternate external wife "card"
    REC TwinPeak 2 285W 3S-3P 2.6kW-STC / 1.9kW-NMOT Array / MN Solar Classic 150 / 2017 Conext SW 4024 Inverter latest firmware / OB PSX-240 Autotransfomer for load balancing / Trojan L16H-AC 435Ah bank 4S connected to Inverter with 7' of 4/0 cable / 24 volt system / Grid-Assist or Backup Solar Generator System Powering 3200Whs Daily / System went Online Oct 2017 / System, Pics and Discussion
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    I have a USB wi-fi card that I will try, but I don't know if it's compatible with Windows 10.  If not, I won't be able to do that today.

    I just finished flashing a new BIOS onto the MSI mobo, since it hadn't been done since the Intel vulnerabilities were discovered. The new bios is dated 6/14/18, but it didn't make any difference with combox.
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    edited August 2018 #113
    Just installed a USB TP-Link AC600 High Gain dual band Wi-Fi adapter.  Disabled my Ethernet connection, then connected to my network using wireless 5Ghz.  Very strong signal, since the router is only one room away.
    Same problem with the combox.
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    edited August 2018 #114
    Using WireShark, I'm seeing the same continual re-transmission messages from the MSI mobo desktop to the combox over port 80 as I saw on the Alienware desktops and laptops:
    74    3.225448    192.168.1.179    192.168.1.249    TCP    62    [TCP Retransmission] 50046 → 80 [SYN, ECN, CWR] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
    75    3.226438    192.168.1.179    192.168.1.249    TCP    62    [TCP Retransmission] 50047 → 80 [SYN, ECN, CWR] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1

    I don't know how significant this is--but I do know that none of my computers that talk to the combox successfully have any of these re-transmissions according to WireShark.


    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Estragon
    Estragon Registered Users Posts: 4,496 ✭✭✭✭✭
    That's quite the wrinkle! A cpu bug that only apparently manifests on a specific http connection?
    Off-grid.  
    Main daytime system ~4kw panels into 2xMNClassic150 370ah 48v bank 2xOutback 3548 inverter 120v + 240v autotransformer
    Night system ~1kw panels into 1xMNClassic150 700ah 12v bank morningstar 300w inverter
  • Estragon
    Estragon Registered Users Posts: 4,496 ✭✭✭✭✭
    Not really a surprise the USB stick didn't work. The main difference would just be the serial interface to the radio... lower down the protocol stack than I think the problem lurks.
    Off-grid.  
    Main daytime system ~4kw panels into 2xMNClassic150 370ah 48v bank 2xOutback 3548 inverter 120v + 240v autotransformer
    Night system ~1kw panels into 1xMNClassic150 700ah 12v bank morningstar 300w inverter
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    edited August 2018 #117
    Estragon said:
    That's quite the wrinkle! A cpu bug that only apparently manifests on a specific http connection?
    I know it's a stretch, and I'm probably barking up the wrong tree--considering I have three different Intel CPUs having the same issue: Haswell-E, SkyLake and KabyLake.  But the motherboards and ethernet adapters are different in the Haswell-E machines, and so are the motherboards in the two Alienware laptops.  I think the ethernet adapters in the laptops are the same, but I might be wrong about that.  But the MSI laptop has a Broadwell CPU (and Windows 10 Home Edition)--although it has the identical Ethernet adapter to the Alienware Desktops that don't talk to the combox, while the MSI laptop does talk to it.  And since I proved yesterday that it isn't any of the Ethernet Adapter settings, I'm at my wits end.  I really thought it was related to the Alienware machines, until I discovered a non-alienware desktop computer today with the same problem--and the only hardware in common between the MSI desktop and the two Alienware desktops is the Intel I7-5960X CPU.  That, and none of those desktops can talk to the Combox.

    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    edited August 2018 #118
    I'm trying to dig deeper into WireShark to see what's going on with the retransmission errors.  I'm using the latest WireShark recording from the MSI Desktop that is having trouble with the combox.

    Highlighting the first retransmission in the 30 second recording and drilling down into the [SEQ/ACK analysis] [TCP Analysis Flags], the first retransmission occured 3.0000062000 seconds after the initial transmission.  That seems like a really long time for the MSI desktop to wait to receive an ACK from the combox, but that's how long it waited.  The MSI desktop never received an ACK from the combox for that data packet in the 30 second length of the WireShark recording:
    2    0.225386    192.168.1.179    192.168.1.249    TCP    62    50046 → 80 [SYN, ECN, CWR] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
    74    3.225448    192.168.1.179    192.168.1.249    TCP    62    [TCP Retransmission] 50046 → 80 [SYN, ECN, CWR] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1

    There are many of these retransmissions in this 30 seconds, so I have to wonder why the combox isn't getting the initial data packet from 5  Windows 10 Pro 64-bit late model Intel CPU machines (all less than 3 years old). 

    So, I'm going to set up one of the Alienware laptops and wire it directly to a stand-alone router and wire the extra combox to the same router.  No other devices will be attached. This will duplicate what I already did with Schneider tech support last week, but the difference will be that I'll be able to look at it with WireShark and see if anything jumps out at me.
    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Estragon
    Estragon Registered Users Posts: 4,496 ✭✭✭✭✭
    Do you by any chance have an old-school dumb hub?

    What I'm thinking is to get a non-working client, the combox, and a working client all on the same collision domain (switched router port). The working client box would do the wireshark sniffing, and should see packets between the non-working client and the combox with no router/switch in between. Running the sniffer on a box separate from send/receive boxes mostly eliminates issues (for diagnostic purposes) around off-loading, in which things like checksums may be added where the sniffer doesn't operate on a send/receive box. Running the sniffer on a third party box helps eliminate that as it should just see traffic on the segment, not anything internal to the boxes being tested.

    If so, put all 3 devices on the hub connected to one (likely switched) port on the router. The router should leave traffic between boxes on the hub on that port, and likely not mess with it.
    Off-grid.  
    Main daytime system ~4kw panels into 2xMNClassic150 370ah 48v bank 2xOutback 3548 inverter 120v + 240v autotransformer
    Night system ~1kw panels into 1xMNClassic150 700ah 12v bank morningstar 300w inverter
  • Dusty
    Dusty Solar Expert Posts: 271 ✭✭✭
    edited August 2018 #120
    For this test, I started WireShark recording right before logging in to the combox, and I let it run for 5 minutes. That's how long it took to get to the page where the left side of the combox web page shows the three options: System Performance, System Devices and Combox Configuration. But the entire time, the right side of the screen (where the battery, solar, grid etc. icons would be) was only this message-- "Loading in progress, your patience is appreciated."

    The IP address of the Alienware 17R4 is 192.168.0.199, and the combox is 192.168.0.198.  The router is a D-Link DIR-655 gigabit router, and it was not connected to the Internet during this test:

    6    2.189716    192.168.0.199    192.168.0.255    BROWSER    257    Local Master Announcement ALIENWARE17R4, Workstation, Server, NT Workstation, Potential Browser, Master Browser
    7    2.416998    Dell_77:de:56    Broadcast    ARP    42    Who has 192.168.0.198? Tell 192.168.0.199
    8    2.417997    Schneide_fe:3d:b5    Dell_77:de:56    ARP    64    192.168.0.198 is at 00:00:54:fe:3d:b5 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]

    The first TCP retransmission message was 5.66 seconds into the recording (probably took me that long to log in from when I started the recording)

    9    2.418013    192.168.0.199    192.168.0.198    TCP    62    50453 → 80 [SYN, ECN, CWR] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
    17    5.417474    192.168.0.199    192.168.0.198    TCP    62    [TCP Retransmission] 50453 → 80 [SYN, ECN, CWR] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1

    Strangely, The laptop again asked

    51    10.619500    Dell_77:de:56    Schneide_fe:3d:b5    ARP    42    Who has 192.168.0.198? Tell 192.168.0.199
    52    10.620677    Schneide_fe:3d:b5    Dell_77:de:56    ARP    64    192.168.0.198 is at 00:00:54:fe:3d:b5 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]

    Then the laptop sent another retransmission

    54    11.417436    192.168.0.199    192.168.0.198    TCP    62    [TCP Retransmission] 50453 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1

    And approximately 9 seconds after sending the first data packet, combox acknowledged it.

    55    11.419418    192.168.0.198    192.168.0.199    TCP    64    80 → 50453 [SYN, ACK] Seq=0 Ack=1 Win=4096 Len=0 MSS=1460 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]
    56    11.419479    192.168.0.199    192.168.0.198    TCP    54    50453 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
    57    11.419575    192.168.0.199    192.168.0.198    HTTP    385    GET / HTTP/1.1
    58    11.422739    192.168.0.198    192.168.0.199    TCP    64    80 → 50453 [ACK] Seq=1 Ack=332 Win=3765 Len=0 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]
    59    11.495870    192.168.0.198    192.168.0.199    TCP    300    80 → 50453 [PSH, ACK] Seq=1 Ack=332 Win=3765 Len=246 [TCP segment of a reassembled PDU]
    60    11.495956    192.168.0.199    192.168.0.198    TCP    54    50453 → 80 [ACK] Seq=332 Ack=247 Win=63994 Len=0
    61    11.507916    192.168.0.198    192.168.0.199    TCP    1514    80 → 50453 [ACK] Seq=247 Ack=332 Win=3765 Len=1460 [TCP segment of a reassembled PDU]
    62    11.508005    192.168.0.199    192.168.0.198    TCP    54    50453 → 80 [ACK] Seq=332 Ack=1707 Win=64240 Len=0
    63    11.508668    192.168.0.198    192.168.0.199    TCP    642    80 → 50453 [PSH, ACK] Seq=1707 Ack=332 Win=3765 Len=588 [TCP segment of a reassembled PDU]
    64    11.508716    192.168.0.199    192.168.0.198    TCP    54    50453 → 80 [ACK] Seq=332 Ack=2295 Win=63652 Len=0
    65    11.512592    192.168.0.199    192.168.0.198    TCP    54    50453 → 80 [FIN, ACK] Seq=332 Ack=2295 Win=63652 Len=0
    66    11.513956    192.168.0.199    192.168.0.1    DNS    84    Standard query 0xf370 A detectportal.firefox.com
    67    11.514496    192.168.0.198    192.168.0.199    TCP    64    80 → 50453 [ACK] Seq=2295 Ack=333 Win=3765 Len=0 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]
    68    11.522790    192.168.0.199    192.168.0.198    TCP    62    50463 → 80 [SYN, ECN, CWR] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
    69    11.524458    192.168.0.198    192.168.0.199    TCP    1514    80 → 50453 [ACK] Seq=2295 Ack=333 Win=3765 Len=1460 [TCP segment of a reassembled PDU]
    70    11.524495    192.168.0.199    192.168.0.198    TCP    54    50453 → 80 [RST, ACK] Seq=333 Ack=3755 Win=0 Len=0
    71    11.525138    192.168.0.198    192.168.0.199    TCP    642    80 → 50453 [PSH, ACK] Seq=3755 Ack=333 Win=3765 Len=588 [TCP segment of a reassembled PDU]

    The above segment 71 was the last packet of data for Port 80 50453 and took approximately 9 seconds to transmit with no other traffic on the router....

    This 5 minute snapshot is full of retransmissions like this.  And the whole time, the combox was unresponsive.

    XW6048, 3.4KW PV, Grid-Tied, always tweaking.
  • Estragon
    Estragon Registered Users Posts: 4,496 ✭✭✭✭✭
    It isn't actually as much of a stretch as you might think. From what I've observed, much of the internet only works because of a principle similar to the "swiss cheese" approach to transportation safety.

    In transportation safety, every "slice" has holes (features/tweaks/bugs), but stack enough slices, the holes all get filled, and the system works. If you remove or change a slice, unexpected holes can appear.

    Applying this to your processor theory; these processors have been out for some time, and neither internal or real-world testing turned up a big hole. There have to be enough of these processors used with enough comboxes, that if the hole opened with that change alone, it would be evident by now. That impies there's a tertiary (or more) slice opening the hole.

    In other words, there could (for example) be a change (eg. ordering through multiple cpu cores) in threading that occurs only rarely in some code under certain circumstances, but in which some TCP implementations, in certain circumstances, rely on an obsolete/newer RFC, which the combox can't deal with.
    Off-grid.  
    Main daytime system ~4kw panels into 2xMNClassic150 370ah 48v bank 2xOutback 3548 inverter 120v + 240v autotransformer
    Night system ~1kw panels into 1xMNClassic150 700ah 12v bank morningstar 300w inverter