Claimed incorrect MS behaviour wrt Source and Dest IP ...

Richard Sharpe sharpe at
Fri Jun 5 13:16:29 GMT 1998

Has anyone heard or seen the following before?  This sounds bogus, in that
I have never noticed this behaviour, but perhaps I am missing something.

>From Firewalls Digest:
>Date: Thu, 4 Jun 1998 14:51:54 -0400
>From: Laris Benkis <lbenkis at>
>Subject: Interesting packet trace on inbound packets -Reply
>[To unsubscribe, send mail to majordomo at with
>"unsubscribe firewalls" in the body of the message.]
>- -
>A snippet from a Usenet posting that may be relevant:
>>>We have several Win95 machines, WinNT 4.0 workstations and a couple
>>>of WinNT 4.0 servers running on a LAN with TCP-IP. Some other
>>>protocols are used but I am interested in TCP-IP.
>>>We also have a Securicor 3net Monet router which is our gateway
>>> - it manages the ISDN line to our ISP.
>>>We have a problem on our network. Every so often (there is no
>>>specific time delay between cycles) our ISDN line is brought up regularly, 
>>>and it seems that no one machine is causing this. Something is causing
>>>the router to dial the ISDN line and keep it open for its minimum
>>>time out of 45 seconds.
>The problem occurs when you use microsoft networking over TCP/IP.
>From what I can tell Microsoft basically 'got it wrong'... 
>Packets which are destined for machines on the local network (hence
>are delivered via their MAC addresses) have the destination IP 
>address field reversed. 

Well, they got lots of things wrong :-) But this? Seems unlikely!

>The local destination machine has no problems with this as they
>identify the packet via the MAC address grab it. Unfortunately most 
>IP routers sitting on the same subnet will recognise the reversed IP
>address as external and try to route it.
>Ooops, up goes your ISDN link...

Could it perhaps be a browser update or something like that?

>depending on what the destination address is when it's reversed 
>the packet will get routed through the internet until it gets to the
>actual (reversed) host or some router along the way says 'nope, go
>away'. The latter usually happens and you will get a
>ICMP destination unreachable type error returned.
>We found this problem during the development of our packet analyser 
>product (PacketBoy). 

Richard Sharpe, sharpe at, NIC-Handle:RJS96
NS Computer Software and Services P/L, 
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080, 
Samba, Linux, Apache, Digital UNIX, AIX, Netscape, Stronghold, C, ...

More information about the samba-technical mailing list