So here is the thing I was able to find, I ran iptrace on my lan0 interface to capture the Firefox traffic.
As it turned out that massive amount of data is due to traffic between my OS/2 box and my NAS unit, that being ZyXel NSA325 V2. What exactly is being moved is hard to tell, but ipformat shows that the traffic is limitted to just those two static ip addresses.
I ran iptrace as follows: "ipformat -f iptrace.dmp > iptrace.out2". Perhaps I could have tried some other options to better judge what type of data is actually being exchanged.
Here is a sample of typical data packet:
=== START ===
-------------------------- #:4 --------------------------
Delta Time: 0.020sec Packet Length: 234 bytes (EA hex)
IP: Dest: 192.168.001.005 Source: 192.168.001.010
----------------------- IP HEADER -----------------------
IP: Version: 4 Correct Header Length: 20 bytes
IP: Type Of Service: 00
IP: 000. .... Routine
IP: ...0 .... Normal Delay
IP: .... 0... Normal Throughput
IP: .... .0.. Normal Reliability
IP: Total Len: 234 (xEA) bytes Id: 2629
IP: Flags: 2
IP: .1.. Don't Fragment
IP: ..0. Last Fragment
IP: Fragment Offset: 000
IP: Time To Live: 64 sec Protocol: 6 TCP
IP: Header Checksum: 9085 (Correct)
IP: No Options
---------------------- TCP HEADER ----------------------
TCP: Source Port: 57489 (Unassigned port) Dest Port: 445 (Unassigned port)
TCP: Sequence #: 4155242293
TCP: Ack #: 468644365
TCP: Offset: 20 bytes
TCP: Flags: 18
TCP: ..0. .... Urgent bit Off
TCP: ...1 .... <ACK> Ack bit On
TCP: .... 1... <PUSH>Push bit On
TCP: .... .0.. Reset bit Off
TCP: .... ..0. Synchronize bit Off
TCP: .... ...0 Finish bit Off
TCP: Window: 33888 Checksum: 944A (Correct)
TCP: No Options
--------------------------------- DATA -----------------------------------
0000 00 00 00 BE FF 53 4D 42 72 00 00 00 00 08 01 C8 .....SMBr.......
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 ................
0020 00 00 01 00 00 9B 00 02 50 43 20 4E 45 54 57 4F ........PC NETWO
0030 52 4B 20 50 52 4F 47 52 41 4D 20 31 2E 30 00 02 RK PROGRAM 1.0..
0040 4D 49 43 52 4F 53 4F 46 54 20 4E 45 54 57 4F 52 MICROSOFT NETWOR
0050 4B 53 20 31 2E 30 33 00 02 4D 49 43 52 4F 53 4F KS 1.03..MICROSO
0060 46 54 20 4E 45 54 57 4F 52 4B 53 20 33 2E 30 00 FT NETWORKS 3.0.
0070 02 4C 41 4E 4D 41 4E 31 2E 30 00 02 4C 4D 31 2E .LANMAN1.0..LM1.
0080 32 58 30 30 32 00 02 44 4F 53 20 4C 41 4E 4D 41 2X002..DOS LANMA
0090 4E 32 2E 31 00 02 4C 41 4E 4D 41 4E 32 2E 31 00 N2.1..LANMAN2.1.
00A0 02 53 61 6D 62 61 00 02 4E 54 20 4C 41 4E 4D 41 .Samba..NT LANMA
00B0 4E 20 31 2E 30 00 02 4E 54 20 4C 4D 20 30 2E 31 N 1.0..NT LM 0.1
00C0 32 00 2.
=== STOP ===
....but, where this led me to is to eventually spot a filename that was stored on the NAS...some more poking around identified the root cause (as best as I can tell at the moment anyways). I must have downloaded this file using Firefox and pointed to my NAS box as the "SAVE AS" location. I was able to find this very filename in the Downloads list...removing it from there no longer causes Firefox to interrogate my NAS box for directory contents, or so it appears.
Strange, at least it seems strange that the app would do this, it implies that all previous downloads still present in the History would be looked at as well. Local filesystem is different then network stuff, thus the spike in my tcp/ip traffic. This behaviour could certainly be the result of Netdrive version I use, which is 3.1.4 with File System Drive being 3.027.
