XML, miniupnpd and ping/dns errors!



  • I'm getting this errors:

    php: : XML error: syntax error at line 1    ???

    miniupnpd[1075]: sendto(udp_notify=12, 192.168.0.254): Operation not permitted
    miniupnpd[1075]: sendto(udp_notify=13, 192.168.2.254): Operation not permitted
    last message repeated 7 times

    And ping from shell works, but around 80% of time (tinyDNS problem?):

    ping google.com

    ping: cannot resolve google.com: Host name lookup failure

    ping google.com

    PING google.com (64.233.163.104): 56 data bytes
    ping: sendto: Operation not permitted
    ping: sendto: Operation not permitted

    ping google.com

    PING google.com (64.233.163.104): 56 data bytes
    64 bytes from 64.233.163.104: icmp_seq=0 ttl=54 time=70.758 ms
    64 bytes from 64.233.163.104: icmp_seq=1 ttl=54 time=70.336 ms
    64 bytes from 64.233.163.104: icmp_seq=2 ttl=54 time=70.779 ms
    ^C
    –- google.com ping statistics ---
    3 packets transmitted, 3 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 70.336/70.624/70.779/0.204 ms

    Help!



  • @Gradius:

    php: : XML error: syntax error at line 1    ???

    cosmetic, not an error.

    the rest sound like you're running out of states.



  • It was TinyDNS, I give up on him and everything is working fine, but that "cosmetic error" is still there.

    I have another issues with Status > Traffic Graph.

    When I'm downloading something, the graph is fine until a minute or so, then it shows a zero spike, then it goes to normal, a minute after (perhaps less, I still didn't checked the time with a clock) another zero spike, and so on.  What can it be?  I will post a screenshoot when I download something big again.



  • The zero spikes might be due to lost packets. The lost data will cause receiver to stop sending acknowledgements. This will cause the connection's transmit window to fill so TCP will stop transmitting until its timeout expires at which time it will retransmit.



  • @wallabybob:

    The zero spikes might be due to lost packets. The lost data will cause receiver to stop sending acknowledgements. This will cause the connection's transmit window to fill so TCP will stop transmitting until its timeout expires at which time it will retransmit.

    Actually isn't a real zero spike it goes negative (-), it shows a very crazy number like -42938473847 something, is pretty odd, I will try to catch a screenshoot.



  • Isn't that easy to get that spike, the right number is -4294967296, or -2^32.

    I'm using 2xVDSL (50Mbps each) via Load Balancing to make it into "100Mbps".

    Since is PPPoE I'm using fixed MTU to 1492 on everything here, perhaps that is the culpit?

    Edit:
    Managed to get this spike:

    Edit2:
    Perhaps the number is… ?!
    c:>netsh interface ipv4 show subinterfaces

    MTU  MediaSenseState  Bytes In  Bytes Out  Interface
    ------  ---------------  ---------  ---------  -------------
    4294967295                1          0    731659  Loopback Pseudo-Interface 1
      1500                5          0          0  Wireless Network Connection
      1492                1  281687472  110259282  Local Area Connection


  • Rebel Alliance Developer Netgate

    If you push a lot of traffic it probably is wrapping the 32-bit counter that tracks the used bandwdith, causing an abnormality in the graph. 2.0 uses 64-bit counters for that, so it should behave better.



  • I see.

    Cannot wait for 2.0 final release (aka stable) !


Log in to reply