Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.




311 posts

Ultimate Geek
+1 received by user: 3


Topic # 54039 15-Dec-2009 17:09
Send private message

Hi,


I'm using Snow Leopard (10.6.2). The installation was straight forward, no issues.


I connected and the traffic started counting with a rate of about 4-5KB/sec (both ways) and it chewed up almost 1MB in about on minute.


I did a tcpdump on the interface and:



tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type PPP (PPP), capture size 65535 bytes
17:00:16.545930 IP 115.189.249.83.53678 > 202.27.158.40.53: 33916+ PTR? b._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
17:00:16.556040 IP 115.189.249.83.54375 > 202.27.156.72.53: 13753+ PTR? db._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
17:00:16.566194 IP 115.189.249.83.62901 > 202.27.156.72.53: 9127+ PTR? r._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
17:00:16.877685 IP 202.27.156.72.53 > 115.189.249.83.60091: 52832 ServFail 0/0/0 (56)
17:00:16.888063 IP 202.27.156.72.53 > 115.189.249.83.53678: 33916 ServFail 0/0/0 (55)
17:00:16.888866 IP 202.27.158.40.53 > 115.189.249.83.53678: 33916 ServFail 0/0/0 (55)
17:00:16.899117 IP 115.189.249.83.53678 > 202.27.158.40.53: 33916+ PTR? b._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
17:00:16.909304 IP 115.189.249.83.62901 > 202.27.156.72.53: 9127+ PTR? r._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
17:00:16.919491 IP 115.189.249.83.60091 > 202.27.156.72.53: 52832+ PTR? lb._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
17:00:16.937549 IP 202.27.156.72.53 > 115.189.249.83.65093: 50902 ServFail 0/0/0 (56)
17:00:17.077658 IP 202.27.156.72.53 > 115.189.249.83.54375: 13753 ServFail 0/0/0 (56)
17:00:17.177661 IP 202.27.156.72.53 > 115.189.249.83.62901: 9127 ServFail 0/0/0 (55)
17:00:17.231930 IP 115.189.249.83.53678 > 202.27.156.72.53: 33916+ PTR? b._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
17:00:17.242095 IP 115.189.249.83.54375 > 202.27.156.72.53: 13753+ PTR? db._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
17:00:17.252257 IP 115.189.249.83.62901 > 202.27.156.72.53: 9127+ PTR? r._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
17:00:17.262426 IP 115.189.249.83.65093 > 202.27.156.72.53: 50902+ PTR? dr._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
17:00:17.272569 IP 115.189.249.83.60091 > 202.27.156.72.53: 52832+ PTR? lb._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)


And continued with a lot of similar traffic.


I tried with a Vodafone SIM which worked out of the box, with the Telecom settings!.


Traffic was idle after connecting and a tcpdump was very quiet:



tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type PPP (PPP), capture size 65535 bytes
17:04:25.890427 IP 121.90.249.42.65320 > 121.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:04:26.161138 IP 121.90.249.42.65320 > 121.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:04:26.431817 IP 121.90.249.42.65320 > 121.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
tcpdump: pcap_loop: read: Device not configured
3 packets captured
3 packets received by filter
0 packets dropped by kernel




Any idea what could cause this?


Thanks.


View this topic in a long page with up to 500 replies per page Create new topic
 1 | 2
33 posts

Geek
+1 received by user: 4


  Reply # 282827 15-Dec-2009 18:08
Send private message

Interesting, I would not have a clue what it all means, but ... i get the same, im running 10.6.2 and when I use Vodafone, notice almost no traffic after conneting, where as with XT, almost right away there seems to be alot of Data being sent 



311 posts

Ultimate Geek
+1 received by user: 3


  Reply # 282859 15-Dec-2009 18:56
Send private message

After doing some digging it seems that Telecom's DNS's are "broken". They should return NXDOMAIN for that query and they return ServFail.

I tried various ways of forcing manual DNS but it uses the ones received through DHCP. Even in the Telecom Connection Manager I force Manual DNS but without success.

I'll let you know if I solve it.

Cheers

 
 
 
 


426 posts

Ultimate Geek
+1 received by user: 16

Trusted
Spark NZ
Subscriber

  Reply # 282891 15-Dec-2009 20:15
Send private message

I've asked some people to look into this.

In case you're wondering DNS traffic to/from our DNS servers is not counted for billing purposes.

Neal




The comments I write on this forum do not necessarily reflect the views of my employer and as such cannot be taken as official statements of my employer.



311 posts

Ultimate Geek
+1 received by user: 3


  Reply # 282893 15-Dec-2009 20:18
Send private message

Hi Neal,

Many thanks for the help.

I've managed to put Google's DNS servers (8.8.8.8) manually in network preferences and the traffic stopped so it's clearly a DNS issue (and this is why with Vodafone it also works).

What's annoying is that I have to do it every time I plug my stick.

Great thing about the DNS not counting. Is this the only traffic not counted?

Cheers.

677 posts

Ultimate Geek
+1 received by user: 27

Trusted

  Reply # 282906 15-Dec-2009 20:43
Send private message

Neal I will take a look at this tonight if you like and post back here.
tcpdump, if you manage to capture a dump of the same request to another DNS server, like google then can you please post that here or PM me with the details?

I dont have access to a mac so it might take me a few hours to work out what is going on.

Paul




meat popsicle



311 posts

Ultimate Geek
+1 received by user: 3


  Reply # 282924 15-Dec-2009 21:06
Send private message

Hello,

This is the output when using Google's DNS server:


bash-3.2# tcpdump -n -i ppp0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type PPP (PPP), capture size 65535 bytes
21:05:48.431652 IP 115.189.211.134.65327 > 8.8.8.8.53: 147+ PTR? r._dns-sd._udp.0.1.168.192.in-addr.arpa. (57)
21:05:48.497491 IP 202.27.158.40.53 > 115.189.211.134.58021: 51295 NXDomain 0/0/0 (59)
21:05:48.531695 IP 115.189.211.134.62437 > 8.8.8.8.53: 61913+ PTR? dr._dns-sd._udp.0.1.168.192.in-addr.arpa. (58)
21:05:48.543103 IP 115.189.211.134.64885 > 8.8.8.8.53: 34949+ PTR? lb._dns-sd._udp.0.1.168.192.in-addr.arpa. (58)
21:05:48.553343 IP 115.189.211.134.51263 > 8.8.8.8.53: 18922+ PTR? b._dns-sd._udp.0.90.16.172.in-addr.arpa. (57)
21:05:48.563502 IP 115.189.211.134.53552 > 8.8.8.8.53: 59835+ PTR? db._dns-sd._udp.0.90.16.172.in-addr.arpa. (58)
21:05:48.573709 IP 115.189.211.134.57100 > 8.8.8.8.53: 11499+ PTR? r._dns-sd._udp.0.90.16.172.in-addr.arpa. (57)
21:05:48.583826 IP 115.189.211.134.62952 > 8.8.8.8.53: 61720+ PTR? dr._dns-sd._udp.0.90.16.172.in-addr.arpa. (58)
21:05:48.593941 IP 115.189.211.134.61292 > 8.8.8.8.53: 17430+ PTR? lb._dns-sd._udp.0.90.16.172.in-addr.arpa. (58)
21:05:48.603616 IP 115.189.211.134.50293 > 8.8.8.8.53: 52824+ PTR? b._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
21:05:48.613877 IP 115.189.211.134.58704 > 8.8.8.8.53: 53401+ PTR? db._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:48.623075 IP 115.189.211.134.51513 > 8.8.8.8.53: 20123+ PTR? r._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
21:05:48.633296 IP 115.189.211.134.49280 > 8.8.8.8.53: 52998+ PTR? dr._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:48.643509 IP 115.189.211.134.53631 > 8.8.8.8.53: 4467+ PTR? lb._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:48.653773 IP 115.189.211.134.62009 > 8.8.8.8.53: 31571+ PTR? 79.1.168.192.in-addr.arpa. (43)
21:05:48.664012 IP 115.189.211.134.57825 > 8.8.8.8.53: 13246+ PTR? 134.211.189.115.in-addr.arpa. (46)
21:05:48.877482 IP 8.8.8.8.53 > 115.189.211.134.50088: 24107 NXDomain 0/0/0 (57)
21:05:48.878060 IP 8.8.8.8.53 > 115.189.211.134.59321: 37056 NXDomain 0/0/0 (58)
21:05:48.878699 IP 8.8.8.8.53 > 115.189.211.134.65327: 147 NXDomain 0/0/0 (57)
21:05:48.988255 IP 8.8.8.8.53 > 115.189.211.134.62437: 61913 NXDomain 0/0/0 (58)
21:05:48.988260 IP 8.8.8.8.53 > 115.189.211.134.64885: 34949 NXDomain 0/0/0 (58)
21:05:49.177355 IP 8.8.8.8.53 > 115.189.211.134.62009: 31571 NXDomain 0/0/0 (43)
21:05:49.177940 IP 8.8.8.8.53 > 115.189.211.134.62952: 61720 NXDomain 0/0/0 (58)
21:05:49.178435 IP 8.8.8.8.53 > 115.189.211.134.61292: 17430 NXDomain 0/0/0 (58)
21:05:49.197222 IP 8.8.8.8.53 > 115.189.211.134.51263: 18922 NXDomain 0/0/0 (57)
21:05:49.197827 IP 8.8.8.8.53 > 115.189.211.134.57100: 11499 NXDomain 0/0/0 (57)
21:05:49.198325 IP 8.8.8.8.53 > 115.189.211.134.53552: 59835 NXDomain 0/0/0 (58)
21:05:49.447353 IP 8.8.8.8.53 > 115.189.211.134.51513: 20123 ServFail 0/0/0 (55)
21:05:49.457349 IP 8.8.8.8.53 > 115.189.211.134.49280: 52998 ServFail 0/0/0 (56)
21:05:49.467227 IP 8.8.8.8.53 > 115.189.211.134.53631: 4467 ServFail 0/0/0 (56)
21:05:49.487222 IP 8.8.8.8.53 > 115.189.211.134.58704: 53401 ServFail 0/0/0 (56)
21:05:49.605451 IP 115.189.211.134.50293 > 8.8.8.8.53: 52824+ PTR? b._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
21:05:49.607307 IP 8.8.8.8.53 > 115.189.211.134.50293: 52824 ServFail 0/0/0 (55)
21:05:49.615538 IP 115.189.211.134.58704 > 8.8.8.8.53: 53401+ PTR? db._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:49.625974 IP 115.189.211.134.51513 > 8.8.8.8.53: 20123+ PTR? r._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
21:05:49.636170 IP 115.189.211.134.49280 > 8.8.8.8.53: 52998+ PTR? dr._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:49.646278 IP 115.189.211.134.53631 > 8.8.8.8.53: 4467+ PTR? lb._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:49.665580 IP 115.189.211.134.57825 > 8.8.8.8.53: 13246+ PTR? 134.211.189.115.in-addr.arpa. (46)
21:05:49.827353 IP 8.8.8.8.53 > 115.189.211.134.57825: 13246 1/0/0 PTR 115-189-211-134.mobile.telecom.co.nz. (96)
21:05:49.977486 IP 8.8.8.8.53 > 115.189.211.134.57825: 13246 1/0/0 PTR 115-189-211-134.mobile.telecom.co.nz. (96)
21:05:50.207417 IP 8.8.8.8.53 > 115.189.211.134.49280: 52998 ServFail 0/0/0 (56)
21:05:50.227290 IP 8.8.8.8.53 > 115.189.211.134.50293: 52824 ServFail 0/0/0 (55)
21:05:50.227907 IP 8.8.8.8.53 > 115.189.211.134.53631: 4467 ServFail 0/0/0 (56)
21:05:50.247464 IP 8.8.8.8.53 > 115.189.211.134.58704: 53401 ServFail 0/0/0 (56)
21:05:50.247917 IP 8.8.8.8.53 > 115.189.211.134.51513: 20123 ServFail 0/0/0 (55)
21:05:52.611434 IP 115.189.211.134.50293 > 8.8.8.8.53: 52824+ PTR? b._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
21:05:52.621588 IP 115.189.211.134.58704 > 8.8.8.8.53: 53401+ PTR? db._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:52.632734 IP 115.189.211.134.51513 > 8.8.8.8.53: 20123+ PTR? r._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
21:05:52.642855 IP 115.189.211.134.49280 > 8.8.8.8.53: 52998+ PTR? dr._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:52.652947 IP 115.189.211.134.53631 > 8.8.8.8.53: 4467+ PTR? lb._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:05:53.197694 IP 8.8.8.8.53 > 115.189.211.134.58704: 53401 ServFail 0/0/0 (56)
21:05:53.198272 IP 8.8.8.8.53 > 115.189.211.134.50293: 52824 ServFail 0/0/0 (55)
21:05:53.208979 IP 8.8.8.8.53 > 115.189.211.134.49280: 52998 ServFail 0/0/0 (56)
21:05:53.227324 IP 8.8.8.8.53 > 115.189.211.134.53631: 4467 ServFail 0/0/0 (56)
21:05:53.297644 IP 8.8.8.8.53 > 115.189.211.134.51513: 20123 ServFail 0/0/0 (55)
21:06:01.629837 IP 115.189.211.134.50293 > 8.8.8.8.53: 52824+ PTR? b._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
21:06:01.638976 IP 115.189.211.134.58704 > 8.8.8.8.53: 53401+ PTR? db._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:06:01.650127 IP 115.189.211.134.51513 > 8.8.8.8.53: 20123+ PTR? r._dns-sd._udp.0.0.0.115.in-addr.arpa. (55)
21:06:01.660259 IP 115.189.211.134.49280 > 8.8.8.8.53: 52998+ PTR? dr._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:06:01.671482 IP 115.189.211.134.53631 > 8.8.8.8.53: 4467+ PTR? lb._dns-sd._udp.0.0.0.115.in-addr.arpa. (56)
21:06:02.217296 IP 8.8.8.8.53 > 115.189.211.134.51513: 20123 ServFail 0/0/0 (55)
21:06:02.227385 IP 8.8.8.8.53 > 115.189.211.134.49280: 52998 ServFail 0/0/0 (56)
21:06:02.247247 IP 8.8.8.8.53 > 115.189.211.134.50293: 52824 ServFail 0/0/0 (55)
21:06:02.257184 IP 8.8.8.8.53 > 115.189.211.134.58704: 53401 ServFail 0/0/0 (56)
21:06:02.307296 IP 8.8.8.8.53 > 115.189.211.134.53631: 4467 ServFail 0/0/0 (56)
tcpdump: pcap_loop: read: Device not configured
65 packets captured
71 packets received by filter
0 packets dropped by kernel
bash-3.2#


The "Telecom connection manager" shows about 3KB down and 3KB up in total after half a minute which is about right.
Interestingly enough I see a lot of Servfail but also some NXdomain.

Thanks again for your help.

677 posts

Ultimate Geek
+1 received by user: 27

Trusted

  Reply # 282928 15-Dec-2009 21:14
Send private message

Hi tcpdump,

It looks like its an issue of two halfs, the servers should return NXDOMAIN and the mDNS on OSX should honour servfail in a slightly better way.
I will arrange to have the NXDOMAIN response taken care of and post back when it is in place.

Paul




meat popsicle



311 posts

Ultimate Geek
+1 received by user: 3


  Reply # 282945 15-Dec-2009 22:03
Send private message

Brilliant. Many thanks.



311 posts

Ultimate Geek
+1 received by user: 3


  Reply # 283180 16-Dec-2009 18:57
Send private message

As an update, I managed to disable the multicast advertising following this document:
 
http://support.apple.com/kb/HT3789

Now, it's very quiet on port 53, no unnecessary advertisement and I can use the DNS provided by Telecom.

Thanks again for your help.

60 posts

Master Geek
+1 received by user: 8


  Reply # 283233 16-Dec-2009 21:17
Send private message

I wonder if something has changed in the network? I already had the -NoMulticastAdvertisements setting and it didn't help me, but everything is fine now. I'm >mostly< convinced that I rebooted after the change ;o)

In any case, that's pretty cool!

65 posts

Master Geek


  Reply # 283353 17-Dec-2009 09:58
Send private message

I got the Tstick given away by XT to their broadband customers inc. 500MB/$29 prepay. It's advertised as OSX compatible; however, it's a sad joke; the Telecom Connection manager constantly writes messages to Console generating pages and pages of crap and there's a constant traffic of about 2KB/s from mDNSresponder to Telecom's dns servers (202.27.156.72 & 202.27.158.40). This would make the Tstick unusable as a 500MB allowance will be burned up very quickly just through unnecessary DNS server access, is this traffic definitely not counted? Makes it very difficult to estimate your data usage as the connection manager tracks this traffic. Additionally, every time the stick is plugged in it adds 3 new services to network.plist I now have 3x ZTEUSBModem, 3xZTEUSBATPort, 3x ZTEUSBDIAGPort. Additionally the installer fails to configure them (solved by manually adding in a number), but the duplicates require the same thing- it's a pita. Please Telecom, get the high school student who wrote the software to come back, give them more red bull and ask them to fix their homework. Pretty please, k tnx.



311 posts

Ultimate Geek
+1 received by user: 3


  Reply # 283356 17-Dec-2009 10:02
Send private message

You can resolve the issue with mDNSresponder, read this thread.
About the 3 new network ports, this is an OSX specific thing, it does the same with all USB sticks. A bit annoying, but not the end of the world.

BDFL - Memuneh
59065 posts

Uber Geek
+1 received by user: 10341

Administrator
Trusted
Geekzone
Subscriber

  Reply # 283363 17-Dec-2009 10:14
Send private message

consolation: there's a constant traffic of about 2KB/s from mDNSresponder to Telecom's dns servers (202.27.156.72 & 202.27.158.40). This would make the Tstick unusable as a 500MB allowance will be burned up very quickly just through unnecessary DNS server access, is this traffic definitely not counted?


Telecom already said earlier in this topic the traffic is not counted.

consolation: Additionally, every time the stick is plugged in it adds 3 new services to network.plist I now have 3x ZTEUSBModem, 3xZTEUSBATPort, 3x ZTEUSBDIAGPort. Additionally the installer fails to configure them (solved by manually adding in a number), but the duplicates require the same thing- it's a pita. Please Telecom, get the high school student who wrote the software to come back, give them more red bull and ask them to fix their homework. Pretty please, k tnx.


This is off topic. Please start a new discussion if you must continue.

Any other posts here not related to the mDNSresponder problem and I lock this discussion.




65 posts

Master Geek


  Reply # 283392 17-Dec-2009 11:07
Send private message

Well... imho, the mDNSresponder problem is a symptom of the disease; crappy Telecom Connection Manager / drivers / kexts under OSX. So, do we really need 3 topics on the same overarching issue? Having said that, I've got nothing more useful to add, so I'm out. Hopefully we will see a new package from XT soon.

426 posts

Ultimate Geek
+1 received by user: 16

Trusted
Spark NZ
Subscriber

  Reply # 283405 17-Dec-2009 11:22
Send private message

@consolation Feel free to document your issues about the connection manager in an email to me and I will see what I can do to address these.

Neal




The comments I write on this forum do not necessarily reflect the views of my employer and as such cannot be taken as official statements of my employer.

 1 | 2
View this topic in a long page with up to 500 replies per page Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:





News »

From small to medium and beyond: Navigating the ERP battlefield
Posted 21-Nov-2017 21:12


Business owners: ERP software selection starts (and finishes) with you
Posted 21-Nov-2017 21:11


Why I'm not an early adopter
Posted 21-Nov-2017 10:39


Netatmo launches smart home products in New Zealand
Posted 20-Nov-2017 20:06


Huawei Mate 10: Punchy, long battery life, artificial intelligence
Posted 20-Nov-2017 16:30


Propel launch Disney Star Wars Laser Battle Drones
Posted 19-Nov-2017 21:26


UFB killer app: Speed
Posted 17-Nov-2017 17:01


The case for RSS — MacSparky
Posted 13-Nov-2017 14:35


WordPress and Indieweb: Take control of your online presence — 6:30 GridAKL Nov 30
Posted 11-Nov-2017 13:43


Chorus reveals technology upgrade for schools, students
Posted 10-Nov-2017 10:28


Vodafone says Internet of Things (IoT) crucial for digital transformation
Posted 10-Nov-2017 10:06


Police and Facebook launch AMBER Alerts system in NZ
Posted 9-Nov-2017 10:49


Amazon debuts Fire TV Stick Basic Edition in over 100 new countries
Posted 8-Nov-2017 05:34


Vodafone VoIP transition to start this month
Posted 7-Nov-2017 12:33


Spark enhances IoT network capability
Posted 7-Nov-2017 11:33



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.