What is this PANIC error?

I don't understand this error that pops up from time to time in the error log. I do NOT have any device at 192.168.1.24, so why does it seem like it wants to write to that? I have two HDHR's, and one is at 192.168.1.25, and the other at .29. My RB pi 4b server is at .33

I'm running server: 2023.02.28.2326

Anybody know?

2023/03/15 10:55:50 [Recovery] 2023/03/15 - 10:55:50 panic recovered:
write tcp 192.168.1.33:8089->192.168.1.24:49541: write: no route to host
github.com/gin-gonic/[email protected]/render/json.go:58 (0x9defcf)
github.com/gin-gonic/[email protected]/context.go:899 (0x9e3e43)
github.com/gin-gonic/[email protected]/context.go:942 (0x151307f)
github.com/fancybits/channels-server/http_device.go:369 (0x151303c)
github.com/gin-gonic/[email protected]/context.go:169 (0x1512fb7)
github.com/fancybits/channels-server/http_device.go:360 (0x1512edc)
github.com/gin-gonic/[email protected]/context.go:169 (0x151074b)
github.com/fancybits/channels-server/http_device.go:87 (0x151066c)
github.com/gin-gonic/[email protected]/context.go:169 (0x14fe60f)
github.com/fancybits/channels-server/http.go:273 (0x14fe338)
github.com/gin-gonic/[email protected]/context.go:169 (0x14fe29f)
github.com/fancybits/channels-server/http.go:250 (0x14fe27c)
github.com/gin-gonic/[email protected]/context.go:169 (0x14fe167)
github.com/fancybits/channels-server/http.go:242 (0x14fdbc0)
github.com/gin-gonic/[email protected]/context.go:169 (0x9ebeab)
github.com/gin-gonic/[email protected]/recovery.go:107 (0x9ebe8c)
github.com/gin-gonic/[email protected]/context.go:169 (0x9eb19b)
github.com/gin-gonic/[email protected]/logger.go:240 (0x9eb178)
github.com/gin-gonic/[email protected]/context.go:169 (0x1086b47)
github.com/gin-contrib/[email protected]/sessions.go:65 (0x1086b28)
github.com/gin-gonic/[email protected]/context.go:169 (0x1080ed3)
github.com/gin-contrib/[email protected]/gzip.go:47 (0x1080ea4)
github.com/gin-gonic/[email protected]/context.go:169 (0x14feeb3)
github.com/fancybits/channels-server/http.go:363 (0x14fee94)
github.com/gin-gonic/[email protected]/context.go:169 (0x9ea2ef)
github.com/gin-gonic/[email protected]/gin.go:598 (0x9e9fd8)
github.com/gin-gonic/[email protected]/gin.go:554 (0x9e9bd7)
net/http/server.go:2947 (0x6c1c7b)
net/http/server.go:1991 (0x6bd733)
runtime/asm_arm64.s:1172 (0x46d9e3)[/unquote]

call FBI and tell them somebody is impersonating a device on your network and using the IP address of 192.168.1.24 to establish connections to your DVR ....

... or look at http logs of the DVR, there will be requests coming from that IP

There is a connection established with that IP already and you are saying this IP never existed :rofl:

There isn't any device on my network at that address. There may have been at one time, but not now. It's not showing in the Attached Devices list in my router, and I even walked around and manually checked all my present devices. NONE of them are at .24.

There are NO REQUESTS coming from that IP address to be found in the error log. The ONLY mention of that IP address, is right there, in that "panic" area, whatever it is.

I was not talking about error log but http log

1 Like

I can't find any "http log" on the server anywhere. There's a "Logs" folder, but all that's in that is COMSKIP and RECORDING folders.

/mnt/data/channels-dvr/data/channels-dvr-http.log

192.168.1.24 is some sort of client making a request to /devices/XXX/guide

I don't know how to get to this on the Channels Raspberry Pi image. I have the server on the network, and can see all the folders in my laptops Windows network list, but all that shows is a MEDIA folder, and the sub folders under that.

Once again I repeat, there is NO client on my network at .24, PERIOD. I can't imagine what this phantom is that you said is pulling a "guide" request.

You could use the experimental setting to send http logs to the main log

Cool! I didn't even know that existed. I'll check that, and see if I can track down what the heck is causing this.

Thanks!

1 Like

You may get lucky and this address could be under clients in the admin GUI

Nope, first thing I checked. It's not there.

On the Pi, pull up a terminal and check your arp cache. If you're on a recent version of Debian/Raspberry OS then the command is:

ip neigh list

1 Like

Ok, it suddenly occurred to me as to just WHAT may have been causing the "PANIC" error at times.

When I first started using the Apple Tv 4k client instead of a Firestick 4k MAX, I had the Apple tv plugged into the router with an ethernet cord. It grabbed the address 192.168.1.16, and I reserved that in the router. Later on, there was some issue going on and I UNPLUGGED the ethernet cable, and that automatically turns ON the Apple tv 4k's WIFI. I suspect it then grabbed: 192.168.1.24, but never checked that, as I assumed it would have stayed with the reserved .16 address.

Anyway, I ran it on Wifi for a couple weeks, and finally went back to direct ethernet connection. When I did that, it must have gone BACK to the reserved .16 address, and the Wifi .24 address effectively "vaporized" and nothing else in the network used it.

Then, I suddenly learned about the LOG file from the Channels Web admin, so would check it from time to time, just because. Then I finally noticed the "Panic" error where it was apparently (per tmm1) trying to send guide data to .24, that no longer existed! Now, since it no longer existed, AND the router logs had long since removed references to it, SOMEHOW the Channels Raspberry Pi image still "remembered" it, and kept trying to send guide data to it for some reason, even though it was long since "gone".

Anyway, I went into the Apple Tv 4k network settings, changed it to "Manual" and reset it to 192.168.1.24. So, my theory goes that this should hopefully fix the issue, and I won't see the error anymore.

DHCP leases are per MAC address, which are unique to the interface. Ethernet and WiFi are two separate Network Interfaces and will look like two different devices to the DHCP server.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.