Page 41 of 48 FirstFirst ... 313940414243 ... LastLast
Results 601 to 615 of 714

Thread: New oleg firmware version

  1. #601
    My system log contain quite many of these (RT-N16, 1.9.2.7-rtn-r3497, not PPP connection) in every half an hour:
    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
    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.

    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 12:43.

  2. #602
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ecaddict View Post
    Do you have some idea what's causing this or how to figure it out (what client it refers to)?
    Some client send command to unlisted interface or it is a bug inside miniupnpd.
    I can add debug print about sender IP to miniupnpd only.

    P.S. Unfortunately, miniupnpd is far from ideal daemon...

  3. #603
    Quote Originally Posted by lly View Post
    P.S. Unfortunately, miniupnpd is far from ideal daemon...
    But, indeed it's better than supplied bcm upnp

  4. #604
    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.

  5. #605
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ecaddict View Post
    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
    Code:
    ps|grep syslogd
    nvram get log_level_x
    ?

  6. #606
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by ecaddict View Post
    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:
    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
    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:
    Code:
    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
    Last edited by wpte; 02-11-2011 at 19:59.

  7. #607
    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.

  8. #608
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by ecaddict View Post
    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

  9. #609
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by wpte View Post
    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?

  10. #610
    Quote Originally Posted by lly View Post
    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.

  11. #611
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by theMIROn View Post
    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.

  12. #612

  13. #613
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by lly View Post
    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.
    Last edited by wpte; 03-11-2011 at 12:47.

  14. #614
    Quote Originally Posted by theMIROn View Post
    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:
    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
    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.

  15. #615
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    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

Page 41 of 48 FirstFirst ... 313940414243 ... LastLast

Similar Threads

  1. Probleme mit der Oleg firmware
    By errox in forum German Discussion - Deutsch (DE)
    Replies: 15
    Last Post: 14-06-2008, 23:26
  2. new firmware 1.9.2.7-8 by oleg
    By alien433 in forum WL-500gP Firmware Discussion
    Replies: 31
    Last Post: 24-01-2008, 21:31
  3. Oleg firmware not working.
    By wpte in forum WL-500gP Q&A
    Replies: 6
    Last Post: 07-01-2008, 13:48
  4. C Compiler voor de oleg firmware
    By wouzs in forum Dutch Discussion - Nederlands
    Replies: 1
    Last Post: 28-10-2007, 16:57

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •