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 timesAnd 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 permittedping 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 msHelp!
-
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.
-
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 subinterfacesMTU 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 -
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) !
