From vern at ee.lbl.gov Fri Sep 11 23:51:11 1998 From: vern at ee.lbl.gov (Vern Paxson) Date: Fri, 11 Sep 1998 23:51:11 -0700 (PDT) Subject: Testing #2 Message-ID: <199809120651.XAA18352@daffy.ee.lbl.gov> testing, testing, testing From DMiller at atvsi.com Mon Sep 14 13:12:48 1998 From: DMiller at atvsi.com (Don Miller) Date: Mon, 14 Sep 1998 16:12:48 -0400 Subject: Compile Errors in Linux Message-ID: <94DAC4B8C0CBD0118E0200000000000141508B@kojak.atvsi.com> Group, I am using linux version 5.2 to compile the bro software. I am having problems with the DNS.cc source code. The error has to do with the "void DNS_Mgr::AddResult function. There is a message that says there is a syntax error before the ( on line 688. Has anyone seen this? Don Miller From zab at zabbo.net Mon Sep 14 13:47:21 1998 From: zab at zabbo.net (Zach Brown) Date: Mon, 14 Sep 1998 13:47:21 -0700 (PDT) Subject: Compile Errors in Linux In-Reply-To: <94DAC4B8C0CBD0118E0200000000000141508B@kojak.atvsi.com> Message-ID: On Mon, 14 Sep 1998, Don Miller wrote: > Group, > > I am using linux version 5.2 to compile the bro software. I am having > problems with the DNS.cc source code. The error has to do with the > "void DNS_Mgr::AddResult function. > > There is a message that says there is a syntax error before the ( on > line 688. Has anyone seen this? It helps if you give us the output of whatever is giving you the error, and linux 5.2? whats that? :) it seems there is a collision between a member of nb_dns_result and .. the attached patch is an ugly nasty hack that gets it to compile.. then you get to run into collisions in TCP.h.. I don't have time now, but maybe later I'll try to get this to compile under glibc and linux. -- zach --- DNS.cc.old Mon Sep 14 13:41:33 1998 +++ DNS.cc Mon Sep 14 13:42:10 1998 @@ -22,6 +22,7 @@ #include #include #include +#undef h_errno /* collides w/ member in struct in nb_dns.h */ #include #include #include --- nb_dns.c.old Mon Sep 14 13:41:40 1998 +++ nb_dns.c Mon Sep 14 13:42:01 1998 @@ -43,6 +43,7 @@ #include #include #include +#undef h_errno /* collides w/ member in struct in nb_dns.h */ #include #include #include From cmiller at surfsouth.com Mon Sep 14 14:00:52 1998 From: cmiller at surfsouth.com (cmiller at surfsouth.com) Date: Mon, 14 Sep 1998 17:00:52 -0400 Subject: config empty lists Message-ID: <19980914170052.A5881@surfsouth.com> Forgive my ignorance, please. In the runtime configs, fresh out of the tarball, there are several lists (eg, const ``NFS_world_servers = { ... }'' in portmapper.bro) that I don't wish to have any elements. I may eventually want to use these, as I grow more experienced with BRO and want to refine my usage of it, but at the moment, I have no use for this list. By removing the elements, and leaving an empty ``{ }'' (in perl- style), I see messages like ``error: parse error, at or near "}"'' . Is my only alternative to remove all references to this list in the files? A config DTD would be nice, but I'll settle for a hint, and resort to patching the sources if necessary. Thanks, - chad ObErrors: - -- const NFS_world_servers = - -- const NFS_world_servers = { }; - -- const NFS_world_servers = { [ ], }; - -- const NFS_world_servers; - -- const NFS_world_servers = []; - -- const NFS_world_servers = (); - -- From olav.kolbu at usit.uio.no Mon Sep 14 15:31:46 1998 From: olav.kolbu at usit.uio.no (Olav Kolbu) Date: Tue, 15 Sep 1998 00:31:46 +0200 (METDST) Subject: Compile Errors in Linux In-Reply-To: Message-ID: > On Mon, 14 Sep 1998, Don Miller wrote: > > > Group, > > > > I am using linux version 5.2 to compile the bro software. I am having > > problems with the DNS.cc source code. The error has to do with the > > "void DNS_Mgr::AddResult function. > > > > There is a message that says there is a syntax error before the ( on > > line 688. Has anyone seen this? Just gave it a try on my RedHat 5.1 box, and there are a whole number of things you have to fix to get it to compile properly. Not for the faint of heart here... Here is a quick list for the impatient, not sure what approach the maintainer wants to take regarding Linux support so I'm leaving out the actual diffs (these are too nasty for production anyway ;-). 0. The h_errno has to be #undef'ed sometime after including 'netdb.h' in DNS.cc. This is because netdb.h re-#defines it to something unsuitable. Defining '_LIBC', e.g. adding -D_LIBC to your CFLAGS line in Makefile gives the same effect. 1. Some values in the enumeration 'EndpointState' (various source files) conflicts with already enumerated types in /usr/include/linux/tcp.h Rename the enumerated values that conflict (and do the same in the source files), or comment out the whole typedef from TCP.h. Commenting out will force you to change 'EndpointState' to say 'unsigned char' in the relevant places in the source, and you also need to explicitly #define TCP_INACTIVE, TCP_PARTIAL, TCP_CLOSED and TCP_RESET to some unique values above 11 (thats where the relevant system ones stop on my box). 2. _All_ the members of the tcphdr and udphdr structs have different names under Linux compared to what's expected in the source. Which basically means you have to edit a lot of files to fix this. The relevant system definitions are in /usr/include/linux/{tcp,udp}.h and look like this (these dumps primarily for the maintainer so he can have a look at doing linux support): struct tcphdr { __u16 source; __u16 dest; __u32 seq; __u32 ack_seq; #if defined(__LITTLE_ENDIAN_BITFIELD) __u16 res1:4, doff:4, fin:1, syn:1, rst:1, psh:1, ack:1, urg:1, res2:2; #elif defined(__BIG_ENDIAN_BITFIELD) __u16 doff:4, res1:4, res2:2, urg:1, ack:1, psh:1, rst:1, syn:1, fin:1; #else #error "Adjust your defines" #endif __u16 window; __u16 check; __u16 urg_ptr; }; struct udphdr { unsigned short source; unsigned short dest; unsigned short len; unsigned short check; }; Compare this to what say Solaris: struct tcphdr { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ #ifdef _BIT_FIELDS_LTOH u_int th_x2:4, /* (unused) */ th_off:4; /* data offset */ #else u_int th_off:4, /* data offset */ th_x2:4; /* (unused) */ #endif u_char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ }; struct udphdr { u_short uh_sport; /* source port */ u_short uh_dport; /* destination port */ short uh_ulen; /* udp length */ u_short uh_sum; /* udp checksum */ }; Note specifically the change from a single flags member that you typically 'tp->flags & TH_URG' to 'tp->urg'. The quick list of changes: TCP: th_off -> doff th_sport -> source th_dport -> dest th_flags & TH_SYN -> syn th_flags & TH_ACK -> ack etc etc just lowercase the #define and remove 'th_' on the various flags. th_seq -> seq th_ack -> ack_seq UDP: uh_sum -> check uh_ulen -> len uh_sport -> source uh_dport -> dest That should be it. I haven't done any tests at all, so the fixes above may or may not give you a bro that actually works. But at least it runs and it does produce what appears to be useful output. Note that I also had to change line 89 in policy/hot.bro from [external_routers, external_routers, bgp], to [external_routers, external_routers, 179/tcp], This is because (I presume, haven't read the source for the parser) bgp isn't defined in your average Linux /etc/services file. OK -- Olav Kolbu (Olav.Kolbu at usit.uio.no) Senoir System Administrator Center for Information Technology Services/Section for Operations University of Oslo P.O. Box 1059 Blindern, N-0316 Oslo, Norway Phone: +47 22 85 27 80, Fax: +47 22 85 27 30 From jordan at Thinkbank.COM Mon Sep 14 15:38:26 1998 From: jordan at Thinkbank.COM (Jordan Hayes) Date: Mon, 14 Sep 98 15:38:26 PDT Subject: Compile Errors in Linux Message-ID: <9809142238.AA22782@blood.Thinkbank.COM> From olav.kolbu at usit.uio.no Mon Sep 14 15:34:16 1998 _All_ the members of the tcphdr and udphdr structs have different names under Linux compared to what's expected in the source. Hey, you get what you pay for! :) /jordan From cmiller at surfsouth.com Mon Sep 14 15:46:11 1998 From: cmiller at surfsouth.com (cmiller at surfsouth.com) Date: Mon, 14 Sep 1998 18:46:11 -0400 Subject: Compile Errors in Linux In-Reply-To: <9809142238.AA22782@blood.Thinkbank.COM>; from Jordan Hayes on Mon, Sep 14, 1998 at 03:38:26PM -0700 References: <9809142238.AA22782@blood.Thinkbank.COM> Message-ID: <19980914184611.A6431@surfsouth.com> On Mon, Sep 14, 1998 at 03:38:26PM -0700, Jordan Hayes wrote: Hey, you get what you pay for! :) And you paid how much for BRO? :) At any rate, linux conventions should at least (or most, considering), be #ifdef'd in. I'll help; it's way too popular to ignore.. - chad From Markus.Friedl at informatik.uni-erlangen.de Mon Sep 14 23:13:19 1998 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 15 Sep 1998 08:13:19 +0200 Subject: Compile Errors in Linux In-Reply-To: <19980914184611.A6431@surfsouth.com>; from cmiller@surfsouth.com on Mon, Sep 14, 1998 at 06:46:11PM -0400 References: <9809142238.AA22782@blood.Thinkbank.COM> <19980914184611.A6431@surfsouth.com> Message-ID: <19980915081319.A7488@cip.informatik.uni-erlangen.de> On Mon, Sep 14, 1998 at 06:46:11PM -0400, cmiller at surfsouth.com wrote: > At any rate, linux conventions should at least (or most, considering), > be #ifdef'd in. I'll help; it's way too popular to ignore.. a better idea is: get a new version of the linux libc. at least version 5.4.46 has standard tcp/ip structures like BSD (struct tcphdr, struct ip). you may have to define __BSD_SOURCE for 'struct ip'. -markus From jordan at Thinkbank.COM Thu Sep 17 10:39:41 1998 From: jordan at Thinkbank.COM (Jordan Hayes) Date: Thu, 17 Sep 98 10:39:41 PDT Subject: 0.4 changes for FreeBSD 2.2.7-RELEASE Message-ID: <9809171739.AA06922@blood.Thinkbank.COM> I had a few problems in aux/hf ... In nf.l, I had to #include before because there's a prototype that uses 'struct in_addr' ... likewise in ef.l -- also around line 164 there's reference to a field ether_addr_octet that seems to be just 'octet' now. This looks like pretty old code, though. /jordan From vern at ee.lbl.gov Thu Sep 17 20:01:07 1998 From: vern at ee.lbl.gov (Vern Paxson) Date: Thu, 17 Sep 1998 20:01:07 PDT Subject: config empty lists In-Reply-To: Your message of Mon, 14 Sep 1998 17:00:52 PDT. Message-ID: <199809180301.UAA28475@daffy.ee.lbl.gov> [back from travel and now catching up on email] > In the runtime configs, fresh out of the tarball, there are several > lists (eg, const ``NFS_world_servers = { ... }'' in portmapper.bro) > that I don't wish to have any elements. I may eventually want to > use these, as I grow more experienced with BRO and want to refine > my usage of it, but at the moment, I have no use for this list. > > By removing the elements, and leaving an empty ``{ }'' (in perl- > style), I see messages like ``error: parse error, at or near "}"'' . > > Is my only alternative to remove all references to this list in > the files? You can change the definitions to: global NFS_world_servers: addr; You need to give a type since previously Bro was inferring it from the initialization list, but without any initializers it can't do this; and you need to make it "global" because Bro is unhappy with a "const" that's not initialized (I should probably change this). Vern From vern at ee.lbl.gov Thu Sep 17 20:13:17 1998 From: vern at ee.lbl.gov (Vern Paxson) Date: Thu, 17 Sep 1998 20:13:17 PDT Subject: Compile Errors in Linux In-Reply-To: Your message of Tue, 15 Sep 1998 08:13:19 PDT. Message-ID: <199809180313.UAA28672@daffy.ee.lbl.gov> Craig Leres is working on porting Bro to our local Linux box (the earlier patches were contributed by a 0.3 alpha tester for their particular Linux system). Expect a 0.5 release soon. There was a question earlier about replacing a use of "bgp" with 179/tcp and speculation that this is because the compiler reads /etc/services. That's right. This has turned out to be a portability headache. I guess the right way to fix it is to predefine a bunch of names for particular ports; I'm not all that happy with such a solution, though, because it eats up id's from the namespace, some of which are of no interest at all in some environments. Vern