New oleg firmware version

[ecaddict]

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.

[lly]

I've stopped twonkymedia and the messages disappeared. After starting it again they have appeared immediately.

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:

SSDP M-SEARCH from 0.0.0.0 ST: ???"

Are you logging errors only? Could you provide output of following comands

ps|grep syslogd
nvram get log_level_x

?

[theMIROn]

Probably, we have to add "listening_ip=127.0.0.1/8" into miniupnpd.conf

refer http://wl500g.info/showpost.php?p=234697&postcount=590
despite the face of security hole, seems like we have to add lo interface.

[lly]

refer http://wl500g.info/showpost.php?p=234697&postcount=590
despite the face of security hole, seems like we have to add lo interface.

To be sure to do this, we must know that sender IP neither anycast, nor multicast. Right?
Since I haven't twonkey, I ask wpte & ecaddict for information.

[theMIROn]

Ok
"Can't find in which sub network the client %s is", client_ip?

[ecaddict]

refer http://wl500g.info/showpost.php?p=234697&postcount=590
despite the face of security hole, seems like we have to add lo interface.

I can confirm that running the following commands:

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

makes it unnecessary adding the ip=192.168.1.1 to twonkymedia.ini so that the strange logs disappear.

I don't know if this information is any help to you.

[wpte]

Well my message is coming from an unexpected corner

miniupnpd[216]: Can't find in which sub network the client 192.168.3.1:1030 is

192.168.3.x is my openvpn ip range
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

[lly]

Unfortunately, miniupnpd hasn't bind to specific interface option. Seems to be it really urgent on routers...

[theMIROn]

Unfortunately, miniupnpd hasn't bind to specific interface option. Seems to be it really urgent on routers...

Huh, that's was I'm talking about recently

[wpte]

Unfortunately, miniupnpd hasn't bind to specific interface option. Seems to be it really urgent on routers...

Seems like an easy fix tho.
This could explain why twonky didn't cause the messages after it knew the ip the broadcast on...
It's too bad the developers didn't include this by default, on a port-forwarding application it would be a good security feature in my eyes.

[wpte]

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.

Hmm... what version do you use?

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 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've done a quick capture with wireshark and this is what I got:

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

I guess that's the ssdp m-search package you're talking about.
My comment on this: It's a correct package according to the UPnP Device architecture document:

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: seconds to delay response
ST: search target

(without the line endings, but they're supposed to be windows style)
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

[ecaddict]

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.

[wpte]

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.

I'm not sure ecaddict... an m-search is just a udp broadcast so an ip should be resolved by the control point (miniupnpd in this case), setting an ip for the device shouldn't make a difference

[lly]

I'm not sure ecaddict... an m-search is just a udp broadcast so an ip should be resolved by the control point (miniupnpd in this case), setting an ip for the device shouldn't make a difference

M-SEARCH has a multicast target address, but sender(source) address in packet is?

[wpte]

M-SEARCH has a multicast target address, but sender(source) address in packet is?

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.