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 5 years ago.
Improve this question
hopefully someone can help me.
I have a DHCPD/PXE Server that seems to be assigning 2 IP addresses for the same mac address.
I need computers getting assigned ip addresses to be sequential
I have tried "allow duplicates;" and "deny duplicates;"
I can see the ONLY difference is this "uid" line.
Other than this annoyance -- my dhcpd/pxe server works fine.
Heres a snippet from my Leases File:
lease 10.11.46.227 {
starts 4 2014/10/02 15:01:06;
ends 0 2150/11/08 21:29:20;
cltt 4 2014/10/02 15:01:06;
binding state active;
next binding state free;
hardware ethernet 00:1e:67:b9:32:f6;
uid "\000\215\013\011b\345\227\021\343\270\270\000\036g\2712\366";
}
lease 10.11.46.228 {
starts 4 2014/10/02 15:09:13;
ends 0 2150/11/08 21:37:27;
cltt 4 2014/10/02 15:09:13;
binding state active;
next binding state free;
hardware ethernet 00:1e:67:b9:32:f6;
}
Here is my dhcpd.conf
allow booting;
allow bootp;
authoritive;
deny duplicates;
class "pxeclients" {
match if substring(option vendor-class-identifier,0,9) = "PXEClient";
next-server 10.11.0.1;
filename "pxelinux.0";
}
subnet 10.11.0.0 netmask 255.255.0.0 {
range 10.11.1.1 10.11.25.200;
default-lease-time 4294967294;
max-lease-time 4294967294;
min-lease-time 4294967294;
}
# Pxe Server so it doesnt get changed.
host masterPXE {
hardware ethernet 00:1E:67:98:D5:EB;
fixed-address 10.11.0.1;
}
I've seen this with linux systems that have ip=dhcp enabled in kernel options and then a secondary dhcp client that runs in userland that re-requests an IP address.
The easiest solution is to just set your max-lease-time to something small like 5 minutes, or remove the dhcp host id from the user-land client so that it looks like the client is just asking for another DHCP address when it already has one.
Related
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 6 years ago.
Improve this question
I have a USB touchscreen connected to my hardware setup. and when I use cat /proc/bus/input/devices I get the following details about my device:
I: Bus=0003 Vendor=2965 Product=5023 Version=0110
N: Name="Kortek Kortek Touch"
P: Phys=usb-0000:00:14.0-3.4/input2
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.4/3-3.4:1.2/0003:2965:5023.0006/input/input7
U: Uniq=S20131028
H: Handlers=mouse1 event7 js0
B: PROP=0
B: EV=1b
B: KEY=30000 0 0 0 0 0 0 0 0
B: ABS=3
B: MSC=10
I want to know what does the line S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.4/3-3.4:1.2/0003:2965:5023.0006/input/input7 means. How to read it ? What are the numbers in the path ?
The Sysfs attribute is the location of that device within the sysfs filesystem. Assuming your kernel was compiled with CONFIG_SYSFS and the sysfs filesystem is mounted to /sys, you can view the device at:
/sys/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.4/3-3.4:1.2/0003:2965:5023.0006/input/input7
To break down what path represents:
/sys/ is the mountpoint of the sysfs filesystem (see the output of mount | grep sysfs).
/devices/ contains a filesystem representation of the device tree (source).
/pci0000:00/ describes the PCI domain and the bus number. In this case, the domain number is 0000 and the bus number is 00 (source).
/0000:00:14.0/ has the the PCI domain and bus number repeated, along with the slot and function. In this case, the USB device's slot number is 14 and its function number is 0 (source).
/usb3/ refers to USB controller attached to bus number 3 (source).
/3-3/3-3.4/3-3.4:1.2/ has redundant information. The last /3-3.4:1.2/ means you are referring to the USB controller attached to bus 3, port 3, port 4, configuration number 1 and interface number 2 (source).
/0003:2965:5023.0006/ means the device is attached to bus 0003, has a vendor ID of 2965, and a product ID of 5023.
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 6 years ago.
Improve this question
I installed openstack via devstack on Ubuntu 14.04. I have got 8 gb of ram on my computer and i have created around 8 VM's which i don't use simultaneously as I use the VM differently.
Now i cannot create any more VM's. I get an error message
No Valid Host was found.
there are not enough hosts available.
Can someone advice what should i do?
Since you say that this is a devstack installation, I'm assuming that you aren't running this in a production environment. Openstack allows users to bump up their over-subscription ratio for the RAM. By default, it is kept at 1.5 times the physical RAM available in the machine. Hence, it should be 12 Gb of usable memory. To change the subscription ratio:
sudo vim /etc/nova/nova.conf
#Add these two lines
ram_allocation_ratio=2
cpu_allocation_ratio=20 # Default value here is 16
These values are just a rough estimate. Change the values around to make them work for your environment. Restart the Devstack.
To check if the changes were made, log into mysql (or whichever DB is supporting devstack) and check:
mysql> use nova;
mysql> select * from compute_nodes \G;
*************************** 1. row ***************************
created_at: 2015-09-25 13:52:55
updated_at: 2016-02-03 18:32:49
deleted_at: NULL
id: 1
service_id: 7
vcpus: 8
memory_mb: 12007
local_gb: 446
vcpus_used: 6
memory_mb_used: 8832
local_gb_used: 80
hypervisor_type: QEMU
disk_available_least: 240
free_ram_mb: 3175
free_disk_gb: 366
current_workload: 0
running_vms: 4
pci_stats: NULL
metrics: []
.....
1 row in set (0.00 sec)
The Scheduler looks at the free_ram_mb. If you have a free_ram_mb of 3175 and if you want to run a new m1.medium instance with 4096M of memory, the Scheduler will end up with this message in the logs:
WARNING nova.scheduler.manager Failed to schedule_run_instance: No valid host was found.
Hence, make sure to keep an eye out for those when starting a new VM after making those changes.
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 2 years ago.
Improve this question
What does the selector (parameter sel) in the "ip xfrm state add" command achieve?
The source and destination addresses (and additional parameters like ports and protocol) are set in the ID section, but the selector contains a supplementary set of these. Example:
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 proto esp spi 123456 sel src 10.0.0.3 dst 10.0.0.4 enc blowfish 0xaabbccddee
This leads to the following result:
src 10.0.0.1 dst 10.0.0.2
proto esp spi 0x0001e240 reqid 0 mode transport
replay-window 0
enc cbc(blowfish) 0xaabbccddee
sel src 10.0.0.3/32 dst 10.0.0.4/32
Setkey seemingly does not have the opportunity to add such a selector value. It also does not show selectors in the output. The xfrm command from above produces the following "setkey -D" output:
10.0.0.1 10.0.0.2
esp mode=transport spi=123456(0x0001e240) reqid=0(0x00000000)
E: blowfish-cbc aabbccdd ee
seq=0x00000000 replay=0 flags=0x00000000 state=mature
created: Nov 26 01:25:39 2013 current: Nov 26 01:26:07 2013
diff: 28(s) hard: 0(s) soft: 0(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=0 pid=6959 refcnt=0
So what does the IPsec subsystem eventually do with this selector?
It is probably straight from the IPsec standard (RFC 4301: Security Architecture for the Internet Protocol).
Probably is because the standard describes "nominal model" i.e. implementations do not have to be exactly as described.
In Section 4.4.2. Security Association Database (SAD):
For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST be initially populated with the value or values negotiated at the time the SA was created. ... For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the elector values negotiated for the SA. Thus, the SAD acts as a cache for checking the selectors of inbound traffic arriving on SAs. For the receiver, this is part of verifying that a packet arriving on an SA is consistent with the policy for the SA.
In Section 5.2. Processing Inbound IP Traffic (unprotected-to-protected):
IPsec MUST perform the following steps:
...
3a. If the packet is addressed to the IPsec device and AH or ESP is specified as the protocol, the packet is looked up in the SAD. ... If the packet is found in the SAD, process it accordingly (see step 4).
4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received.
5. If an IPsec system receives an inbound packet on an SA and the packet's header fields are not consistent with the selectors for the SA, it MUST discard the packet.
In short for your example
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 proto esp spi 123456 sel src 10.0.0.3 dst 10.0.0.4 enc blowfish 0xaabbccddee
when IPsec (ESP in this case) packet arrives at the server, then probably the following happens:
the part src 10.0.0.1 dst 10.0.0.2 proto esp spi 123456 is used to find the corresponding SA.
The SA is used to decrypt the packet's payload.
Payload in transport mode IPsec is another IP packet.
the part sel src 10.0.0.3 dst 10.0.0.4 is the selector from the SP which was used to create our SA.
This selector is applied to the inner IP packet to verify that it is consistent with the SP.
Selector is used in tunnel mode. i.e. networks that are (inter)connected by tunnel.
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 7 years ago.
Improve this question
I have a setup where 2 pc with Linux is trying to communicate with RS232 Serial and Ethernet.
One of the PC, PC(B), I'm using USB<->RS232 connnector. When PC(A) issue a command for it to restart, PC(B) restarts but while booting up again, it received garbage messages at PC(A) from PC(B). PC(A) is still listening at the serial port. Some of these garbage messages happen to be what I'm listening for, which is not nice!
Anyone knows what those messages are? Is there a way to remove them? Does Centos sends some initializing message for testing purpose or what? How about other distribution of Linux?
Thanks in advance if anyone knows what is going on. =)
You can't expect a USB serial converter to be well behaved through a system restart. There's a period where the device is uninitialized, where it may produce glitches on the data lines. Any toggles on the data line will appear as garbage Rx data on A.
If you want to do what you intend, you will have to put some code on A to look for the known startup message and discard any prepended garbage bytes.
I also noticed the garbage too. After trying several baud rates, I checked the signal using an oscilloscope*. It turned out that the message is a valid output, not the result of random signals. It is sent on 9600 baud, 8N1, and it is something like a binary countdown. Specifically the following bytes are sent (in hex):
11, 10, 0F, 0E, 0D, 0C, 0B, 0A, 09, 08, 07, 06, 05, 04, 03, 02, 01, 00
These bytes are sent around the same time as when the login prompt is displayed on the (video) console. There is another very short signal sequence quite earlier in the boot process, a fast, 20 us impulse followed by a 10 us one. This sequence is too short to decide whether it is actual data or only the byproduct of some kind of switching.
I have not noticed anything on a Windows 7 desktop with a PCI serial controller card, which uses the MCS9865 chip according to its documentation.
The box is running Ubuntu 12.10. Linux kernel version is 3.5.0. The serial port controller is on a PCI Express card, lspci identifies it as "NetMos Technology PCIe 9922 Multi-I/O Controller".
It could be the BIOS. A colleague of mine noticed that his laptop gave out the BIOS version number and some more info over RS-232 at 115200 bps during bootup.
Try listening at the RS-232 at different baud rates; you may see something that makes sense.
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 4 years ago.
Improve this question
We have an home-brewed XMPP server and I was asked what is our server's MSL (Maximum Segment Lifetime).
What does it mean and how can I obtain it? Is it something in the Linux /proc TCP settings?
The MSL (Maximum Segment Lifetime) is the longest time (in seconds) that a TCP segment is expected to exist in the network. It most notably comes into play during the closing of a TCP connection -- between the CLOSE_WAIT and CLOSED state, the machine waits 2 MSL's (conceptually a round trip to the end of the internet and back) for any late packets. During this time, the machine is holding resources for the mostly-closed connection. If a server is busy, then the resources held this way can become an issue. One "fix" is to lower the MSL so that they are released sooner. Generally this works OK, but occasionally it can cause confusing failure scenarios.
On Linux (RHEL anyway, which is what I am familiar with), the "variable" /proc/sys/net/ipv4/tcp_fin_timeout is the 2*MSL value. It is normally 60 (seconds).
To see it, do:
cat /proc/sys/net/ipv4/tcp_fin_timeout
To change it, do something like:
echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout
Here is a TCP STATE DIAGRAM. You can find the wait in question at the bottom.
You can also see a countdown timer for sockets using -o in netstat or ss, which helps show concrete numbers about how long things will wait. For instance, TIME_WAIT does NOT use tcp_fin_timeout (it is based on TCP_TIMEWAIT_LEN which is usually hardcoded to 60s).
cat /proc/sys/net/ipv4/tcp_fin_timeout
3
# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24
NetidRecv-Q Send-Q Local Address:Port Peer Address:Port
tcp 0 0 192.168.100.1:57516 192.168.0.10:80 timer:(timewait,55sec,0)
tcp 0 0 192.168.100.1:57356 192.168.0.10:80 timer:(timewait,25sec,0)
tcp 0 0 192.168.100.1:57334 192.168.0.10:80 timer:(timewait,22sec,0)
tcp 0 0 192.168.100.1:57282 192.168.0.10:80 timer:(timewait,12sec,0)
tcp 0 0 192.168.100.1:57418 192.168.0.10:80 timer:(timewait,38sec,0)
tcp 0 0 192.168.100.1:57458 192.168.0.10:80 timer:(timewait,46sec,0)
tcp 0 0 192.168.100.1:57252 192.168.0.10:80 timer:(timewait,7.436ms,0)
tcp 0 0 192.168.100.1:57244 192.168.0.10:80 timer:(timewait,6.536ms,0)
This looks like it can answer your question:
http://seer.support.veritas.com/docs/264886.htm
I suggest that you ask why someone asked you this and find out how that applies to XMPP.
TCP/IP Illustrated volume 1 is online and describes 2MSL in more detail: Here
MSL is also described in the TCP RFC 793 as mentioned in wikipedia