enter image description hereI am doing CISCO packet tracer - Lab 08 – Configuring RIPv2, I get an error on part 1)a) of the lab where I need to (Use the appropriate command to create a default route on R1 for all Internet traffic to exit the network through S0/0/1). The error is "%Invalid interface type and number" after I used the command
"Router(config)#ip route 0.0.0.0 0.0.0.0 s0/0/1" I do not know why I got this error? May anyone help me understand why I got this error and how to fix it.
It can be due to 2 reasons I can think of
1. You do not have that interface ( try may be serial 0/0/1)
2. Its in shutdown mode
The red triangle means the interface is actually off , go to the router's cli
do these commands :
en
conf t
int s0/0/1
no shut
and then do the route again
Related
I am trying to configure 5GHz WiFi band for my new Beaglebone AI.
What I am doing is
cp /tmp/hostapd-bbai.conf to /etc/hostapd.conf
opening /etc/default/bb-wl18xx and changing USE_GENERATED_HOSTAPD to 'no'
USE_GENERATED_HOSTAPD=no
in order to use /etc/hostapd.conf file instead of generated conf file from /tmp
this method works perfect for 'b' and 'g' but I can not configure to 'a' in order to use 5GHz band
Can anyone help me regarding this?
this is my hostapd.conf
interface=SoftAp0
ssid=BeagleBone-59A4
hw_mode=a
channel=1
wmm_enabled=1
country_code=IN
ieee80211d=1
ieee80211n=1
ieee80211ac=1
wmm_enabled=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=BeagleBone
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
logger_syslog=-1
logger_syslog_level=2
New Beagle Bone AI WIFI stack is more powerful and its auto handle.
if still you facing issue regarding any other interfaces then please follow below link :
https://github.com/MalavPatel3501/BeagleBone-AI--mpBBAI-IO-Python-Library
In this project you got .dts file and all pin muxing steps. Moreover i puts some example code in this project.
I have installed condor 8.2.0 on several Win7 (32/64bit) computers according this guide: http://www.slideshare.net/gtelzur/condor8-win-install All the services run on the same machine and therefore I rule out a physical network interrupt.
Whenever a job is created/submitted, it stays in the idle mode. A detailed look a the log files unveil the following issue (ShadowLog):
07/07/14 08:10:47 (1.1) (PID1): **** condor_shadow (condor_SHADOW) pid PID1 EXITING WITH STATUS 107
07/07/14 08:10:47 (1.0) (PID2): condor_read() failed: recv(fd=540) returned -1, errno = 10054 , reading 5 bytes from startd slot1#mycomputer.mydomain.local.
07/07/14 08:10:47 (1.0) (PID2): IO: Failed to read packet header
07/07/14 08:10:47 (1.0) (PID2): Can no longer talk to condor_starter <192.168.25.120:56186>
I couldn't find more details about an IO exception with ID 10054. Beyond that Google does not give me useful hints if I search for "Condor IO: Failed to read packet header".
Do you have a clue what could address the issue?
I had the same issue and it was fixed when I reinstalled Condor in C:\Condor (it was in D:\Condor).
Note that with Condor 8.2.1 I ran into an unrelated problem: I had to edit the condor_config file and remove one $ in the line CONDOR_HOST = $$(FULL_HOSTNAME), as otherwise there was a parsing error.
When you see
condor_read() failed: .... reading 5 bytes from .....
In one of the log files, that usually means that the other side of the connection hung up, so you should look in the log file for the other side of the conversion. In this case, that would be the StarterLog.slot1 on mycomputer.mydomain.local (or possibly just the StarterLog, if the problem happens very early).
Usually when a daemon hangs up, the reason for the hang up is in the log, and very often the problem is that the other side of the conversation isn't authorized. See configuration values that match ALLOW_* to see what is authorized.
I have successfully installed the UHD device along side REDHAWK version 1.8.3. It isn't obvious to me how to connect a component in a waveform to a device being managed by a device manager. I am also unclear on the interplay between the IDL interfaces and the data ports on the USRP device.
I was unable to find a trivial example to send and receive waveform that utilizes the USRP device (e.g. a signal generator component sending a sine wave to the USRP). Does anyone have experience with this or any suggestions?
One way to connect a Component to a Device in a running environment is through the REDHAWK python module. It is able to attach to a running domain, query any launched Applications and connect Ports from Components to Devices. The following is an example python script (Note the ports must both be the same type in order for the connection to succeed):
from ossie.utils import redhawk
from ossie.cf import CF
# Connect to the running domain
domain = redhawk.attach("REDHAWK_DEV")
# Gets a reference to the running application
for app in domain.apps:
# Find desired application
if app.name == 'desired_name':
application = app
# Gets the component from the application
for comp in application.comps:
# Find desired component
if comp.name == 'desired_name':
component = comp
# Gets the device to connect
for devMgr in domain.devMgrs:
for dev in devMgr.devs:
# Find desired device
if dev.name = 'desired_name':
device = dev
# Gets the references to the input and output ports
comp_port = component.getPort('port_name')._narrow(CF.Port)
dev_port = device.getPort('port_name')
# Makes the actual connection
comp_port.connectPort(dev_port, 'ConnectionID')
# Make sure device is started
device.start()
# Start application
application.start()
# To disconnect:
# Stop device and application
application.stop()
device.stop()
comp_port.disconnectPort('ConnectionID')
There are multiple ways to accomplish this depending on your situations. Here are a few:
A.) Problem: You are debugging an issue in the IDE and quickly want to connect a device port to a component port
Solution: With the component and device both running in either domain or in the sandbox, expand the component and device in your SCA Explorer view to expose the ports. Click on the output port then ctrl+click the input port you would like to connect to. With both ports highlighted you can now right click and select Connect.
B.) Problem: You need a generic way of connecting a components input port, regardless of implementation language, to a particular type of devices output port, regardless of language implementation.
Solution: This is a multi-step process and is not that intuitive at first. I recommend you look at the SCA spec page D-43 for additional detail for step 10 and beyond below.
Open the component in your editor and navigate to the Implementations tab.
Right click on the implementation you would like to use for this connection (ex. python)
Select New → Uses Device
Generate (or enter) a unique DCE ID for this connection
Enter the type "usesDevice" although I'm not 100% sure if the type matters, I used usesDevice
Right click on the Uses Device select new Property Ref. You will not be directly connecting component X to device Y. Instead you are connecting component X to a device which meets the property restrictions set here. ie. model, type, etc.
In your device, in the properties tab, set a property like device_kind or device_model's Name field to something you want to match to. We'll say XYZ123 for an example. Save and deploy this to the SDR ROOT
Back in the component where we were setting the property Ref, select browse and select the property on the device you just set as your matching property.
Set the Value to the value you set it to ex XYZ123. Save and deploy the compnent
Now in your waveform, you'll need to hand edit the SAD file and add something like this, where [[TEXT]] indicates something for you to change:
<connections>
<connectinterface id="[[Connection_Name]]">
<usesport>
<usesidentifier>[[Output Port Name]]</usesidentifier>
<deviceusedbythiscomponentref refid="[[DCE matching the componentinstantiationID]]" usesrefid="[[DCE matching the generated ID from step 4]]"/>
</usesport>
<providesport>
<providesidentifier>[[Input Port Name]]</providesidentifier>
<componentinstantiationref refid="[[DCE matching the componentinstantiationID]]"/>
</providesport>
</connectinterface>
</connections>
I recommend you add a dummy component to your SAD editor and connect dummy component to the real compnent just so your SAD file is populated with the connectinterface block and you can see an example of a connection.
After making those changes, the IDE may tell you that an error exists in your SAD file, save anyway, close the SAD editor and reopen. If no error is displayed then your syntax is fine. Deploy the waveform and launch as usual.
C.) Problem: You want to connect to a device via a python script outside of REDHAWK, a python service within REDHAWK, or through a python component in your waveform.
Solution: See Adam's solution.
On Ubuntu 12.04 I am tring to get the subtree of management values with the following command:
snmpwalk -v 2c -c public localhost
with the last line of the output being
iso.3.6.1.2.1.25.1.7.0 = No more variables left in this MIB View (It is past the end of the MIB tree)
Is this an error? A warning? Does the subtree end there?
There's a bit more going on here than you might suspect. I encounter this on every new Ubuntu box that I build, and I do consider it a problem (not an error, but a problem--more on this down further).
Here's the technically-correct explanation (why this is not an "error"):
"No more variables left in this MIB View" is not particularly an error; rather, it is a statement about your request. The request started at something simple, say ".1.3" and continued to ask for the "next" lexicographic OID. It got "next" OIDs until that last one, at which point the agent has informed you that there's nothing more to see; don't bother asking.
Now, here's why I consider it a problem (in the context of this question):
The point of installing "snmpd" and running it is to gather meaningful information about the box; typically, this information is performance-oriented. For example, the three general things that I need to know about are network-interface information (IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets), disk information (UCD-SNMP-MIB::dskUsed and UCD-SNMP-MIB::dskTotal), and CPU information (UCD-SNMP-MIB::ssCpuRawIdle, UCD-SNMP-MIB::ssCpuRawWait, and so on).
The default Ubuntu "snmpd" configuration specifically denies just about everything useful with this configuration (limiting access to just enough information to tell you that the box is a Linux box):
view systemonly included .1.3.6.1.2.1.1
view systemonly included .1.3.6.1.2.1.25.1
rocommunity public default -V systemonly
This configuration locks the box down, which may be "safe" if it will be on an insecure network with little SNMP administration knowledge available.
However, the first thing that I do is remove the "-V systemonly" portion of the "rocommunity" setting; this will allow all available SNMP information to be accessed (read-only) via the community string of "public".
If you do that, then you'll probably see what you're expecting, which is pages and pages of SNMP information that you can use to gauge the performance of your box.
I know this thread is probably very old the I fix this is to use:
rocommunity public
and that should fix the problem.
Briefly, this is not an error, actually, when you "walk up" all OIDs on your agent, it will shows your this line>
Sometimes, it won't show you this line, because the last OID is not on your agent(you have already walk up all OIDs on your agent, but not walk up all OIDs).
$ snmpwalk -v 2c -c public localhost NET-SNMP-EXTEND-MIB::nsExtendObjects
NET-SNMP-EXTEND-MIB::nsExtendObjects = No more variables left in this MIB View (It is past the end of the MIB tree)
Also you can get this error while you can trying to see executed scripts I fix that problem to add
view all included .1 80
line to snmpd.conf than restart service
Than you will see your output going to change for both input
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I've just performed a new installation of the very latest (Fall, 2008) version of Fedora 9 Linux and am perplexed that it never set the default route properly and that even traveling the labyrinthine ways of this OS, there's no obvious way.
Of course, it's clear that one can do it on a one-off basis like this:
route add default gw gw1 metric 0 eth0
or like this:
ip route add to default via 192.168.2.1 protocol static
However, neither of these survives reboot. In reading through /etc/rc.d/init.d/network, it attempts to find data from a file in /etc/sysconfig/static-routes, but that file never existed. So, I tried to create it and populate it with data. The trouble with that is that the script places a dash (minus sign) in an odd spot that I'm not sure how to deal with.
Of course, one can just edit /etc/rc.d/init.d/network, but that would be non-standard. As it is, my only other recourse seems to be editing rc.local, but that doesn't come early enough in the boot sequence to be there for things like, for example, the network time daemon.
I've done my homework - I've read all the man pages, info entries, tried apropos, and I've even done a fair bit of web searching, all to no avail - my next step, sans answer here, will be to sign up to the Fedora mailing lists and ask there! Or, give up and edit the scripts.
So, how is one supposed to do this?
The gateway is normally set in /etc/sysconfig/network-scripts/ifcfg-eth0, not in /etc/sysconfig/network. For example, on my current machine:
/etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=flyboys
NISDOMAIN=ekcineon
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
HWADDR=00:1d:09:31:3a:cc
NETMASK=255.255.255.0
IPADDR=150.102.65.30
GATEWAY=150.102.65.252
TYPE=Ethernet
Note that I set HWADDR because I have two ethernet cards and I want to make sure the right one is assigned to eth0. The configuration for the second card is in /etc/sysconfig/network-scripts/ifcfg-eth1
just edit the /etc/sysconfig/network-scripts/route-ethXX
and write inside: default via ip_address dev device , replace ip_address with your gateway ip and device with the name of the right eth device. but for the Device option its ... optional, set it in the case of multiple eth devices.
Works even in case of network restart, the route directive in rc.local works at boot only.
I have not used recent versions of Fedora, but it was often set as a GATEWAY variable in /etc/sysconfig/network.
Of course, if you just wanted it to work, you could just put the commands in /etc/rc.local to be executed when the boot sequence completes.
You can use nmcli if available, e.i.
# nmcli con show
NAME UUID TYPE DEVICE
System eth0 xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet eth0
ens33 xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet --
# nmcli con edit "System eth0"
nmcli> goto ipv4
You may edit the following properties: method, dns, dns-search, dns-options, dns-priority, addresses, gateway, routes, route-metric, route-table, routing-rules, ignore-auto-routes, ignore-auto-dns, dhcp-client-id, dhcp-timeout, dhcp-send-hostname, dhcp-hostname, dhcp-fqdn, never-default, may-fail, dad-timeout
nmcli ipv4>
nmcli ipv4> print
['ipv4' setting values]
ipv4.method: manual
ipv4.dns: --
ipv4.dns-search: --
ipv4.dns-options: --
ipv4.dns-priority: 0
ipv4.addresses: 10.10.10.1/26
ipv4.gateway: 10.10.10.129
ipv4.routes: --
ipv4.route-metric: -1
ipv4.route-table: 0 (unspec)
ipv4.routing-rules: --
ipv4.ignore-auto-routes: no
ipv4.ignore-auto-dns: no
ipv4.dhcp-client-id: --
ipv4.dhcp-timeout: 0 (default)
ipv4.dhcp-send-hostname: yes
ipv4.dhcp-hostname: --
ipv4.dhcp-fqdn: --
ipv4.never-default: no
ipv4.may-fail: yes
ipv4.dad-timeout: -1 (default)
nmcli ipv4>
nmcli ipv4> set routes 192.168.122.0/24 10.10.10.1
nmcli ipv4> verify
Verify setting 'ipv4': OK
nmcli ipv4> save
nmcli ipv4> quit
#nmcli con up "System eth0"
And it should create file /etc/sysconfig/network-scripts/routes- with proper parameters, e.g.
ADDRESS0=192.0.2.0
NETMASK0=255.255.255.0
GATEWAY0=198.51.100.1
Haven't seen Fedora. But shouldn't there be some GUI for this kind of thing? If you have Gnome try running gnome-network-preferences
Here it is for RHEL, as it is slightly different:
Identify the interface by using ifconfig
sudo vi /etc/sysconfig/network-scripts/route-ethXX
add the routes as per syntax below, where /xx represents subnet mask
host: 172.30.xxx.xxx via 172.30.xxx.xxx
network: 172.30.xxx.xxx/xx via 172.30.xxx.xxx
Default gateway: 0.0.0.0 via xxx.xxx.xxx.xxx</li>
Save the file.
sudo /etc/init.d/network restart (Warning: if you forget to set
correct routes for the management interface (if applicable) you may lose
connectivity to the server)