Wired DNS traffic on T-Stick (only on Telecom)

Forums › Spark New Zealand › Wired DNS traffic on T-Stick (only on Telecom)

tcpdump

311 posts

Ultimate Geek
+1 received by user: 3

Topic # 54039 15-Dec-2009 17:09

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.

1 | 2

33 posts

Geek
+1 received by user: 4

Reply # 282827 15-Dec-2009 18:08

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

tcpdump

311 posts

Ultimate Geek
+1 received by user: 3

Reply # 282859 15-Dec-2009 18:56

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

NealR

426 posts

Ultimate Geek
+1 received by user: 16

Trusted

Spark NZ

Subscriber

Reply # 282891 15-Dec-2009 20:15

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.

tcpdump

311 posts

Ultimate Geek
+1 received by user: 3

Reply # 282893 15-Dec-2009 20:18

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.

ptinson

677 posts

Ultimate Geek
+1 received by user: 27

Trusted

Reply # 282906 15-Dec-2009 20:43

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

tcpdump

311 posts

Ultimate Geek
+1 received by user: 3

Reply # 282924 15-Dec-2009 21:06

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.

ptinson

677 posts

Ultimate Geek
+1 received by user: 27

Trusted

Reply # 282928 15-Dec-2009 21:14

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

tcpdump

311 posts

Ultimate Geek
+1 received by user: 3

Reply # 282945 15-Dec-2009 22:03

Brilliant. Many thanks.

tcpdump

311 posts

Ultimate Geek
+1 received by user: 3

Reply # 283180 16-Dec-2009 18:57

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.

redmouse

60 posts

Master Geek
+1 received by user: 8

Reply # 283233 16-Dec-2009 21:17

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!

consolation

65 posts

Master Geek

Reply # 283353 17-Dec-2009 09:58

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.

tcpdump

311 posts

Ultimate Geek
+1 received by user: 3

Reply # 283356 17-Dec-2009 10:02

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.

freitasm

BDFL - Memuneh
58759 posts

Uber Geek
+1 received by user: 10156

Administrator

Trusted

Geekzone

Subscriber

Reply # 283363 17-Dec-2009 10:14

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.

Geekzone broadband switch | Amazon (Geekzone aff) | MightyApe (Geekzone aff) | Backblaze cloud backup (personal and business) | My technology disclosure

consolation

65 posts

Master Geek

Reply # 283392 17-Dec-2009 11:07

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.

NealR

426 posts

Ultimate Geek
+1 received by user: 16

Trusted

Spark NZ

Subscriber

Reply # 283405 17-Dec-2009 11:22

@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