More sniff.lsp woes...

[kanen]

Without sounding like I am complaining about it... sniff.lsp has given me nothing but trouble. I suspect I will have a complete rewrite of this code by the time kane|box is released.



As you know, I added pcap_open_offline so I could open pcap files instead of sniff traffic, which allows me to better control testing with known packets and files.



Today's problem;

Code Select Expand

$ newlisp src/sniff.lsp captures/tcp-scan.pcap
device: captures/tcp-scan.pcap

--- 1---  from ether addr: 00:30:0f:33:40:00 to: 02:00:00:00:45:00

ERR: value expected in function * : TH_OFF
called from user defined function report-packet

Yet, tcpdump handles this perfectly (or, as perfectly as tcpdump can);

Code Select Expand

$ tcpdump -ttttnnr captures/tcp-scan.pcap

2007-09-25 15:42:04.819943 IP 10.0.23.109.3574 > 80.237.98.132.2675: Flags [S],
seq 1439989931, win 65535, options [mss 1356,nop,nop,sackOK], length 0
2007-09-25 15:42:04.819979 IP 10.0.23.109.3547 > 80.237.98.132.1319: Flags [S],
seq 1043408690, win 65535, options [mss 1356,nop,nop,sackOK], length 0
...


The file in question is here: https://www.openpacket.org/uploads/0000/0029/tcp-scan.pcap">//https://www.openpacket.org/uploads/0000/0029/tcp-scan.pcap



Also, Wireshark has no problems reading this capture.

[Lutz]

It seems that TH_OFF is not defined. The sniff code, as it is, only defines TH_OFF if 'proto' has been set to a correct protocol value of either TCP, UDP or ICMP. If the package captured is not recognized as one of those, 'proto' is never set, and then the error occurs when TH_OFF is needed to calculate the payload length. The 'proto' variable as IP (zero) or as undefined 'nil' is not handled.



After the line:

Code Select Expand

(set 'protocol (lookup proto protocols))
you could add an option for 'proto' equals IP and handle that case. You could handle yet another branch if 'proto' hasn't been set at all, then dump the raw packet.



Also: the 'payload-len' may only be correct for TCP packages. For UDP and ICMP, I simply define payload for everything left after the respective header in the packet, either UDP or ICMP; both with a header length of 8 bytes.



I can experiment with pcap_open_offline and mal-formed packets, when I come back from Europe, hopefully this coming weekend, depending on volcanos ;-).

[kanen]

Yes, that's basically what I have been looking at doing. Right now, I am simply throwing the packet away, just to keep everything from falling apart. But, I will need to handle all protocols soon and that has become a high priority for me.



Thanks for looking at this and responding. I really appreciate it, even though I realize my last message may have sounded a bit... erhm... intense.



Now, if I could just convince you to create a (raw-packet) option in newLISP, my problems would be solved. ;P



Keep clear of those volcanoes!

It seems that TH_OFF is not defined. The sniff code, as it is, only defines TH_OFF if 'proto' has been set to a correct protocol value of either TCP, UDP or ICMP. If the package captured is not recognized as one of those, 'proto' is never set, and then the error occurs when TH_OFF is needed to calculate the payload length. The 'proto' variable as IP (zero) or as undefined 'nil' is not handled.



After the line:

Code Select Expand

(set 'protocol (lookup proto protocols))
you could add an option for 'proto' equals IP and handle that case. You could handle yet another branch if 'proto' hasn't been set at all, then dump the raw packet.



Also: the 'payload-len' may only be correct for TCP packages. For UDP and ICMP, I simply define payload for everything left after the respective header in the packet, either UDP or ICMP; both with a header length of 8 bytes.



I can experiment with pcap_open_offline and mal-formed packets, when I come back from Europe, hopefully this coming weekend, depending on volcanos ;-).