Schneider Advantys STB NIP 2212 doesn't get IP via DHCP

[blasmurf]

Hello!

I'm trying to get an I/O-island, Schneider Electric Advantys STB NIP 2212, to get an IP-address from a DHCP server by putting the switches available to something (for example 2 on tens and 2 on ones).

I can see in the DHCP server that the Advantys is asking for an IP and the DHCP-server delivers it, but no action. Still blinking "Lan Stn", meaning no IP-address on its network card.

I have tried several DHCP-servers, all with the same results - they recognize it and sends it an IP-address, but no IP appears on the NIP.

Anybody knows what I'm doing wrong?
Thanks in advance.

Alexander Eisner, Sweden

 

[GeoffC]

After setting the rotary switches to a value try pressing the reset button (this button is hidden under the lift up flap at the front of the unit). You will need to hold the button down for a few seconds until the leds on the rest of the cards in the rack start blinking

 

[blasmurf]

GeoffC, Thank you very much for your response!

It didn't get an IP anyway via DHCP, not even after Reset nor rebooting.
The only automatic way is via Bootp Server,
and that's not so common nowadays in enterprise networks.

I have two NIP:s and they behave the same way. They are new, with Exec version 3.00. Schneider support tried with an older version, 1.20 and it worked spotless , he said. But googling gave me that somewhere on the new updates, Schneider had some problwms with DHCP, (fixed with a 2.xx version).

Any more ideas are higly appreciated!

Br

Alexander

 

[osmanmom]

info,

http://www.schneider-electric.co.in...&country=IN&lang=EN&id=FA175498&redirect=true

 

[blasmurf]

Thank you for the link!
"To obtain the IP address for NIP the appropriate server must reside on the network."
Does that mean that the NIP uses a special type of DHCP-server? I have tested 3 so far, 1 Windows Server 2003 and 2 private router-DHCP-servers - same result, No IP...

As I understand it, if I put the roles to 1 (tens) and 1 (ones) the rolename should be *_11 to call it with and, of course, an IP-address?

Are there anyone out there who uses DHCP (not Bootp) and Exec 3.00 who just can say that it's working fine for them?

Thank you very much for your concern!

 

[GeoffC]

As I understand it, if I put the roles to 1 (tens) and 1 (ones) the rolename should be *_11 to call it with

The rolename should be STBNIP2212_011 I am sure it is a 3 digit number at the end
I use this all the time (at least one site is v3) I use the plc as the DHCP server An M340 or Quantum NOE module has this capability

 

[GeoffC]

The rolename may even end with a 4 digit number '0011', I will have to check tomorrow

 

[blasmurf]

Ok, GeoffC, thanks again! I guess the M340 uses a special type of DHCP-server.

I've been using both NIP2212 and the M340 for many years myself but with fixed IP. Now I want to use the NIP together with a PC, hoping that usual enterprise-network DHCP-servers would work, giving the NIP an IP, and my PC-program automatically finds the NIP:s around the network.

Thanks again for your time!

 

[GeoffC]

So did you try the rolename with 3 or 4 digit number

 

[robertkjonesjr]

I have a non-ROHS version which does not have a 3.x fw rev, but instead V2.38. From the release notes, looks like the 3.32 fix is newer. I know they have two firmware tracks: 2.3x for non-RoHS, and 2.7+ for RoHS. Obvious, isn't it?

I tested with what I have which is not the same as yours... so can't be sure my results are absolutely relevant. Anyway, the clientID that is put on the wire in the DHCP request is:

0000 3d 0f 00 53 54 42 4e 49 50 32 32 31 32 5f 30 30
0010 31

which, when looked up in ASCII table would be:

STBNIP2212_001

So the clientID portion has three numbers.

For me, my generic DHCP server works fine, and provides an address. In general, I propose clientID is not relevant - it's a server side feature that would help a server uniquely identify a particular STB system, so that connections could then be made to it. With many DHCP systems, the unique identifier would be MAC address, but I suspect Schneider uses clientID with role name to make it easier to change devices - on failure, the device has to change, but then so does MAC address. By using rotary switches, a replacement can be put in place yet still get the same IP address for connections. It just provides the logical link.

On my DHCP server (non-Windows based), the DHCP offer (four step process: Discover, Offer, Request, Ack) from the server has no mention of clientID, so I know it's not required - the STB does not care. Also tested was either broadcast or unicast - the Discover and Request from the client are usually broadcast anyway, but my DHCP server has an option to always use broadcast or not, which would be how the Offer and Ack are sent at layer-2. It worked in either case.

At least for my STB version, anyway. If there is a bug, my hardware is different, so has different firmware as much as the developers want to tell us it's the same - it never really is.

Could you post a Wireshark trace of your DHCP process?

 

[blasmurf]

Thank you guys for hanging on!

Attached is a file from Wireshark and one from my router. Seems like my router doesn't respond at all? All I can see is "Discover"-calls.

The picture attached shows (in swedish, sorry) that it has been given the NIP an IP-address of 192.168.1.64. This doesn't work when browsing it though (no respond)...

 

[blasmurf]

And also, GeoffC: I tested with higher rolenames - no difference.
And also, robertkjonesjr: at work, I did see the ASCII-string in that DHCP-server! But still the NIP didn't get a stable Green light on "LAN ST".

Putting the NIP to "Bootp", it gets an IP directly! But if you tell the DHCP-server not to listen to Bootp then the NIP gets no IP. Since Bootp is old, I'm worried that my clients don't have the Bootp "on" in their DHCP-servers.

Again, thanks!

 

[robertkjonesjr]

I see only the Discovers as well. Depending on where you took the trace, this may be expected. If you took this on the Windows machine that is the DHCP server then you have an issue - no response is provided and it is useful information. If you took from somewhere else, not on a span/mirror port or hub, then this would be normal.

Do you have a Schneider PLC to test with? Good packet captures comparing success and failure would be useful.

 

[blasmurf]

I did put an M340 as a DHCP-server in the same network as the Windows DHCP-server, and voila - it did get the, in the PLC specified, IP-address.

In the other way, Schneider support did test two different firmwares of NIP:S yesterday, old vs new. The old firmware worked flawlessly in a Windows environment, the new didn't (Exec 3.00 and 3.32 did not work). So I hope for a fix

I attached the Wireshark test of the successful PLC-DHCP-server functionality file. This time it's in ".pcapng" but it was not supported by the forum so I zipped it.

Thank you very much for your time and effort!