NetBurner Community Forum

I am really an embedded programmer and not well versed in networking. It's a testament to the product that we were able to bring up an SNMP agent so rapidly given my lack of networking experience (I'm really a physical/link layer guy). However we ran into an issue with a customer where a customer noticed the network connection between their management system and our agent was hanging after roughly 4 minutes of Pinging, around 250 pings. I found that the problem was related to the network mask setting (the customer's host was set to 255.255.255.0, and our agent's was set to 0.0.0.0) once I set up the network mask on our agent to 255.255.255.0 the problem went away. Speculating it makes me think that maybe the issue is related to some sort of credits mechanism or a message queue overflow, but given my lack of networking experience I don't have a satisfactory grasp on the root cause. Can anyone help to explain this behavior? I am currently researching the relationship between the IP address and the network mask, I need to have a better grasp of the application rather then just the lower level development, but I don't want to spend too long on it as my focus remains on hardware not networking.

The mask should match for a variety of reasons,
but I don't think its related to the ping stopping.

Wee the two boxes connected to the same hub?
Were there any routers involved?

Could you still find the device with the ipsetup tool?

I've seen firewalls do this, ie they allow some communication, but when it exceedes some threshold they decide
its bad and turn off the connection.

Thanks, in our lab we were connected via a dumb hup (no DHCP server) with the IP addresses statically defined our agent was set to 10.203.0.186, network mask 0.0.0.0 and default gateway 0.0.0.0 and the server was connected to 10.203.0.185, mask 255.255.255.0, gateway 10.203.0.100. There were two ways to fix the issue:

set the resective IP addresses to 192.168.1.2 and 192.168.1.3 or using the old IP addresses changing th network mask of our agent to 255.255.255.0. the reason for the strang IP addresses is that the firmware initially attempts to get an IP from a DHCP server, and if that fails reverts back to the last known IP address, and the 10.203.0.186 IP address happens to be the one that our network originally assigned the agent too.

Brian