Changing settings

[tomaszvil]

Hello
I am using your firmware to Network Module Web_Relay_Con V2.0 HW-584, I am interested in your project.
After installing several HW-584 modules in the same network, I have a problem with them .
The HW-584 network modules change their configurations on their own without my intervention, change are mac adrr, name, IO Type and Invert Boot State, are changed to incorrect ones .
Button refresh and reboot do not restore the settings, only disconnecting the power causes a proper start to restore the settings.
It also happens that it stops working completely, there is no communication and only restoring to the initial settings (5s reset) revives the module.
When I read data from processor (settings) area of the processor, incredibly random data is stored in the eeprom.

The hw 584 network modules are connected via the MQTT protocol with Home Assistant.
Only Home Assistant controls my network modules.
I use last version NetworkModule-MQTT-Home.
router is CISCO RV042G
I bought several modules from different sellers, all of them had the same problem.
Each network module is connected to its 16 Relay Module Low Lewel Trigger.
When I used one HW-584 network module , the settings changed once in 1 months.
In my project I need to use 5 modules in different locations on the same network.
When there were already 4 HW-584 network modules in my network , the settings changed randomly in different modules, very often even twice in 3 days.
Currently, I have 2 active HW-584 network modules and I have noticed that the settings change less frequently, about once a two week, sometimes more often.
I have set an individual IP address and an individual MAC address for each HW-584 network device.
There are a dozen or so computers and about twenty IP cameras in the network
I appreciate your dedication and contribution to this project and the very detailed documentation .
Please help me solve my problem.
Sorry for my English.

Tomasz

[nielsonm236]

It isn't the HW-584 hardware, or the router. I think you are OK there. This must be a firmware bug.

I haven't seen any other reports of this problem, so we need to dig a little deeper.

1. At the bottom of the Configuration screen the firmware reports the Code Revision. Can you send a screen shot of that?
2. Are all the HW-584 modules that exhibit the problem at the same Code Revision?
3. Do you have a feel for how often the relays change state? In particular, do you have any situations where most of the relays (or all 16) are commanded to change state at the same time?
4. When you said "Button refresh and reboot do not restore the settings, only disconnecting the power causes a proper start to restore the settings" do you mean that the settings are returned to being correct just by disconnecting and reconnecting power? Or are they still incorrect?

My initial questions above are to try to understand the following:
a) If the problem is specific to an older code revision.
b) If the problem is related to hardware reset that might be caused by power glitches with many relay's switching state all at once.

Note that I have seen similar corruption of the EEPROM but only during development of code. Typically it is because I have an errant pointer that overwrites the EEPROM. I've built in a lot of code protection to prevent this, To my knowledge it hasn't occurred in the field - only in my test configurations while code is being changed. But there is always a first time :-)

OTHER USERS: PLEASE RESPOND IF YOU HAVE SEEN THIS.

It is not certain what will happen if the HW-584 modules have the hardware reset triggered frequently. That is very difficult to test, and I know that it is much more difficult to control DC power glitches when more relays are attached. There are several people using 16-relay boards successfully, so we just need to try to understand what might be different in your situation.
Mike

[tomaszvil]

Hello Mike
I am very pleased that you so interested in my problem and you trying to help me.

1. I am attaching the entire screenshot of the code version, I am using the latest available version. (screenshot)

2. All HW-584 modules have the same, latest firmware and all of them have the problem..

3. There are not many relay status changes, several times a day, several relays, maximum 4-5 at the same time, are switched on. At the same time, it turns the on or off. maximum 3 relays
   There is no rule when the HW-584 module hangs, the home assistant reports a loss of communication at different times, certainly not when the relay status changes, and sometimes loss communication when they are all turned off, there is no situation where many relays are turned on at the same time.

4. Sometimes disconnecting and turning on the power restores the settings, but it often happens that a lot of errors are saved in the eeprom memory, along with changing the MAC address or IP address, only a 5s reset restores the factory settings.

5. In my solutions, I used good quality Mean well 12v power supplies to power the relays block and I take 5v from the relays block board, photo from voltage measurement.
   Tomasz from Poland
   
   

[nielsonm236]

This is very confusing. Everything you are doing looks right.
I'm going to take my test configurations (9 HW-584 modules) back to that revision level using Home Assistant to see if I can replicate this. I don't have relays connected - just LEDs to indicate IO status.
About how long do the modules run before you see a failure?

[tomaszvil]

Hello Mike
I am very impressed with how seriously you took the topic.
When I had four HW-584 modules configured, they worked correctly for a maximum of a few days.
Now I have two modules in use, they can correctly work for 2-3 weeks, but sometimes after 2-3 days one or the other will crash.
But I will add once again that I have a quite heavily loaded network of IP cameras and dozen computers.
Although yesterday it stopped at night when the network traffic was low, and the home assistant did not switching anything.
Please advise me what else I could check. although I must say that I have been struggling with this problem for a long time, when I exhausted all my ideas, I decided to write to you
Kind regards Tomasz

[nielsonm236]

I just don't see how heavy network loading could cause a problem. If there is a very large amount of messaging through the MQTT Server/Broker it is possible that messages might get lost I suppose. But I don't see how this would cause corruption of the EEPROM in the HW-584. So I will try to get a test going within the next day.
If I can get a failure to occur I might then be able to track it down.
Mike

[nielsonm236]

I've configured 5 HW-584 devices to start running a Home Assistant test tonight. I'll add more if I don't see any replication. These first 5 devices run the "Upgradeable" version of code. Operationally this should be identical to the non-Upgradeable code, but it allows me to change code without needing to use the SWIM interface.
As FYI I've configured Home Assistant to turn on Output 1 at 5 minutes past the hour on all devices, and to turn those outputs off at 15 minutes past the hour. This is just to see what happens. I'll increase the complexity if I don't see any replication.
Also as FYI my network is fairly busy and includes 16 security cameras. Also a teenager playing video games :-)
I will keep you posted.
Mike

[nielsonm236]

While this first test runs I thought of a possible issue.
During some recent code development (not released yet) I found that the MQTT Username and Password fields might allow entry of forbidden characters. If you only use the characters that the pop-up says you can use (hover over the fields to see the pop-up) then you should be OK.

[tomaszvil]

Hi Mike
I used only allowed characters to save the password and name.
Tomasz

[nielsonm236]

Tomasz - Please email me at [email protected]
I want to be able to exchange some information about our networks and network activity that you might not want visible to the public. I'm just thinking ahead that if I can't replicate the problem we need to look deeper into what is different between your network and Home Assistant configuration and utilization that is different from mine.
Right now I think you have found some corner case in the firmware that is causing a pointer over-run when writing EEPROM. The trick will be figuring out what particular event is making this happen.
After we figure this out we can come back here and publish only the facts that might be useful to another user.
Mike

[nielsonm236]

Despite a significant number of email exchanges with @tomaszvil we've been unable to resolve the issue. I believe this to be a power glitch problem, but @tomaszvil has performed a significant number of measurements, power rearrangements, and tests and the problem persists. I am unable to reproduce in my setups, with the exception of seeing a similar problem with a degraded power supply long ago (issue #125 in Closed Issues).

I'm out of ideas.

[yozik04]

@nielsonm236 Hello Michael!
Couple days ago I've noticed a similar problem with one of the modules. I use just two at the moment for house heating and water circulation. Power to the module is fine. 5.23V almost constant. I do control just one of the relays with it during this time of the year.
The device does not crash, it still responds to port 80 but HomeAssistant tells that device became unavailable. I assume MQTT part has stopped working. Configuration page shows some junk symbols in MAC Address and I see some value changes in IO table that I did not do.
I tried to change MAC Address and fix IO table. IO was fixed but MAC Address is corrupt the same way. Interesting that even if I reboot then it starts to work for around a day then it disconnects from MQTT again.

MQTT Explorer:

Configuration after I fixed IO Table:

Note: Ignore "heat2floor" in MQTT Username. I just use same username and password for both modules.

[yozik04]

and IOControl page screenshot:

Note the difference between what is in MQTT Explorer and on this screenshot.

[yozik04]

I can try to install 20240612 to check if it will fix the problem. I can dump EEPROM Data block before that if needed.

[yozik04]

BTW NetModule calculates page length wrongly.

curl -v http://192.168.5.18/61                                                                               19:04:32
*   Trying 192.168.5.18:80...
* Connected to 192.168.5.18 (192.168.5.18) port 80
> GET /61 HTTP/1.1
> Host: 192.168.5.18
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length:04738
< Cache-Control: no-cache, no-store
< Content-Type: text/html; charset=utf-8
< Connection:close
<
<html><head><link rel='icon' href='data:,'><meta name='viewport' content='width=device-width'><style>.s0{background:red;}.s1{background:green;}table{border-spacing:8px2px}.t1{width:100px;}.t2{width:450px;}.t3{width:30px;}.t8{width:60px;}.c{text-align:center;}.ip input{width:27px;}.s div{width:13px;height:13px;display:inline-block;}.hs{height:9px;}</style><title>heat1floor: Configuration</title></head><body><h1>Configuration</h1><form onsubmit='return m.s(event);return false'><table><tr><td>Name</td><td><input name='a00' value='heat1floor' pattern='[0-9a-zA-Z-_*.]{1,19}' required title='1 to 19 letters, numbers, and -_*. no spaces'/></td></tr><tr class='hs'/><tr><td>IP Address</td><td><input name='b00' class='ip'/></td></tr><tr><td>Gateway</td><td><input name='b04' class='ip'/></td></tr><tr><td>Netmask</td><td><input name='b08' class='ip'/></td></tr><tr><td>Port</td><td><input name='c00' class='t8 port'></td></tr><tr><td>MAC Address</td><td><input name='d00' required pattern='([0-9a-fA-F]{2}[:-]?){5}([0-9a-fA-F]{2})' title='aa:bb:cc:dd:ee:ff format'/></td></tr><tr><td>Features</td><td class='f'></td></tr><tr class='hs'/><tr><td>MQTT Server</td><td><input name='b12' class='ip'/></td></tr><tr><td>MQTT Port</td><td><input name='c01' class='t8 port'></td></tr><tr><td>MQTT Username</td><td class='up'><input name='l00' value='heat2floor'></td></tr><tr><td>MQTT Password</td><td class='up'><input name='m00' value='redacted'></td></tr><tr class='hs'/><tr><td>MQTT Status</td><td class='s'><div class='s1'></div> <div class='s1'></div> <div class='s1'></div> <div class='s1'></div> <div class='s1'></div></td></tr><tr class='hs'/></table><table><tr><th>IO</th><th>Type</th><th>Invert</th><th>Boot state</th></tr><script>const m=(e=>{let t=['b00','b04','b08','b12'],$=['c00','c01'],r={'Full Duplex':1,'HA Auto':6,MQTT:4,DS18B20:8,BME280:32,'Disable Cfg Button':16},n={disabled:0,input:1,output:3,linked:2},o={retain:8,on:16,off:0},l=document,a=location,p=l.querySelector.bind(l),i=p('form'),c=Object.entries,d=parseInt,_=e=>l.write(e),s=(e,t)=>d(e).toString(16).padStart(t,'0'),u=e=>e.map(e=>s(e,2)).join(''),f=e=>e.match(/.{2}/g).map(e=>d(e,16)),b=e=>encodeURIComponent(e),h=e=>p(`input[name=${e}]`),g=(e,t)=>h(e).value=t,x=(e,t)=>{for(let $ of l.querySelectorAll(e))t($)},E=(e,t)=>{for(let[$,r]of c(t))e.setAttribute($,r)},y=(e,t)=>c(e).map(e=>`<option value=${e[1]} ${e[1]==t?'selected':''}>${e[0]}</option>`).join(''),A=(e,t,$,r='')=>`<input type='checkbox' name='${e}' value=${t} ${($&t)==t?'checked':''}>${r}`,S=()=>{let r=new FormData(i),n=e=>r.getAll(e).map(e=>d(e)).reduce((e,t)=>e|t,0);return t.forEach(e=>r.set(e,u(r.get(e).split('.')))),$.forEach(e=>r.set(e,s(r.get(e),4))),r.set('d00',r.get('d00').toLowerCase().replace(/[:-]/g,'')),r.set('h00',u(f(e.h00).map((e,t)=>{let $='p'+t,o=n($);return r.delete($),o}))),r.set('g00',u([n('g00')])),r},T=(e,t,$)=>{let r=new XMLHttpRequest;r.open(e,t,!1),r.send($)},j=()=>a.href='/60',k=()=>a.href='/63',v=()=>a.href='/61',w=()=>{l.body.innerText='Wait 5s...',setTimeout(v,5e3)},B=()=>{T('GET','/91'),w()},D=e=>{e.preventDefault();let t=Array.from(S().entries(),([e,t])=>`${b(e)}=${b(t)}`).join('&');T('POST','/',t+'&z00=0'),w()},q=f(e.g00)[0],z={required:!0};return x('.ip',e=>{E(e,{...z,title:'x.x.x.x format',pattern:'((25[0-5]|(2[0-4]|1[0-9]|[1-9]|)[0-9])([.](?!$)|$)){4}'})}),x('.port',e=>{E(e,{...z,type:'number',min:10,max:65535})}),x('.up input',e=>{E(e,{title:'0 to 10 letters, numbers, and -_*. no spaces. Blank for no entry.',maxlength:10,pattern:'[0-9a-zA-Z-_*.]{0,10}$'})}),t.forEach(t=>g(t,f(e[t]).join('.'))),$.forEach(t=>g(t,d(e[t],16))),g('d00',e.d00.replace(/[0-9a-z]{2}(?!$)/g,'$&:')),f(e.h00).forEach((e,t)=>{let $=(3&e)!=0?A('p'+t,4,e):'',r=(3&e)==3||(3&e)==2&&t>7?`<select name='p${t}'>${y(o,24&e)}</select>`:'';_(`<tr><td>#${t+1}</td><td><select name='p${t}'>${y(n,3&e)}</select></td><td>${$}</td><td>${r}</td></tr>`)}),p('.f').innerHTML=Array.from(c(r),([e,t])=>A('g00',t,q,e)).join('</br>'),{r:B,s:D,l:v,i:j,p:k}})({b00:'c0a80512',b04:'c0a80501',b08:'ffffff00',c00:'00050',d00:'��',b12:'c0a80505',c01:'0* transfer closed with 8 bytes remaining to read
* Closing connection
curl: (18) transfer closed with 8 bytes remaining to read
075b',h00:'00000303030303008880800000008000',g00:'0f'});</script></table><p><button type=submit>Save</button> <button type=reset onclick='m.l()'>Undo All</button></p></form><p>Pinout Option 1<br/>Code Revision 20231009 1022 MQTT Home ............<br/><a href='https://github.com/nielsonm236/NetMod-ServerApp/wiki' target='_blank'>Help Wiki</a></p><button title='Save first!' onclick='m.r()'>Reboot</button><br><br><button title='Save first!' onclick='m.l()'>Refresh</button><br><br><button title='Save first!' onclick='m.i()'>IO Control</button> <button title='Save first!' onclick='m.p()'>PCF8574 Configuration</button></body></html>%

[yozik04]

If I click "Reboot" button, after intermediate "wait 5 seconds" page Network module still does not communicate via MQTT. Only power circle fixes the problem and MQTT Address starts to show proper mac address. IO table also was restored to the my initial one.

[nielsonm236]

The information that some pages may not be properly sized may be a clue. I will start there. If a page is not sized properly it might cause a buffer over-run and that could lead to data corruption. Very small chance that is the problem but it needs to be corrected.

If the MAC address is corrupted it will interfere with HA. The MAC address is used as part of the device ID's.

I'm not sure how the Browser continues to work with a corrupted MAC address. The router should be very unhappy about that and shouldn't be able to find the device. But ... I've forgotten more than I remember so maybe it can still work if the IP address is unchanged.

Mike

[yozik04]

I do not think that page size is the problem. It becomes a problem only when MAC Address get's corrupt. Before that page sizes are correct.

I see when corrupt it sends next data for MAC Address:

0000000 bfef efbd bdbf
0000006

Which is 6 bytes (this might be not correct as I did hexdump from the clipboard)

But when unit works correctly it sends:

0000000 6133 6337 3130 6266 6239 6135
000000c

Which is 12 bytes.

[nielsonm236]

I think the hexdump might not be correct. A MAC address without a mix of digit and alpha characters is very unlikely.

Still the question is "how did the MAC corruption occur", because your screen captures very clearly show that did happen. Since your system operated a very long time I agree power glitching is unlikely. Now I'm thinking tha tis also true for @tomaszvil. A buffer over-run can corrupt just about anything, depending on where the compiler placed those things in RAM. So I agree it is a long shot.
Interesting that the page size is valid until the corruption occurs. The corruption of the MAC address might cause this if the resulting MAC content is a not-allowed "character" in HTML. I will still transmit all 12 bytes of the MAC, but the receiving Browser will toss not-allowed bytes and not count them in the received page size (just as it does with extra spaces). At least I think that is what happens. This is going to be very difficult to find.
I will have to go back and look at what I changed in the 20231009 release. To your knowledge you didn't have any problems prior to that release?
Some things that might cause problems that could explain why I don't see it, but you and @tomaszvil do see it:

• The Configuration itself, in particular with use of MQTT Username and Password. I don't use Username and Password.
• I recall fixing the filtering around Device Name, MQTT Username, and MQTT Password.
• I have "barely tested" code for a Software Defined Radio project and for Browser Login ID. Both requestors evaporated before helping with test. All that code is fenced with #if statements, but it is possible some change did not get fenced and is causing a problem. Or, some allocation of resource shifted RAM locations about and exposed a latent problem.

First I need to see if I can get this to reproduce so that I can add some debug. We may have to exchange some information by private message so I can set up a duplication of your Configuration in greater detail.

Mike

[yozik04]

Regarding "Browser will toss not-allowed bytes". This can't be true as I was using curl command line tool to capture what HTML I am getting and verify if packets received are full. Curl clearly tells that received byte count is different from what was sent in ContentLength header. Next time I will pipe curl output to hexdump to see what exactly is there. Maybe will use wireshark to capture TCP packets as well.
My module worked on 20231009 firmware since it's release. So it is at least half a year without any issues. Suddenly I got this corruption three times in a period of couple days. After power circle it worked for some hours (4-6) and got corrupted again. After Monday's power circle and settings update It still works without issues (23 hours has passed).
I do not think that the problem was introduced in 20231009 because I've seen some corruption of settings using previous releases as well. No idea what can be the cause.

[nielsonm236]

OK. Now I'm completely baffled again. It ran fine for months then started to repeatedly have a EEPROM corruption problem? Thinking out loud to see if it provokes any ideas:

1. Could be some aliasing issue causing a buffer over-run. But this should be completely random and won't just start occurring repeatedly after months of no issue.
2. Maybe some network activity issue that wasn't there before. I'm aware that the hardware filtering in the ENC28J60 still lets a lot of network probing activity through. Firmware then filters out the bogus activity that the ENC29J60 did not filter. Could there be too much bogus activity? Perhaps. But firmware should just start dropping messages if overrun. It may be that there is a leak in that process that causes a buffer over-run. As an FYI, the "bogus activity" I've seen seems related to Microsoft Windows probing the network for resources, and Smart devices and Alexa dots probing the network for devices. And other probing activity that I think is coming through from the Internet. Sometimes there is just a huge storm of this going on.
3. There aren't any cumulative processes going on in the firmware. I could search to re-verify that there aren't any counters that can roll over and cause an issue. But even if there is one, it should cause a problem ONCE, then after a reboot it would be many months again before the problem resurfaces. So, that can't be it.
   3a) Well, OK the Link Error Statistics output accessible via the /66 command has two counters. They should just roll over at max count. Might be useful to see if anything is showing up there. Like a Stack Overflow.
4. There is always the power noise issue ... that was actually a very repeatable source of corruption that I had in my own test bed. Cheap power supplies can slowly go bad over a long time (which is the problem I had).
5. Is it possible something is repeatedly writing the EEPROM and wearing it out? I've been very careful to avoid that. My test bed has far exceeded the specs for EEPROM and Flash writes, and still I don't see the corruption issues. And if this is a wearout problem, you've seen corruption in the past but then the problem goes away. That's not EEPROM wearout.
6. Over-heating of the STM8 processor might cause processor timing issues and EEPROM/Flash write issues. And those issues could be transient. I have been suspicious of this because of the fact that the STM8 is 3.3V, and users regularly want to hook up 5V logic. If done correctly it is no problem. If done incorrectly it will cause thermal issues, and at worst device failure.
7. Is it possible some part of the Flash has become corrupted, and reloading the firmware will correct it? Seems unlikely Flash could have any corruption but the code still runs. The Link Error Statistics /66 page includes an ILLOPF counter to expose hardware detection of an illegal opcode. Might be a clue.

If we can think of any instrumentation to confirm or reject a suspect issue let's do it while you are seeing the problem.

Mike

[nielsonm236]

Regarding ""Browser will toss not-allowed bytes" I'm running on recollection here which could be faulty. I know that if I code a string with multiple spaces in a series it will appear at the Browser as a single space. I can't remember where the spaces are concatenated .... perhaps just in the Browser itself. I also vaguely recall that if I sent bytes outside of the Browser character set they can cause problems. But I don't know if that will affect receive count or not.

Notes on MAC adddress storage:
The MAC address is stored as 6 uint8_ bytes in the EEPROM. This is used in most processes throughout firmware, and is also stored in the ENJ29J60. But the MAC is also stored as 12 hex characters in a string in RAM for use in display functions and in generating MQTT IDs. This could explain why some connections persist (those using the uint8_t bytes), and some fail (those, like MQTT, using the MAC string).
So it is possible the EEPROM is not being corrupted, but the MAC string IS being corrupted in RAM.
Again, thinking out loud.
Mike

[yozik04]

It is a great list of potential places for looking.
2. Network activity: can be. I have many different devices but no new ones. Actually couple of Android phones I gave to kids with custom firmwares... But let's see if the issue will reappear.
3a. I will get statistics when/if it will crash again. Interesting to see what is there when it is with corrupt MacAddress.
4. Will try a different higher quality power adapter after next crash. That was my initial assumption but when I measured the voltage on that I decided to keep it. It produces sound but still works. It produced sound a year back as well =)
5. I intentionally do not use retain boot state flag.
6. It is in a closed box with some holes for cables only. Will measure the temperature in the evening.

Regarding MacAddress storage. I also think that MAC string IS being corrupted in RAM. Because when I power circled last time the unit MacAddress reappeared in the Configuration page intact.

Something different happened this time. I will create a separate issue not to pollute this one. #228
State in MQTT Explorer is equal to what I see in IO Control page.
I do not see corruption in MacAddress this time. MQTT Broker still receives temperature data. Configuration page does not show any corruption. Content-Length equals with the size received.

So this is not the crash we are looking for...

From the page /66:
3a) Link Error Statistics:
31 0000139361
32 0000021198
33 ff5c864594
34 0180000000
35 0000000001

I clicked reboot and availability has restored to online again.

Nothing to do, let's wait if it will eventually crash.

[nielsonm236]

My interpretation of the Link Error Statistics report:
Line 31 is "Seconds Since Reboot", so this device has been running over 38 hours. The counter should not roll over for 317 years.
Line 32 is the "Number of ethernet transmissions" from the device since power on or reboot. Same 10 digit rollover count.

Line 33 is very concerning.

• The first two bytes should always be zero. I will look into how they could possibly have any other content.
• The byte that says "86": "8" indicates a Stack Overflow occurred at some time. "6" is the ENC28J60 revision and is correct. The Stack Overflow indicator is retained through power cycles so it could have occurred long ago. It can be cleared with URL /67.
• The "45" is the transmit error counter. This seems high. This is cleared at power on / reboot so this is very unusual.
• The "94" is the receive error counter. This seems high. This is cleared at power on / reboot so this is very unusual.
• The error counts are not necessarily TOO high. I treat them more as a symptom than a clear problem. You can clear them with /67 then check with /66 to see if they are incrementing slowly (probably not a problem) or very fast (probably a real problem). One every few minutes is probably not a problem.

Line 34:

• The "01" suggests an unexpected power loss but might have occurred long ago. I don't think the detector is very reliable.
• The "80" is the number of times the device has been reprogrammed via the SWIM interface.
• The rest of the line indicate there have been no Illegal Opcodes or Watchdog timeouts. This tells me the Flash is not corrupted.
• The counters in Line 34 are cumulative and are retained through a power cycle / reboot. They can be cleared with URL /67.

Line 35:

• Indicates no MQTT errors, but the Broker sent a disconnect message one time since power on / reboot.
• Line 35 counters are cleared at power cycle / reboot or with URL /67.

To get a better view of "what has happened since we started testing" I'd suggest using command /67 to zero out the counters. That way we will eliminate the "long ago" history and see what is affecting operation right now. I recall you are using a Cisco business class switch, which is why you have Full Duplex enabled. I also recall we would see somewhat higher transmit and receive error counts with that switch, but what is shown above is much higher than I would expect even with the Cisco switch.

Mike

[yozik04]

Uhh, so professional. You are developing like for satellites to launch into the space =)

No, I am not using a Cisco Business class switch. NetModule is connected to some cheap TP-Link TL-SG105E Gigabit Switch which is connected through another switch to the main router. I can disable full duplex if needed, this should work in both modes, I think.

Some years ago one power block has already died with that module, maybe this is why we see unexpected power loss.

Both modules I have are configured to Full Duplex mode, both have DS18B20 temperature sensors attached (first one has 4, second one has just 2). Settings are the same only number of configured IO output's differ.

Before writing here I used "Oxide clean & Protect liquid" to make sure ethernet cable connectors have good contact. But if you say that tx/rx error rates are reset after every reboot then errors before cleaning should not be included.

I have drilled some holes in the box to let some fresh air in. But both chips on the board were not hot to touch. My infrared temperature sensor showed ~50 degrees celsius on the main chip. Anyway, will be cooler now.

Here are both /66 pages of my both modules before reset if we want to compare.
Module 1:

Link Error Statistics
31 0000024920
32 0000004033
33 ff5c864594
34 0180000000
35 0000000000

Module 2

Link Error Statistics
31 0000752880
32 0000064662
33 0000860000
34 0000000000
35 0000000000

Now I cleared counters on both devices and rebooted them both.

Initial states are almost equal (only 32 differ a bit):

31 0000000149
32 0000000050
33 0000060000
34 0000000000
35 0000000000

Will recheck what are error rates tomorrow. 20 minutes has passed and still zero.

[nielsonm236]

Full Duplex shouldn't be used except with those Cisco business class switches.

The ENC28J60 isn't supposed to work very well in Full Duplex. It has bugs in the auto-negotiate hardware, so the specs recommend half-duplex. The only reason Full Duplex was allowed in my firmware is that is seemed to work a little better with the Cisco switch IF the user also forced the port on the Cisco switch to Full Duplex (no auto negotiate). So, having it set to Full Duplex is probably causing some of the network errors, particularly when network collisions occur (which is really a common thing on busy networks).

At the present time I have no space launches planned. ;-)

Mike

[yozik04]

Uhh, I should have studied the manual more diligently. I have disabled Full Duplex on both modules now, restarted and cleared the counters one more time. Will see how it will go. Thank you for all the help.

[jmcvieira1]

Hello guys
I'll contribute my two cents, as I already had exactly the same EEPROM corruption problem with one of the modules on my test bench, and it was a bad contact on one of the power wires.
I have a module with the same firmware running outside my house inside a PVC box in the sun. This module only controls an electrovalve and monitors the status of the water well motor, as well as the temperature inside the box.
Here are the errors:
Link Error Statistics
31 0007736224
32 0000427905
33 0000860000
34 0000000100
35 0000000000

Thinking out loud:
I see this as being a hardware/power issue.
If the module worked well for months, what has changed now to start showing these faults?
Did the temperature increase?
Has some of the hardware degraded over time?
If the firmware is the same, shouldn't the same symptom have already manifested?
Or would there not be other modules showing the same symptom?
What is so special about this module that it has only now presented this error?
If it's not a power supply problem, could it be an electromagnetic interference problem?

J. Vieira

[nielsonm236]

I hope either switching to Half Duplex or changing the power module gets this back in shape. Otherwise this will be a bugger to figure out. It is interesting that it is so similar to the @tomaszvil report. But he worked very hard on trying to get it working and had no success. I would love to have been at his location to help him track it down. But ... he is 5000 miles away.

The problem with power is that it is not just average voltage level like you see with a meter, but high-frequency noise spikes that you could only see with a high-bandwidth scope, and then only if you get lucky enough to catch it. I found a very stable Lambda industrial power supply to run my test bed. But I still use cheap wall wart power supplies for devices scattered around the house.

[jmcvieira1]

I forgot to mention that the green led was on, and the orange led blinked normally, both before and after I disconnected the network cable, I also forgot to mention that this module is connected to a gigabit switch D-link DGS-1024D.
I'm going to leave the module connected and i will not make any changes, If it happens again that the module stops responding via LAN, is there anything else I can check? the module is close to my personal computer I can connect the st-link programmer to it...

[nielsonm236]

Once it stops responding there really isn’t any way to access RAM error counters. About all we can do is run /66 frequently in hopes of capturing meaningful data. But so far even that has not worked well.You have other modules with older code that are still working on the same network, right? If yes then I think the broadcast filter is causing the problem.Sent from my iPhoneOn Sep 9, 2024, at 5:08 PM, jmcvieira1 ***@***.***> wrote: I forgot to mention that the green led was on, and the orange led blinked normally, both before and after I disconnected the network cable, I also forgot to mention that this module is connected to a gigabit switch D-link DGS-1024D. I'm going to leave the module connected and i will not make any changes, If it happens again that the module stops responding via LAN, is there anything else I can check? the module is close to my personal computer I can connect the st-link programmer to it... —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jmcvieira1]

Yes, I have ten other modules in my house working with the "normal" Home and Domo firmware.

[nielsonm236]

@jmcvieira1 OK - I will get to work to make the "broadcast filter" a URL commanded option. It will normally be turned off (so there is no filtering) and hopefully you see your test module become stable again. If you do, it will tell us the broadcast filter should not be used. Unfortunately it will also mean we are no closer to a solution for the @tomaszvil and @yozik04 disconnects.

[jmcvieira1]

Hello the module in question stopped communicating again today at 2:10 PM
I got home now and I can't access the web gui again.

[nielsonm236]

@jmcvieira1 I'm running some tests on a modification that lets you turn off (or on) the Broadcast filter. That is supposed to be the only major difference between the old code and the new code. If my tests are successful I will post the Domo BME280 version. Since your test case seems fairly repeatable maybe this will tell us if that is the cause of your loss of connection ... or if I have some other defect in code.
Mike

[nielsonm236]

@jmcvieira1 Jose - I've attached a Code Uploader and Domo BME280 build. This will let you turn on/off the Broadcast filter so we can determine if the disconnect you are seeing is related to that filter. URL /6e will turn ON the filter. URL /6f will turn OFF the filter. Executing either command causes a reset. If you load the code the filter should default to OFF, but you can run URL /6f to be sure it is off.
20240910 Viera Domo TEST.zip

[jmcvieira1]

Hello
the command is working correctly, I'm going to put the module to the test, and let's see what happens.
Thank´s
J. Vieira

[nielsonm236]

@jmcvieira1 Privately messaged me with his results, which really only showed (as expected) that if the Broadcast Filter is turned on there are significant delays in response time to ARP requests, and when the Broadcast filter is turned off the responsiveness problem goes away. I think we need to let the @jmcvieira1 testing continue to see if he loses connection over a longer period of time with the Broadcast filter turned off. He asked a couple of questions, and I responded with the following:

What you are seeing is not what I originally expected, but it is similar to what I'm seeing as we have made progress. The exception is that I never get a complete disconnect even if I have the Broadcast Filter turned on.

You may already know this (or some of it). Broadcast messages can be used for several purposes, but the most common usage is to implement the Address Resolution Protocol (ARP). On a local network the IP address is not used to actually communicate over Ethernet. Instead the MAC address is used. But hosts need a means of determining which MAC address is associated with which IP address. So a Broadcast ARP Request is sent by the host to everyone on the network asking "Who owns IP xxx.xxx.xxx.xxx and what is your MAC address?". The device that owns the IP address generates a ARP Response identifying its IP/MAC pair, and after that point the Host can communicate with the device using the MAC address. All Hosts (and switches) see these transactions and each maintains an ARP table so that they don't need to send a Broadcast message UNLESS they attempt communication with a supposedly known MAC address and get no response. Then that host will send a new Broadcast ARP request.

Another way that a device can let everyone know it's IP address and MAC address is to generate a "Gratuitous ARP Response (GARP)" without any host asking for it. All hosts and switches are supposed to see this GARP and add the IP/MAC pair to their ARP tables.

Our recent experimentation with the Broadcast Filter was based on an assumption that something on the tomasvil (and the yozik04) networks was generating too many Broadcast messages of some kind. With the Broadcast Filter turned off the HW-584 firmware must identify and throw away all Broadcast messages that are not needed. If there are hundreds per second the firmware can't keep up. So, an alternative is to turn on a Broadcast Filter in the ENC28J60 and let the hardware throw away ALL Broadcast messages. This takes the load off of the firmware, but it then requires that the HW-584 generate a GARP so that all hosts know the IP/MAC pairing. When the Broadcast Filter is turned on the firmware sends a GARP every 10 seconds.

BUT - something is going wrong in this process when the Broadcast filter is turned on. If in fact all the switches and hosts are seeing and processing the GARP messages from the HW-584 we should not be seeing any delays in responses exceeding about 10 seconds, and that 10 second delay should only exist when the ARP tables have timed out (usually after 4 hours). But GARP is definitely working to some extent or we would NEVER be able to connect at all. I cannot explain why it does not work smoothly as I have implemented per the spec (I think).

So ... I'm thinking the Broadcast Filter / GARP method is hurting more than it is helping. If we must turn off the Broadcast Filter, which also returns us to the Traditional ARP method, we are basically starting over trying to figure out why the HW-584 doesn't work in the tomasvil network, and why yozik04 saw disconnects.

Reviewing the original symptoms reported in both networks the symptom that is most disturbing is that some RAM corruption was being seen. I've added debug around my primary suspect for RAM corruption (ethernet message buffer pointers), but so far we haven't seen a capture. I should note that I performed an experiment that attempted to flood the ENC28J60 with Ping Requests. And ... I saw a couple of RAM corruptions. This experiment was run before I added the buffer pointer debug code, so I should run the experiments again. And I should also add that I know I've seen RAM corruption when I had a very noisy / failing power supply.

If we can eliminate power as the source of the problem I think we are left with "Some networks are simply too active for the ENC28J60 and firmware to keep up". That might be the case for tomasvil (no proof yet), but I doubt it is the case for yozik04 (but also no proof).

[tomaszvil]

I am sending the noticed lack of communication with HA from the last ten days.

I will mention that when I notice offline mode I disconnect the power supply again

in the last ten days I have not noticed any changes in the settings in the eeprom area, after reconnecting the power supply the previous settings are restored.
usually as long as it does not stopped communicating it does not report errors
I have 4 HW584 connected and registered in HA

I have one additional one which is not registered in HA with Code Revision 20240901 TEST MQTT Home, it is only on the network and from time to time I check the communication via the browser, it can stop communicating two or three times a day.

Tomasz

[nielsonm236]

@tomaszvil First a general comment from me: I think the Broadcast Filter hasn't solved anything, and may be adding additional confusion to our test results. I will eliminate it in further test releases. But, that takes us back to where we were a couple of months ago.

Regarding "I have one additional one which is not registered in HA with Code Revision 20240901 TEST MQTT Home, it is only on the network and from time to time I check the communication via the browser, it can stop communicating two or three times a day." A device that is not accessed via your Browser for a period of 2 to 4 hours may be removed from the ARP tables of your host and your switches. With the Broadcast Filter turned ON it can take several attempts before a connection will occur. On my network (which is apparently a "quiet" network) I have seen this take up to 10 attempts, and I had one case where it seemed I could not access the HW-584 at all after many attempts, but 20 minutes later I was able to access it. In your network (which we suspect is "very busy") perhaps this problem is made much worse as attempts to re-establish the ARP tables may have a lot of interference from network activity. For this reason I think the Broadcast Filter is a bad idea. I don't think this will affect the MQTT Broker once the ARP tables are configured because MQTT pings should be keeping the ARP tables refreshed.

So, we are back where we started. The rest of your tests illustrate that there is loss of MQTT communication across several older versions of firmware. As your situation is relatively unique (except that @yozik04 also is having a problem), then the common elements in your test are: a) The firmware itself may have a latent defect that appears in all of those releases that is provoked in your hosts / network / HW-584 configuration, b) The level of network activity overwhelms the hardware / firmware of the HW-584 (simply not enough processing power and memory resource), c) Power supply may still be a contributor.

Did you try your power supply from home with one of the older firmware levels?

[nielsonm236]

@tomaszvil Back on July 28 I suggested running the Browser Only version of code on a HW-584 on your network. It could give us some additional information about network conditions using the Network Statistics report with URL /68 command. I don't think I ever saw a reply with these statistics from your network.
Attached is the latest Browser Only code with Broadcast Filter turned off. You will need to run /68 before the device succumbs to whatever problem is causing the failures. Several samples over time would be useful.
20240910 Browser TEST.zip

[tomaszvil]

I will test this version tomorrow.
Tomasz

[nielsonm236]

Just for reference, this is what I collected from my network after running about 9 hours:


On my relatively quiet network I am surprised at the number of Broadcast packets (about 4 per second). I don't know all the sources, but I investigated long ago and found most were coming from the "Smart" devices on my network.

[tomaszvil]

after about 4 and then 7,10 hours
Tomasz
netw_stat.txt

[nielsonm236]

Your test results take us in a whole new direction. The counts suggest that the Broadcast traffic is actually very low. Even lower than on my network. However, the "Packets dropped due to wrong IP dest address" is exceptionally high, occurring about every two seconds. On my network I see this every 5 or 6 minutes.
The following contain counts that are interesting, but fairly small numbers. I suspect this is due to traffic volume and collisions.
Packets dropped since they were IP fragments
Received TCP RST (reset) segments
SYNs for closed ports, triggering a RST

Despite "Packets dropped due to wrong IP dest address" being a very high count I don't think it should cause a problem. But because it is very different from anything I've seen I should take a closer look and try to figure out what it is. I will examine the code, but in general it indicates that something on the network is trying to send a packet to the HW-584 MAC address, but it is using the wrong IP address. When I would see it on my network I thought it was just some Microsoft network probing and I ignored it. But with your counts so high it might be something more significant. Maybe I can build a tracker that will tell us the sender IP/MAC values, and from that we can determine what is going on.

I will research and let you know what this might be. If you have Wire Shark expertise you might figure it out faster than I do. FYI, I do not have "Wire Shark expertise", but I have played around with it.

Mike

[nielsonm236]

@tomaszvil Half of all packets received contain the wrong IP Destination address. Is it possible there is another device on the network with the same MAC address?

As FYI I've been searching the internet for a plausible explanation and not finding anything that looks promising. Are you running UPG code, or so you program via the SWIM interface?

[tomaszvil]

I have UPG code :
Pinout Option 1
Code Revision 20240910 TEST Browser UPG ..........
I am careful not to duplicate MAC addresses.
In my LAN i have LAN (10.0.0.x) and VLAN (192.168.1.x)
I think that the cause of the wrong IP Destination address may be caused by a second addressing in the network

Maybe not everything is configured perfectly, but all other HOSTs in the network are working properly except HW584
the network has been working properly for several years without any problems.
I can later disable the additional network 192.168.1.x for two days for testing, but I have to think about a convenient time.
Tomasz

[nielsonm236]

@tomaszvil
I haven't personally seen a network configured that way, but there isn't anything wrong with it. All LANs are really VLANs, but generally people think of their main VLAN as "the LAN", and anything they add is a VLAN. But the same routing code handles all of the address space.
My home network has four VLANs: 192.168.1.x, 192.168.20.x, 192.168.30.x, 192.168.40.x. I use all of them. All of the VLANs are serviced from a single router using DD-WRT firmware.
Keep in mind that within a network all communication uses the MAC addresses. PEOPLE use the IP addresses, so the devices, hosts, and routers have to keep track of the association of IP and MAC addresses. So if there is a configuration issue in the network it would have to be that the MAC address appears in a router table twice ... once with one IP address and once with different IP address. Or the MAC address appears in the router tables of two different routers each mapped to a different IP address. OR there are several much less likely conflicts going on (Google provides some possibilities).

Questions: Do you have two different routers? One for 10.0.0.x and one for 192.168.1.x? Or is it a single router? Is the HW-584 within the DHCP address range of the router(s)? Or is the HW-584 statically assigned with the router(s)? We just need to make sure that you don't have the HW-584 MAC address mapped to a 192.x.x.x IP AND to a 10.x.x.x address.

If the HW-584 MAC is statically assigned and only appears one time in the router tables, then the use of 10.x.x.x AND 192.x.x.x on the same ethernet should be just fine. I do the same thing with multiple VLANs although all within a 192.x.x.x address space.

So, if the router MAC tables are fine (even if two routers), what else could cause a MAC destination to be messaged with an incorrect IP destination address? I'm not sure, but as I mentioned I also see this on my network but I see it very infrequently. Online research suggests packet corruption could cause this, but I find that unlikely in this case. Perhaps some kind of auto-discovery process running on a host? I don't know what that could be, but I do know there are apps that can scan a network and associate all MAC addresses with their IP addresses, so this kind of process exists in the world. But I think those apps use normal ARP response mechanisms, and that would not send a packet to the HW-584 with an invalid IP address. Perhaps an external scan from the internet making it through your firewall? Unlikely. I will continue researching the possibilities.

Let me speculate that all the other HOSTs are also seeing this issue (lots of invalid IP Destination addresses). They may be able to handle it because they have virtually infinite processing power compared to the HW-584, and the only effect would be degradation of network performance. Even the HW-584 might be handling this OK (especially with the Browser Only firmware), as the test you ran only shows an event every two seconds. But if these events are greatly increased when we go back to MQTT firmware with MQTT traffic it might be a problem. So, it is worth understanding it even if it ends up being a dead end.

[nielsonm236]

@jmcvieira1 Is your test still running OK now that the Broadcast Filter is turned off?

[jmcvieira1]

Yes, it is working fine, since I installed the new firmware and selected Broadcast Filter off.

[jmcvieira1]

Update
sixteen days ago I placed a module with the test firmware Code Revision 20240901 TEST MQTT Home UPG ........ in service in my basement it has a temperature sensor and has reported the temperature via mqtt regularly without any failure.
This module is connected to an old 10/100 switch together with two IP cameras.

[nielsonm236]

@jmcvieira1 With the 20240901 TEST version, which has the Broadcast Filter turned on, you will probably find that the Browser has trouble connecting. Usually I could get a connection after only 1 to 3 attempts. But I had one instance when I tried over 10 times and gave up. Then when I came back and tried again after about 20 minutes the device immediately responded. So don't be too surprised. As we move forward we should abandon the Broadcast Filter.

[nielsonm236]

@tomaszvil I need to retract a part of what I said about my network having 4 VLANs. I DO have 4 VLANs, but with the DD-WRT firmware in my router each of those VLANs are on separate ports of the router. So they do not concurrently share the same ethernet hardware paths.
I'm adding some code that will let me re-investigate the "incorrect IP destination address" situation I see infrequently on my network. That additional code is not something you can easily use without attaching a device to utilize the "diagnostic UART port" on IO 11, but it might give us an additional clue just from what I find on my network.
Mike

[nielsonm236]

@tomaszvil I added some additional debug code to determine the source of the "incorrect IP destination address" counts being generated on a HW-584 device on my network. The debug I added shows the following:

• On my network the messages all have a non-ARP "local broadcast destination address (192.168.1.255).
• The Source addresses are all devices on my network. All of these devices are generating the "errant" messages:
  Four Windows 10 PC's (my laptop, a test server, Security Cam Server, a Domoticz server)
  One Windows 11 PC (HA/MQTT Server)
  One Cisco E4200 Access Point
  DLink Print server
• Based on the Port numbers being used the messages are all UDP NetBIOS Name Service or NetBIOS Datagram Service (ports 137 and 138). I don't respond to these messages ... and I don't know if that drives the sending servers nuts or not.
  So, these messages are not errors at all.
  The fastest way for me to generate the debug reports is to use the UART function. That requires addition of hardware to turn IO 11 into a UART for debug message output. I will look into whether I can create some kind of internal debug logging on devices that have the I2C EEPROM attached (those devices using UPG code). That might enable us to see if there are any other processes generating these non-ARP Broadcast messages on your network.
  Mike

[tomaszvil]

In my network I have only one router,
HW-584 within the DHCP address range of the router
I built my network a few years ago and everything worked until I started my adventure with HA and HW-584
I have several other network relays connected to the network and they work properly.
I don't know if solving the address mix-up on one physical wire is unacceptable but it works for me.
below a very simplified outline of the concept of my network.

unmanaged switch
maybe someone will comment on whether this solution is forbidden according to the construction of the network...
devices on the network do not have duplicate mac address
after 7 days Browser Only version of code on a HW-584 with Code Revision 20240910 TEST Browser UPG
so far for 7 days the version works stably without any changes (interesting and in my opinion puzzling) because at the same time the mqtt versions went offline several times- I'm waiting further.
below cyclic reading of statistic.
netw_stat.txt

Tomasz

[nielsonm236]

As already mentioned the "Packets dropped due to wrong IP dest address" is curiously high. I've always assumed your network was mostly Linux, but I don't think you ever actually mentioned that to me. Some Linux devices use NetBIOS, but most don't. Maybe Linux devices are generating some similar traffic.

You mention that the HW-584 is within the DCHP range - but it should not be since it has a static IP address. It could still work, but the risk is that the address gets assigned to another device by DHCP.

I'm puzzled at how DHCP assigns addresses to a PC or Server on your network. If there are two DHCP servers (one for 10.x.x.x and one for 192.x.x.x) when a PC or Server joins the network how do the DHCP servers know which one of them is supposed to assign an address to the new device? Or is it actually the case that all your connected PCs and Servers have been given static addresses in one range or the other?

[nielsonm236]

Here are two links that talk about DHCP and Static IP Addresses.
https://superuser.com/questions/900074/does-the-dhcp-server-know-about-static-ip-addresses-set-in-end-devices
https://serverfault.com/questions/906041/assigning-a-fixed-ip-address-to-a-machine-in-a-dhcp-network

Since the HW-584 must use a static IP address, then you have two choices:
a) The HW-584 IP address must be outside the range of the DHCP server
OR
b) The DHCP server must support IP Reservations within the DHCP range, and you've configured that within the Router.
Note that the MQTT server (and I think the HA server) also require static IP addresses.

An aspect of DHCP provided IP addresses is that they have a "Lease Time". This means that when the least time expires the IP address needs to be re-established, and if there are clients (HW-584, MQTT server, etc) that require a static IP assignment but they are in the DCHP range without a IP reservation then they could end up in conflict with another device that claimed the IP address at lease expiration.

If it has been a while since you set up your network you may have forgotten that you need to do (a) or (b) above when you set up the MQTT and HA servers and the HW-584 devices.

If you don;'t mind: What is the Router model number? I'll go look up whether it supports IP Reservations.

[nielsonm236]

@tomaszvil Just checking in to see if you had any further progress or results.
Also, I have created a new tool to allow capture and display of debug information in a Browser session. It is currently coded to capture and display information about local broadcast packets. While that may not be the problem you experienced it is the only anomaly we've been able to identify so far. The output looks like this (from my network):

0000000031 Start Diagnostic Log
0000000069 uip.c: drop wrong dest address. SrcIP=c0a80173 DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000000132 uip.c: drop wrong dest address. SrcIP=c0a80173 DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000000137 uip.c: drop wrong dest address. SrcIP=c0a8012d DestIP=c0a801ff Prtcl=017 SrcPort=00138 DestPort=00138
0000000193 uip.c: drop wrong dest address. SrcIP=c0a80173 DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000000194 uip.c: drop wrong dest address. SrcIP=c0a80173 DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000000257 uip.c: drop wrong dest address. SrcIP=c0a80173 DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000000282 uip.c: drop wrong dest address. SrcIP=c0a80168 DestIP=c0a801ff Prtcl=017 SrcPort=00138 DestPort=00138
0000000317 uip.c: drop wrong dest address. SrcIP=c0a80173 DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000000330 uip.c: drop wrong dest address. SrcIP=c0a8016b DestIP=c0a801ff Prtcl=017 SrcPort=00138 DestPort=00138
0000000410 uip.c: drop wrong dest address. SrcIP=c0a801af DestIP=c0a801ff Prtcl=017 SrcPort=00138 DestPort=00138
0000000410 uip.c: drop wrong dest address. SrcIP=c0a801af DestIP=c0a801ff Prtcl=017 SrcPort=00138 DestPort=00138
0000000414 uip.c: drop wrong dest address. SrcIP=c0a8012d DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000000415 uip.c: drop wrong dest address. SrcIP=c0a8012d DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000000415 uip.c: drop wrong dest address. SrcIP=c0a8012d DestIP=c0a801ff Prtcl=017 SrcPort=00137 DestPort=00137
0000001569 uip.c: drop wrong dest address. SrcIP=c0a8012d DestIP=c0a801ff Prtcl=017 SrcPort=00138 DestPort=00138
0000001718 uip.c: drop wrong dest address. SrcIP=c0a80168 DestIP=c0a801ff Prtcl=017 SrcPort=00138 DestPort=00138

The numbers on the left are a timestamp (seconds since boot). In my network these are all NetBIOS messages.