From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20653 invoked by alias); 3 Mar 2013 16:17:23 -0000 Received: (qmail 20619 invoked by uid 22791); 3 Mar 2013 16:17:11 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,TW_CP X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 03 Mar 2013 16:17:06 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 57029468000F for ; Sun, 3 Mar 2013 16:17:03 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW9f3fl3ZzzE; Sun, 3 Mar 2013 16:17:01 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001789] New: Null pointer in snmp_send_trap and byte order inconsistency Date: Sun, 03 Mar 2013 16:17:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: lwIP X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mjones@linear.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org X-SW-Source: 2013/txt/msg00115.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001789 Bug ID: 1001789 Summary: Null pointer in snmp_send_trap and byte order inconsistency Product: eCos Version: CVS Target: All Architecture/Host All OS: Status: UNCONFIRMED Severity: normal Priority: low Component: lwIP Assignee: unassigned@bugs.ecos.sourceware.org Reporter: mjones@linear.com CC: ecos-bugs@ecos.sourceware.org I have found a couple of problems using lwip/snmp. I will describe them here and let let someone that knows lwip deal with them because I don't know the intent of the design and I would have a hard time deciding how to improve it. The first problem is snap_send_trap has a call to ip_route(...) shown below. If the IP address of the target platform does not match the trap destination, it returns a null. For example, with netmask 255.255.255.0, if the target platform is 192.168.0.2 and the trap destination is 192.168.1.5, ip_route(...) will return null. Then the code will operate on a null pointer. I think the call should either return an error, set an err value, or use an ASSERT, etc. Most people probably don't have a problem because they are on the same subnet. I only ran into the problem because I did not know that the ip_route() could not handle the more complex routing. snmp_send_trap(s8_t generic_trap, struct snmp_obj_id *eoid, s32_t specific_trap) { struct snmp_trap_dst *td; struct netif *dst_if; struct ip_addr dst_ip; struct pbuf *p; u16_t i,tot_len; for (i=0, td = &trap_dst[0]; ienable != 0) && (td->dip.addr != 0)) { /* network order trap destination */ trap_msg.dip.addr = td->dip.addr; /* lookup current source address for this dst */ dst_if = ip_route(&td->dip); dst_ip.addr = ntohl(dst_if->ip_addr.addr); The next problem is an inconsistency in IP representation handling. This code below works because it calls htonl(...) before snap_trap_dst_ip_set(...), which has another htonl(...) call. Most of the lwip takes an address in the form returned by IP4_ADDR(...). This inconsistency lead to some debug time trying to figure out why it did not work. struct ip_addr addr; IP4_ADDR(&addr, 192, 168, 1, 102); addr.addr = htonl(snmp_message->ADDRESS.addr); snmp_trap_dst_ip_set(0,&addr); Because this was tricky to make work the first time, I leave my code here for the next person trying this. I have not tested if this leaks memory yet, so if you use it, beware it might leak. The context is this code receives a message from a mailbox in an lwip thread. I don't know if I really need the callback or not. I found an example working in a similar way and used it. If nothing else this gives the context of how I am using lwip when I have the above two problems. // Code in lwip thread struct ip_addr addr; addr.addr = htonl(snmp_message->ADDRESS.addr); snmp_trap_dst_ip_set(0,&addr); snmp_trap_dst_enable(0,snmp_message->TRAP); struct snmp_varbind *vb = snmp_varbind_alloc(&objid, SNMP_ASN1_OPAQUE, strlen(snmp_message->message)); struct snmp_varbind_root *vb_root = (struct snmp_varbind_root *)malloc(sizeof(struct snmp_varbind_root));; memset(vb_root, 0, sizeof(struct snmp_varbind_root)); memcpy (vb->value, snmp_message->message, strlen(snmp_message->message)); snmp_varbind_tail_add(vb_root,vb); tcpip_callback(send_trap_callback, vb_root); void send_trap_callback( void * parameters ) { struct snmp_varbind_root *vb_root; if( parameters != NULL ) { vb_root = (struct snmp_varbind_root *) parameters; struct snmp_obj_id eoid; // there should be a way to do this directly. eoid.id[0] = enterprises_ids[1]; eoid.len = 1; trap_msg.outvb = *vb_root; snmp_send_trap(SNMP_GENTRAP_ENTERPRISESPC, &eoid, 1); // Need to know what should be freed. // message text? // struct snmp_varbind? // struct snmp_varbind_root? } } -- You are receiving this mail because: You are on the CC list for the bug.