Siglent SDS800X HD 12 bit DSO's

[Furna]

When I re-enabled DHCP, the scope autonomously got its IP adress and NTP time. 

Sounds like Siglent still hasn't gotten DHCP right.  Testing it, it looks like they're doing a DHCPDISCOVER roughly once a second, forever, if they don't get a response. RFC 2131: "The client MUST adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions."

They also continue to ignore lease times, and do DHCP renewals every minute or so.

There is no RTC so respecting the lease time between reboot/power-off is not possible ... but a renewal every minte and 15 sec is really annoying.
Behaviour not common to every Siglent device; power supply SPD4121x behaveas much better.

[Furna]

[...]
Some standards are written while having in mind thousands devices in single LAN, and how to deal with chaos ensuing.
Single device asking for DHCP server like this is not really a heavy load. If you are not using DHCP then it doesn't matter. If you are using DHCP and server is not available, you need to fix DHCP server to be able to use network.
At that moment problem is fact that all your devices can't see DHCP server, not single device asking relentlessly.
I don't see scenario where this will create real problems.
I agree that formally this is not as it should be. In practice, this is not problem.
Make sure I will report this, but critical it is not.
Thanks for the checking.

Unless the scope is attached to a corporate network ... where such behaviour could potentially triggers alarms.

[2N3055]

[...]
Some standards are written while having in mind thousands devices in single LAN, and how to deal with chaos ensuing.
Single device asking for DHCP server like this is not really a heavy load. If you are not using DHCP then it doesn't matter. If you are using DHCP and server is not available, you need to fix DHCP server to be able to use network.
At that moment problem is fact that all your devices can't see DHCP server, not single device asking relentlessly.
I don't see scenario where this will create real problems.
I agree that formally this is not as it should be. In practice, this is not problem.
Make sure I will report this, but critical it is not.
Thanks for the checking.

Unless the scope is attached to a corporate network ... where such behaviour could potentially triggers alarms.

What are you referring to as potential alarm raising event:

1. Refreshing DHCP every 75 seconds regardless of lease period?
2. Asking for a DHCP server where there is none?

For 1. I agree that some network monitoring device might notice something. But not because it created problems, but because some SIEM or vulnerability scanner might flag it as suspicious.

For 2. It retries because DHCP is not available. In which case those corporate network admins need to fix DHCP server or tell you not to use it.

[Furna]

What are you referring to as potential alarm raising event:

1. Refreshing DHCP every 75 seconds regardless of lease period?
2. Asking for a DHCP server where there is none?

For 1. I agree that some network monitoring device might notice something. But not because it created problems, but because some SIEM or vulnerability scanner might flag it as suspicious.

For 2. It retries because DHCP is not available. In which case those corporate network admins need to fix DHCP server or tell you not to use it.

I am referring to both ...

1. You want to notice such behaviour not only for security reasons ... think about a new firmware version of a mobile phone distributed to the whole company population.
In a matter of days you can have multiple thousand of DHCP requests in few seconds. Such behaviour IS monitored.

2. The fact the corportae network admins are already in trouble doesn't mean you are welcome to add some on top

Nevertheless I am happy with my scope, I am happy Siglent is taking care of signaled issues.

Also thank you for your effort.

[2N3055]

What are you referring to as potential alarm raising event:

1. Refreshing DHCP every 75 seconds regardless of lease period?
2. Asking for a DHCP server where there is none?

For 1. I agree that some network monitoring device might notice something. But not because it created problems, but because some SIEM or vulnerability scanner might flag it as suspicious.

For 2. It retries because DHCP is not available. In which case those corporate network admins need to fix DHCP server or tell you not to use it.

I am referring to both ...

1. You want to notice such behaviour not only for security reasons ... think about a new firmware version of a mobile phone distributed to the whole company population.
In a matter of days you can have multiple thousand of DHCP requests in few seconds. Such behaviour IS monitored.

2. The fact the corportae network admins are already in trouble doesn't mean you are welcome to add some on top

Nevertheless I am happy with my scope, I am happy Siglent is taking care of signaled issues.

Also thank you for your effort.

Just make sure, I like things to be perfect. I am not saying things should not be made perfect when possible. Just trying to explain there is some priority when stuff gets worked on.

As for thanks, you are welcome. I try to help when I can, in my limited way. Siglent does all the job in the end.
I am just happy they listen.

[mikes]

Single device asking for DHCP server like this is not really a heavy load.

That cannot be said. They're broadcasts, and DHCP might be going across a relatively slow WAN link. Once per second is abusive, in addition to violating the RFC. Ignoring the lease time is also abusive, even if on a fast LAN, if only because it fills server logs.

There is no RTC so respecting the lease time between reboot/power-off is not possible

That is irrelevant (it's also not true that it doesn't have an RTC, it just doesn't have a battery backed one). DHCP times are in relative seconds, and the scope does keep track while powered. And it occurs constantly while powered on, a device doing DHCP on every reboot is not an issue.

It retries because DHCP is not available. In which case those corporate network admins need to fix DHCP server or tell you not to use it.

Shit happens; servers are taken down for maintenance. If devices are given 8 hour leases which they honor, an outage of even a few hours won't affect most. If the server is down, a device broadcasting every second is abusive to every other device on the network.

With over 30 years in enterprise networking, this scope is the only device I've ever encountered which is so abusively talkative.

[Furna]

That cannot be said. They're broadcasts, and DHCP might be going across a relatively slow WAN link. Once per second is abusive, in addition to violating the RFC. Ignoring the lease time is also abusive, even if on a fast LAN, if only because it fills server logs.

Fortunately there are no broadcast packets ... the oscilloscope is asking *renewal* using it's source IP address with destination the IP address of the DHCP that released it (tcpdump doesn't lie).
Regarding slow WAN link ... it is exactly what I was thinking off, even if nowadays there are different strategies other than "dhcp relay" that can save bandwidht.
DHCP logs is also a valid observation ... personally I disabled logs; my DHCP cluster is made of Raspberry PI 3B ... flash cards dont like too many writes.

That is irrelevant (it's also not true that it doesn't have an RTC, it just doesn't have a battery backed one). DHCP times are in relative seconds, and the scope does keep track while powered. And it occurs constantly while powered on, a device doing DHCP on every reboot is not an issue.

While you are correct saying that a *battery* backed RTC is not present, that doesn't change the fact that the device has not a way to understand if the lease is still valid even in case it has saved it during shutdown; simply because it doesn't know what time is it while booting.
The fact that the device starts DHCP broadcast everytime it boots even if the lease is still valid, is also an RFC violation ... try to power off your phone and start it again a few mintes later .. it asks for a *renewal* but does not start DHCP from the beginning.

Shit happens; servers are taken down for maintenance. If devices are given 8 hour leases which they honor, an outage of even a few hours won't affect most. If the server is down, a device broadcasting every second is abusive to every other device on the network.

With over 30 years in enterprise networking, this scope is the only device I've ever encountered which is so abusively talkative.

It seems we have some experiences in common

[2N3055]

Single device asking for DHCP server like this is not really a heavy load.

That cannot be said. They're broadcasts, and DHCP might be going across a relatively slow WAN link. Once per second is abusive, in addition to violating the RFC. Ignoring the lease time is also abusive, even if on a fast LAN, if only because it fills server logs.

There is no RTC so respecting the lease time between reboot/power-off is not possible

That is irrelevant (it's also not true that it doesn't have an RTC, it just doesn't have a battery backed one). DHCP times are in relative seconds, and the scope does keep track while powered. And it occurs constantly while powered on, a device doing DHCP on every reboot is not an issue.

It retries because DHCP is not available. In which case those corporate network admins need to fix DHCP server or tell you not to use it.

Shit happens; servers are taken down for maintenance. If devices are given 8 hour leases which they honor, an outage of even a few hours won't affect most. If the server is down, a device broadcasting every second is abusive to every other device on the network.

With over 30 years in enterprise networking, this scope is the only device I've ever encountered which is so abusively talkative.

Regardless of the fact that you are right this is not as it should be, if this would bring my network down I would fire network guys for crappy network.
Scope only asks every second when your network is already broken. And DHCP packet is tiny.

As for filling the server logs, I get it is annoying. But, also if that can bring your log server down, you have bigger problems. At some places I know
 log servers are collecting gigabytes of data from audit and security logs.

I am not dismissing fact DHCP client is not perfect.  But it is something that would create problems only if something is pathological about network.

Should it be fixed. Sure. 

Like Furna, I run my little lab network with DHCP with reserved addresses and do not log DHCP lease events. I didn't even know that it ignores lease time until I was warned about that and then went in and specifically looked for it.  So horrible was the impact on my network. Impact is zero, from single scope. That is what I am saying.

When running on corporate networks, there are many places that won't even let you connect scope. "What is this? A scope. What OS it runs? I don't know, some Linux.. Ok here is the list of allowed operating systems, patch levels, AV software installed.... I can't do that it is closed appliance...
Well sorry, according to our security policy you are not allowed to connect  THAT on our network. Have a nice day.."

[mikes]

Fortunately there are no broadcast packets ... the oscilloscope is asking *renewal* using it's source IP address with destination the IP address of the DHCP that released it (tcpdump doesn't lie).

The fact that the device starts DHCP broadcast everytime it boots even if the lease is still valid, is also an RFC violation

First, on boot/reboot, it sends DHCPDISCOVERs about every second, apparently forever, which is a spec violation and abusive. Once it gets an assignment, and does continuous 1 minute renewals. It would be interesting to see how it behaves at lease expiration - does it honor the lease period at all?

Secondly, no. RFC 2131 says the opposite: "A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network..."

it is something that would create problems only if something is pathological about network.

That it doesn't cause issues in most cases is not a valid excuse. This is not a gray area, they're simply doing it wrong, especially 28 years after DHCP came out, and with lots of reference implementations to see how it's done in both practice and following the spec. That they've strayed so far from the norm only tells me they tried to "roll their own", and failed in the process.

[tautech]

Q:
Does this behavior continue when NTP is set to OFF ?

[Furna]

First, on boot/reboot, it sends DHCPDISCOVERs about every second, apparently forever, which is a spec violation and abusive. Once it gets an assignment, and does continuous 1 minute renewals. It would be interesting to see how it behaves at lease expiration - does it honor the lease period at all?

We are saying the same ... it continuosly perform renewals every 75 seconds; renewal are unicast NOT broadcast.
See attached TXT.

Secondly, no. RFC 2131 says the opposite: "A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network..."

At boot "SHOULD use DHCP to reacquire or verify" => verify via a renewal (unicast); indeed it does a discover (no clock time is mantained so no way to verify a renewal even if it has saved at shutdown).

That it doesn't cause issues in most cases is not a valid excuse. This is not a gray area, they're simply doing it wrong, especially 28 years after DHCP came out, and with lots of reference implementations to see how it's done in both practice and following the spec. That they've strayed so far from the norm only tells me they tried to "roll their own", and failed in the process.

Agree; also I do not understand why other products from Siglent are doing better in this area.
Nevertheless I like the scope all in all.

Q:
Does this behavior continue when NTP is set to OFF ?

A:
See attached TXT.
SPOILER: YES

[mikes]

Does this behavior continue when NTP is set to OFF ?

The behavior doesn't really change. I did notice that when testing this, discovers were sent at closer to a 5 second (average) intervals, greater than yesterday. So, they must be doing some random timing. But, the intervals still did not increase exponentially as required.

[Furna]

The behavior doesn't really change. I did notice that when testing this, discovers were sent at closer to a 5 second (average) intervals, greater than yesterday. So, they must be doing some random timing. But, the intervals still did not increase exponentially as required.

When the DHCP server is not available, I see a pattern:

3 discoveries every 6 seconds, random wait, 3 discoveries every 6 seconds, random wait ...

See my previous post and the attached file.

[tautech]

Q:
Does this behavior continue when NTP is set to OFF ?

A:
See attached TXT.
SPOILER: YES

Okay, further Q;

I let the scopes DHCP find and negotiate an IP then disable DCHP to have that IP set as the one the scope will use and remember.
When setup this way (automatic and with zero user IP input), does the DCHP regular polling continue ?

[Furna]

Q:
Does this behavior continue when NTP is set to OFF ?

A:
See attached TXT.
SPOILER: YES

Okay, further Q;

I let the scopes DHCP find and negotiate an IP then disable DCHP to have that IP set as the one the scope will use and remember.
When setup this way (automatic and with zero user IP input), does the DCHP regular polling continue ?

Further A:
No; it stops as soon as the "Automatic" checkbox is unchecked and this is persisten between reboots.

I will refrain from any comment

[tautech]

Q:
Does this behavior continue when NTP is set to OFF ?

A:
See attached TXT.
SPOILER: YES

Okay, further Q;

I let the scopes DHCP find and negotiate an IP then disable DCHP to have that IP set as the one the scope will use and remember.
When setup this way (automatic and with zero user IP input), does the DCHP regular polling continue ?

Further A:
No; it stops as soon as the "Automatic" checkbox is unchecked and this is persistent between reboots.

When NTP is ON (active) too ?

[Furna]

Q:
Does this behavior continue when NTP is set to OFF ?

A:
See attached TXT.
SPOILER: YES

Okay, further Q;

I let the scopes DHCP find and negotiate an IP then disable DCHP to have that IP set as the one the scope will use and remember.
When setup this way (automatic and with zero user IP input), does the DCHP regular polling continue ?

Further A:
No; it stops as soon as the "Automatic" checkbox is unchecked and this is persistent between reboots.

When NTP is ON (active) too ?

Yes

[tautech]

Q:
Does this behavior continue when NTP is set to OFF ?

A:
See attached TXT.
SPOILER: YES

Okay, further Q;

I let the scopes DHCP find and negotiate an IP then disable DCHP to have that IP set as the one the scope will use and remember.
When setup this way (automatic and with zero user IP input), does the DCHP regular polling continue ?

Further A:
No; it stops as soon as the "Automatic" checkbox is unchecked and this is persistent between reboots.

When NTP is ON (active) too ?

Yes

Then it appears we have a solution to excessive DCHP polling by the scope:

Autofind/set scopes IP and set DCHP Auto to unchecked (OFF).

Thanks for helping us work through that. 

[Furna]

Q:
Does this behavior continue when NTP is set to OFF ?

A:
See attached TXT.
SPOILER: YES

Okay, further Q;

I let the scopes DHCP find and negotiate an IP then disable DCHP to have that IP set as the one the scope will use and remember.
When setup this way (automatic and with zero user IP input), does the DCHP regular polling continue ?

Further A:
No; it stops as soon as the "Automatic" checkbox is unchecked and this is persistent between reboots.

When NTP is ON (active) too ?

Yes

Then it appears we have a solution to excessive DCHP polling by the scope:

Autofind/set scopes IP and set DCHP Auto to unchecked (OFF).

Thanks for helping us work through that. 

Now I can comment.

This is not a solution it is a dirty workaround.
The solution is Siglent's team in charge of SDS800X series to properley implement DHCP.

[mikes]

Then it appears we have a solution to excessive DCHP polling by the scope:

Autofind/set scopes IP and set DCHP Auto to unchecked (OFF).

Thanks for helping us work through that. 

LOL. No.

Patient: Dr, it hurts when I do this.
Dr: Don't do that. I'll send you a bill.

[tautech]

Then it appears we have a solution to excessive DCHP polling by the scope:

Autofind/set scopes IP and set DCHP Auto to unchecked (OFF).

Thanks for helping us work through that. 

LOL. No.

Patient: Dr, it hurts when I do this.
Dr: Don't do that. I'll send you a bill.

Poor feedback.

Okay so there is a problem under certain DCHP usage conditions and with some simple and logical examination Furna helped us zero in on exactly what they are, that is when Auto DCHP is set to ticked (ON).

Now we have something definitive to report to Siglent rather than wildly stating their DHCP implementation is incorrect. 

Take a step back and provide a defined setup that results in suboptimal operation to help with narrowing down the cause instead of some blanket rubbishing of their DCHP implementation.

[mikes]

Poor feedback.

Okay so there is a problem under certain DCHP usage conditions and with some simple and logical examination Furna helped us zero in on exactly what they are, that is when Auto DCHP is set to ticked (ON).

Now we have something definitive to report to Siglent rather than wildly stating their DHCP implementation is incorrect. 

Take a step back and provide a defined setup that results in suboptimal operation to help with narrowing down the cause instead of some blanket rubbishing of their DCHP implementation.

Anyone familiar with basic networking can duplicate the issues with the information already provided. You're obviously not that person.

[2N3055]

I am confused now.

Is it asking every second when cannot contact DHCP or is it every 6 seconds and then random wait. How long is the wait, order of magnitude?
How many unnecessary requests like those are in the minute?

You guys are splitting hairs. Siglent will be informed and it will eventually be made to conform to RFC, just because obeying rules is what engineers do. RFC are our friend.

In meantime is not going to create problems to anybody. It does not need workarounds.
I have yet to see realistic scenario (not some invented imaginary, spherical cows in vacuum  type) of any real world problems this can produce, that would warrant such a outrage. It is not DDOS, for crying out loud .

You guys are beating the dead cow. We heard you. Duly noted. Now please let's move on to something else? Please?

You know, using the scope and comments about it's actual use as an instrument type of discussion?

[tautech]

Poor feedback.

Okay so there is a problem under certain DCHP usage conditions and with some simple and logical examination Furna helped us zero in on exactly what they are, that is when Auto DCHP is set to ticked (ON).

Now we have something definitive to report to Siglent rather than wildly stating their DHCP implementation is incorrect. 

Take a step back and provide a defined setup that results in suboptimal operation to help with narrowing down the cause instead of some blanket rubbishing of their DCHP implementation.

Anyone familiar with basic networking can duplicate the issues with the information already provided. You're obviously not that person.

Correct.
However we now have a definitive set of conditions where DCHP is a problem....did you help us zero in on those..... NO !

[BillyO]

I have designed and setup dozens of industrial and corporate networks.  Never, ever have I specified that stationary equipment use DHCP.  This is just plain poor network design.  All stationary equipment, servers, desktops, machines, instruments, etc.. that remain attached to the network for their normal use and over an extend period of time, should be assigned a permanent address.  ONLY mobile equipment that experiences frequent and extended breaks from the network, like laptops, phones, etc.. should be set to use DHCP.

I don't know why all this started in this thread, but it seems like a non-problem to me.  Even in my home network I have pool of permanent addresses.  In fact my pool of address available for DHCP number only 32, and that's plenty more than I need.

It seems like network design and administration has gone toward "Let's make it so any idiot can be our network admin".  Just like programming, where achingly slow and inefficient languages like Python and C# have taken over from C and C++ just so you can hire low priced morons as programmers instead of spending money on competent people.