Annoying network traffic

Eigil Bjorgum Eigil.Bjorgum at microdesign.no
Wed Feb 18 17:01:16 GMT 1998


Hello all.

This is not a typical Samba question, but probably are of interest to those
of you with an expensive ISDN connection, and others as well.

I have the following scanario:
A couple of Win95 boxes, a NT 4.0/SP3 and a Solaris x86 running Samba.
The Solaris box is also running DNS. In addition I have a Cisco router for
the ISDN connection.

When I some time ago noticed that my router regularely generated calls to my
ISP, I suspected this to be traffic on the 137 and 139 ports. Easy match I
thought, just stop the packets from leaving the router, and did so.
But it didn't stop.
I have to add here that these packets wakes up the router in intervals of
approx 5 minutes. (I pay a connection fee each time plus another fee each
minute of connection time, and this adds up to a lot of money. It would be
cheaper to have a longer idle-timeout to keep the line live for 24 hours)

Next thing to try was to start a packet trace on the network. This was
definately surprise time! I have included a packet trace so you can see for
yourself. Most of the uninteresting  crap are stripped off.

The string "0#SoftwareMicrosoftRpcClientProtocols\7MY\2DOMAIN\0" is supposed
to be a host name! The clue here is that a host with that name has never
existed on my network! It is the NT machine that is sending these crazy
requests to the DNS, and I cannot simply turn off the DNS traffic through
the router.

Comments continued between the DNS packets:

IP:   Source address = 192.168.0.10, NT-400.MY.DOMAIN
IP:   Destination address = 192.168.0.2, NAMESERVER.MY.DOMAIN
IP:   No options
UDP:  Source port = 2317
UDP:  Destination port = 53 (DNS)
DNS:
"\1[\1\0\0\1\0\0\0\0\0\0#SoftwareMicrosoftRpcClientProtocols\7MY\2DOMAIN\0"

This is what happens:
The NT workstation send this packet and the DNS will of course not honor
this request as you se in the next packet. As far I can see, the Win95 boxes
are not generating requests like this.

IP:   Source address = 192.168.0.2, NAMESERVER.MY.DOMAIN
IP:   Destination address = 192.168.0.10, NT-400.MY.DOMAIN
IP:   No options
UDP:  Source port = 53
UDP:  Destination port = 2317
DNS:
"\1[\205\203\0\1\0\0\0\1\0\0#SoftwareMicrosoftRpcClientProtocols\7MY\2DOMAIN
\0"

In the next packet, the NT strips off the domain name and tries again.

IP:   Source address = 192.168.0.10, NT-400.MY.DOMAIN
IP:   Destination address = 192.168.0.2, NAMESERVER.MY.DOMAIN
UDP:  Source port = 2318
UDP:  Destination port = 53 (DNS)
DNS:
"\1\\1\0\0\1\0\0\0\0\0\0#SoftwareMicrosoftRpcClientProtocols\0\0\1\0\1"

The DNS server then forwards the packet to one of the root domain servers.

IP:   Source address = 192.168.0.2, NAMESERVER.MY.DOMAIN
IP:   Destination address = 198.41.0.4, a.root-servers.net
UDP:  Source port = 53
UDP:  Destination port = 53 (DNS)
DNS:
"\21\306\0\0\0\1\0\0\0\0\0\0#SoftwareMicrosoftRpcClientProtocols\0\0\1\0\1"

And get the answer back, not honored either.

IP:   Source address = 198.41.0.4, a.root-servers.net
IP:   Destination address = 192.168.0.2, NAMESERVER.MY.DOMAIN
UDP:  Source port = 53
UDP:  Destination port = 53 (DNS)
DNS:
"\21\306\204\3\0\1\0\0\0\1\0\0#SoftwareMicrosoftRpcClientProtocols\0\0\1\0\1
\0\0\6\0\1\0\1"

My DNS server then returns the answer to the NT machine.

IP:   Source address = 192.168.0.2, NAMESERVER.DOMAIN.DOMAIN
IP:   Destination address = 192.168.0.10, NT-400.MY.DOMAIN
UDP:  Source port = 53
UDP:  Destination port = 2318
DNS:
"\1\\205\203\0\1\0\0\0\1\0\0#SoftwareMicrosoftRpcClientProtocols\0\0\1\0\1\0
\0\6\0\1\0\1"

This is yet another protocol where Micro$oft abuses the standards.

I suspect my telephone company to have payed Bill Gates for this
functionality:-(
A part of the idea here was to reduce the remote DNS requests by using local
DNS to solve local names!
I have to admit that I haven't tried a lot of settings on my NT to get rid
of this, except for one thing. I turned OFF 'DNS for Wins Resolution' in the
TCP/IP properties. That seemed to help, but just for a while (1 day). Now it
has started again.

Any hints that can help this are appreciated, and I also ask the Samba
developers to think twice before implementing this behaviour in Samba.

Samba is great!


Best regards
--
Eigil
mailto:Eigil.Bjorgum at microdesign.no




More information about the samba mailing list