[nycbug-talk] some C help?

[Charles Sprickman]

On Thu, 22 Mar 2007, Charles Sprickman wrote:
> On Sat, 10 Mar 2007, Brian A. Seklecki wrote:
>
>> 
>> This bug is pretty well documented in a ticket I opened with the NetBSD
>> folks on the default size of the "snaplen" size being determined based on
>> the presence of the IPv6 at compile-time v.s. run-time v.s "-i" argument.
>> 
>> http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=34733

Here's the answer to my bug report over at FreeBSD.

State-Changed-From-To: open->closed
State-Changed-By: remko
State-Changed-When: Fri Mar 23 06:43:45 UTC 2007
State-Changed-Why:
Please raise this with the tcpdump maintainers, they can change this and
we can import the new version if needed. Since this is a
vendor/contributed item, we are not going to change that locally.

Want to tag-team the tcpdump people? :)

Charles

>> -s 96 or -s 128 for the win.
>
> I told you guys I move slowly...
>
> I actually didn't want to touch spamlogd so I recompiled tcpdump with SPAPLEN 
> set to 96 for v4 or v6.  I'll need to see if there's a PR on this with 
> FreeBSD and if not file one referencing your NetBSD report.
>
> All seems well:
>
> Mar 22 03:03:31 slimjim spamlogd[700]: invalid ip address 10.10.10
> <restart spamlogd after rebuilding tcpdump>
> Mar 22 20:53:25 slimjim spamlogd[86729]: outbound 10.10.10.3
>
> [root at slimjim /usr/src/usr.sbin/tcpdump]# spamdb
> WHITE|10.10.10.154|||1173413700|1173415662|1176526099|4|0
> WHITE|10.10.10.3|||1174611205|1174611205|1177721605|1|0  <<-- bingo
> [root at slimjim /usr/src/usr.sbin/tcpdump]#
>
> Thanks again,
>
> Charles
>
>> ~BAS
>> 
>> 
>>>>> 
>>>>> Mar 10 00:09:24 slimjim spamlogd[72636]: invalid ip address 10.10.10
>>>>> 
>>>>> Note the lack of the final octet.
>>>>> 
>>>>> This is (I hope) the area where spamlogd parses the output of tcpdump:
>>>> 
>>>> yes, it is, but no need to analyze it...
>>>> 
>>>> it does its job correctly.
>>>> 
>>>>> That chunk makes very little sense to me.
>>>>> 
>>>>> Can anyone give me a quick shove in the right direction?
>>>> 
>>>> ...and the reason yours is failing is not because of that chunk of code,
>>>> but rather your pflog interface.  it should look like:
>>>>
>>>> 	[blah] 10.10.10.9.XXXX > 10.10.10.10.25: [blah]
>>>> 
>>>> where XXXX is an ephemeral port...basically your log is dropping the
>>>> port number. why? i don't know - what does your pf rule look like?
>>> 
>>> oh, and i'll add that -current (and 4.1) doesn't spawn tcpdump any more,
>>> but uses pcap directly....plus lots of other yummy features - ask for
>>> the port to get upgraded ;)
>>> _______________________________________________
>>> % NYC*BUG talk mailing list
>>> http://lists.nycbug.org/mailman/listinfo/talk
>>> %Be sure to check out our Jobs and NYCBUG-announce lists
>>> %We meet the first Wednesday of the month
>>> 
>> 
>> l8*
>> 	-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
>> 	       http://www.spiritual-machines.org/
>> 
>> "...from back in the heady days when "helpdesk" meant nothing, "diskquota"
>> meant everything, and lives could be bought and sold for a couple of pages
>> of laser printout - and frequently were."
>> _______________________________________________
>> % NYC*BUG talk mailing list
>> http://lists.nycbug.org/mailman/listinfo/talk
>> %Be sure to check out our Jobs and NYCBUG-announce lists
>> %We meet the first Wednesday of the month
>> 
>