Monday, May 15, 2000
More MONitoring of the NETwork
So I'm still working on monnet. I basically started over from
scratch, reworking the code although the basic structure is the same from
the old version. The output from the program looks like:
0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.72.81 TCP 25945 80 A 00C07B4D7D81 0040332E103C IPv4 205.229.72.81 208.26.72.3 TCP 80 25945 AP 00C07B4D7D81 0040332E103C IPv4 205.229.72.81 208.26.72.3 TCP 80 25945 AP F 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.72.81 TCP 25945 80 A 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.74.191 TCP 25944 80 A F 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.74.190 TCP 25950 80 S 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.72.81 TCP 25945 80 A F 00C07B4D7D81 0040332E103C IPv4 205.229.74.218 208.26.72.3 TCP 80 25944 R 00C07B4D7D81 0040332E103C IPv4 205.229.74.190 208.26.72.3 TCP 80 25950 A S 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.74.190 TCP 25950 80 A 00C07B4D7D81 0040332E103C IPv4 205.229.72.81 208.26.72.3 TCP 80 25945 A 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.74.190 TCP 25950 80 AP 00C07B4D7D81 0040332E103C IPv4 205.229.74.190 208.26.72.3 TCP 80 25950 A 00C07B4D7D81 0040332E103C IPv4 205.229.74.190 208.26.72.3 TCP 80 25950 AP 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.74.190 TCP 25950 80 A 00C07B4D7D81 0040332E103C IPv4 205.229.74.190 208.26.72.3 TCP 80 25950 AP 00C07B4D7D81 0040332E103C IPv4 205.229.74.190 208.26.72.3 TCP 80 25950 A F 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.74.190 TCP 25950 80 A 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.74.190 TCP 25950 80 A F 00C07B4D7D81 0040332E103C IPv4 205.229.74.190 208.26.72.3 TCP 80 25950 A 0040332E103C 00C07B4D7D81 IPv4 208.26.72.3 205.229.74.190 TCP 26000 80 S 02608CD87517 00C07B4D7D81 ARP A:request ETH:IPv4 208.26.72.2 208.26.72.1 00C07B4D7D81 02608CD87517 ARP A:reply ETH:IPv4 208.26.72.1 208.26.72.2 0040332E103C 00C07B4D7D81 ARP A:request ETH:IPv4 208.26.72.3 208.26.72.1 00C07B4D7D81 0040332E103C ARP A:reply ETH:IPv4 208.26.72.1 208.26.72.3 00C07B4D7D81 0040332E103C IPv4 208.26.72.1 208.26.72.3 ICMP redirect host 208.26.72.4
And the report it can generate:
Total: 64,813 13.45M
IPv4 64,017 12.55M
ICMP 245 16.34K
echo reply 18 1.23K
error 147 10.15K
host unreachable 4 436
port unreachable 142 9.68K
comm prohibited by filters 1 46
redirect 8 368
host 8 368
echo request 18 1.21K
TTL 54 2.43K
> 0 during transit 54 2.43K
TCP 58,998 11.66M
UDP 4,774 516.03K
ARP 796 33.38K
A:request 425 17.35K
A:reply 371 16.03K
Generating that report while the program is running was tricky. I didn't
want to loose any packets so creating a thread or process (I am doing this
under Unix) to handle that should minimize the number of packets lost. I'll
skip threads since personally I don't like the way pthreads works
(I think the API sucks but that's me and I really can't quantify it more
than that) and that leaves fork() (at least under Unix).
But I don't feel that good about the code, since I'm now dealing with signals, and the semantics of signals under Unix is … well … it sucks. I'm sure I have race conditions in there.
![Glasses. Titanium, not steel. [Self-portrait with my new glasses]](https://www.conman.org/people/spc/about/2025/0925.t.jpg)