My system log contain quite many of these (RT-N16, 1.9.2.7-rtn-r3497, not PPP connection) in every half an hour:
I've noticed it only now, but cannot guess what it is. Nothing was connected to the router at that time not even via OpenVPN although it was running.Code:Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:37 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:41 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is Nov 2 00:23:45 miniupnpd[406]: Can't find in which sub network the client is
Do you have some idea what's causing this or how to figure it out (what client it refers to)?
Last edited by ecaddict; 02-11-2011 at 11:43.
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
I've stopped twonkymedia and the messages disappeared. After starting it again they have appeared immediately.
Maybe there is something wrong with my configuration even though it's nothing special compared to the factory twonkymedia-server-default.ini.
Anyhow, thanks for quick responses.
I'm not familiar with UPnP protocols, but twonkymedia really issues SSDP M-SEARCH command.
Probably, we have to add "listening_ip=127.0.0.1/8" into miniupnpd.conf
As I can see in miniupnp sources, there should be one diagnostic string more in syslog.log, like:
Are you logging errors only? Could you provide output of following comandsSSDP M-SEARCH from 0.0.0.0 ST: ???"
?Code:ps|grep syslogd nvram get log_level_x
Hmm... what version do you use?
I've implemented the entire basic UPnP stack for control points(the clients) and devices(servers in common computer language) while working on a uni project.I'm not familiar with UPnP protocols, but twonkymedia really issues SSDP M-SEARCH command.
Probably, we have to add "listening_ip=127.0.0.1/8" into miniupnpd.conf
I've done a quick capture with wireshark and this is what I got:
I guess that's the ssdp m-search package you're talking about.Code:M-SEARCH * HTTP/1.1\r\n MX: 3\r\n ST: urn:schemas-upnp-org:device:RemoteUIServer:1\r\n HOST: 239.255.255.250:1900\r\n MAN: "ssdp:discover"\r\n
My comment on this: It's a correct package according to the UPnP Device architecture document:
(without the line endings, but they're supposed to be windows style)Code:M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: seconds to delay response ST: search target
All the required values are defined, but in theory shouldn't follow the exact same order.
So in my quickly formed opinion this is a bug in the way miniupnpd handles it's m-searches.
blocking out the local host could work, unless you have a bad network and packages bounce back
Last edited by wpte; 02-11-2011 at 18:59.
I've solved the issue via adding ip=192.168.1.1 to twonkymedia.ini.
In this way it's restricted to LAN interface. I don't know if it's any issue, probably not.
Please correct me if I'm wrong.
I'll skip checking this issue further in upnp as I'm not familiar enough with it.
Btw. twonkymedia version is 6.0.37.
refer http://wl500g.info/showpost.php?p=234697&postcount=590
despite the face of security hole, seems like we have to add lo interface.
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
Ok
"Can't find in which sub network the client %s is", client_ip?
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
Yes, the ip-endpoint is set at 255.255.255.255:1900
then an ipv4 socket is created with udp and datagram settings.
then twonky sends the m-search message 3 times (according to upnp spec)
and reads the responses back.
It's importand that if you have multiple devices on 1 host that either way you solve the problem of multiple sockets on 1 interface with a root device (which could act like a sort of switch) or like most programs do because of compatebility issues: do not bound on the socket but simply send and receive data.
In my programming I've never had to use the ip of the device... well... only for serving the service, but not for m-searches and responses
In wireshark the ip of the twonky m-search just popped up as my router ip, as expected.
Last edited by wpte; 03-11-2011 at 11:47.
I can confirm that running the following commands:
makes it unnecessary adding the ip=192.168.1.1 to twonkymedia.ini so that the strange logs disappear.Code:killall miniupnpd cat >> /etc/miniupnpd.conf << __EOF__ listening_ip=127.0.0.1 allow 1024-65535 127.0.0.0/8 1024-65535 __EOF__ miniupnpd ps afx | grep miniupnpd
I don't know if this information is any help to you.
Well my message is coming from an unexpected corner
192.168.3.x is my openvpn ip rangeminiupnpd[216]: Can't find in which sub network the client 192.168.3.1:1030 is
twonky does set it self up on every interface as far as I know. the weird thing is, when connected to openvpn it's not visible