Potential bugs in WS3 firmware causing strange behaviour

[Stephen]

Hey Garnet, so I wanted to clear a few things up I think there may have been a misunderstanding from above.

To clarify, your testing showed that after issuing a command over the console port (changing DHCP settings) some strange issues would occur?

Summarizing the above, I found that when DHCP is turned on (by any means, whether via the console or web) if it fails to acquire an address, in this experiment by removing the cable, then it defaults to an address that is provided by the kernel but it does not tell the Netonix code what that address is which causes unexpected behavior due to a null pointer being passed around from the de-synced config. I hope that's a bit clearer.

And I am working on fixing this one for sure, but it is only an issue if the switch fails to acquire a DHCP lease, which I was only able to do by removing the cable connecting the switch to the DHCP server.

Regarding your other post showing the 2 address's assigned to the switch from the DHCP server.
I have tried replicating this by using a Netgear router and an Ubiquiti router acting as the DHCP server, but I haven't seen this occur.
On the WS3 could you provide the output for the following command:

Code: Select all

cmd
ip addr show


That might help shed some light as to what is happening.

[Garnet]

Hello Stephen,

As requested I've attached a file containing the result of 'ip addr show'. To me the output looks correc,t however I did confirm that the switch acquired two IPv4 addresses again. This was confirmed from the routers DHCP Leases, as before the 'estax' host appears first followed by Netonix_Switch a few seconds later. The 'estax' host does not renew it's DHCP lease so I'm confident in saying that it must be from part of the switch before the Netonix side takes over (something Vitesse maybe).

[Garnet]

Stephen, on another note. Would you be able to look into that PHP error that this unit has been having? I'm almost certain that the root cause of our issues is that error. It could be something as simple as a file that isn't being created / is being deleted under specific circumstances.

Edit: As well based on what I've found so far, this type of error is usually caused when the resource listening on the other end doesn't exist or is otherwise unavailable.

Edit2: ESTAX Appears to be the name of an old version of the Vitesse API from 2010

[Stephen]

Hey Garnet, the data you provided above has been useful.
I've been studying this issue closely and I have a working theory for how it may be occurring.
However, I can't test it locally because I haven't been able to replicate the issue directly in my environment.

Would you be willing to try out some test code when it's ready?

Also if you are, because of some other change's in the works and I need you to provide me the output from this command:

Code: Select all

cmd
ls -al /switch
cat adc*


Feel free to send that to me in a PM.

[Garnet]

Hi Stephen,

I've PM'd you a text file containing the output of those commands. I'm assuming by test code you mean some Alpha Firmware? Either way I would be willing to try some test code if it means a chance at solving this edge case.

Do note that the switch had Ethernet connected when those commands ran.

[Garnet]

Has there been any progress made on this issue?

[Garnet]

Is there any new information available?

[Garnet]

As per additional information in other threads we have decided to RMA our WS3 for a second time in order to receive a unit with new internals. The relevant threads are linked below:

First Thread:
viewtopic.php?f=17&t=6948&hilit=can%27t+log+in#p34578

Third Thread:
viewtopic.php?f=17&t=7233&p=35772#p35772

Most Recent Thread:
viewtopic.php?f=17&t=7231&p=35738#p35738