gregtampa / coreemu

Automatically exported from code.google.com/p/coreemu
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

EMANE 0.8.1 #206

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. use core 4.5
2. use emane 0.8.1 with 802.11
3. drag nodes on the canvas
4. open some tcpdump and use ping to measure connectivity 

CORE seems not updating nodes' position to EMANE 0.8.1, so e.g. making close 
nodes does not change the initial connectivity condition.
The problem there is not with EMANE 0.7.4

Original issue reported on code.google.com by and.de...@gmail.com on 29 May 2013 at 11:35

GoogleCodeExporter commented 9 years ago
Is emane_event_monitor=False set in your /etc/core/core.conf file?

You can use 'tcpdump -nli eth0 port 45703' to verify that CORE is generating 
EMANE location events out e.g. eth0. You need a default route or a default 
multicast route in order for the EMANE events to be sent (to the multicast 
group).

Regarding initial connectivity, there was a change since 4.5 was released to 
generate extra location events upon startup. During startup, not all NEMs may 
be ready when the initial position event is generated. You can try the latest 
SVN snapshot to see if this fixes your problem.

Original comment by ahrenh...@gmail.com on 29 May 2013 at 3:04

GoogleCodeExporter commented 9 years ago
Any update on the requested details for this issue?

Original comment by ahrenh...@gmail.com on 24 Jun 2013 at 5:20

GoogleCodeExporter commented 9 years ago
No news since I finally switched to CORE with NS3 that seems to me less CPU
hungry.

Original comment by and.de...@gmail.com on 25 Jun 2013 at 9:37

GoogleCodeExporter commented 9 years ago
Assume this is related to a bug in EMANE 0.8.1:
http://pf.itd.nrl.navy.mil/pipermail/emane-users/2013-July/000543.html

The bug may cause EMANE to use stale pathloss and propagation time with the 
Universal PHY.

Original comment by ahrenh...@gmail.com on 7 Aug 2013 at 10:21