How do I check the auto-negotiated speed of a network interface on OpenBSD?
When I force a specific speed, ifconfig will show it in the "media" line; but if the interface is in auto-negotiation mode, I can't find a way to retrieve the network speed effectively negotiated.
Thanks for your help!
If auto-negotiation is successful, you should also see it on the media line:
media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause)
The lack of the above output, or the need to force a particular speed, may indicate you have another problem (..bad cable; unsupported interface or hardware issue).
Related
I'm working on communicating embedded device via serial port for debug. The device supports only 1843200 bps for baud rate.
But, my usual terminal softwares (minicom, Teraterm) don't look like supporting such high baud rate as they are.
What I want to do using such terminal software is:
sending command string interactively
transporting file to the device
Thank you.
As I commented, I solved the problem myself and post it again.
Teraterm ... high baudrate can be set from CUI (command line), not GUI (926100, max).
teratermpro.exe /BAUD=1843200 /C=1
PuTTy ... Using "plink.exe" works with options like below:
plink.exe -serial \.\COM1 -sercfg 1843200,8,n,1,N
But, you could have to stop "plink" once by Ctrl-c and type like below:
plink.exe -serial com1 -sercfg 1843200,8,n,1,N < [file path]
Regarding Linux, I didn't find the way. It could be that the proper driver should be installed.
#thebusybee Thank you for your kind advice!
What baudrate that is supported by a certain UART device depends on hardware:
How high the clock source for the UART clock go.
What prescalers/divisors the UART hardware support when translating the clock source to it's own hardware peripheral clock.
Some general rule of thumb is that divisors should not give more than 3% inaccuracy from the requested baudrate. More than that and you risk spurious data corruption, framing errors and similar.
Therefore software might limit the number of supported baudrates, not to correct higher ones that will be wildly inaccurate anyway.
Needless to say your embedded device also needs good clock accuracy, so if you are clocking it from something like an internal RC oscillator while running UART at 1.8MHz, you are very likely doing it wrong.
In ttermpro you can manually set the desired baudrate even if it does not show up in the drop-down list. Just type it into the field.
I have an FPGA (Like most of the people asking this question) that gets configured after my Linux kernel does the initial PCIe bus scan and enumeration. As you can guess, the FPGA implements a PCIe endpoint.
I would Like to have the PCIe core re-enumerate the ENTIRE PCIe bus so that my FPGA will then show up and I can load my driver module. I would also like the ability to SWAP the FPGA load out for a different configuration. By this I mean I would like to be able to:
Boot Linux
Configure FPGA
Enumerate PCIe endpoint and load module
Remove PCIe endpoint
Re-configure FPGA
Re-enumerate PCIe endpoint
All without rebooting Linux
Here are solutions that have been proposed elsewhere but do not solve the problem.
echo 1 > /sys/bus/pci/rescan This seems to work (only sometimes) and it does not work if I want to hotswap the FPGA load after it was first enumerated.
Can the Hotplug/power managment facilities of PCIe be used to make this work? If so is there any good resources for how to use the Hotplug system with PCIe? (LDD does not quite cover it thoroughly enough)
Re-enumerating the PCIe bus/tree via echo 1 > /sys/bus/pci/rescan is the correct solution. We are using it the same way as you described it.
We are using echo 1 > $pcidevice/remove to disconnect the driver from the device and to detach the device from the tree. The driver (xillybus) is not unloaded, just disconnected.
A better solution is to rescan only the node where your FPGA is attached to. This reduces the over all impact for the system.
This technique is used in the RC3E FPGA cloud system.
This is really dependent on exactly what is changed on the FPGA. The problem is in how PCIe enumeration and address assignment is done, particularly how the PCIe switches are configured. The allocation MUST be done in one shot as a depth-first search. After this is complete, it is not possible to go insert additional bus numbers or address space without changing all of the subsequent allocations, which would require reloading all of the corresponding device drivers. Basically, once the bus is enumerated and addresses are assigned, you can't change the overall allocations without re-enumerating the entire bus, which requires a reboot. Preallocating resources on a specific PCIe port can alleviate this problem, and is required for PCIe hot plugging.
If the PCIe BAR configuration has not changed, then usually doing a remove/hot reset/rescan is sufficient and no reboots are required.
If the BAR configuration has changed, then it's a different story. If the new BARs are smaller, then there should be no problem. But if the new BARs are larger or there are more BARs, if there isn't enough address space allocated to the switch port that the device is attached to, then those BARs cannot be allocated address space and the device will fail to enumerate. In this case, a reboot is required to so that resources can be reassigned. Don't forget that there are also 32 bit BARs and 64 bit BARs and these BARs are assigned form two different pools of address space, so changing BAR types can also require a reboot to re-enumerate.
If you're going from no device to a device (i.e. blank FPGA to configured FPGA), then bus numbers may need to be reassigned, which requires a reboot.
From The Doctor
Here is how to reset the Vegas before same as a reset in windows. This is based on the Vendor ID.
lspci -n | grep 1002: | egrep -v ".1"| awk '{print "find /sys | grep ""$1"/rescan" -| tac -;"}' | sh - | sed s/^/echo\ 1\ >\ "&/g | sed s/$/"/g
The output of that put in your /etc/rc.local to reset your Vegas after bootup similar to the devcon restart script.
echo 1 > "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/rescan"
echo 1 > "/sys/devices/pci0000:00/0000:00:1c.5/0000:03:00.0/rescan"
echo 1 > "/sys/devices/pci0000:00/0000:00:1d.0/0000:06:00.0/rescan"
echo 1 > "/sys/devices/pci0000:00/0000:00:1d.1/0000:07:00.0/rescan"
I have the following network setup:
[Customizable Wireless AP] ----- [Windows 7 Laptop]
In other words, my Win7 laptop is connected to a wireless access point which I can configure. I am using the Wireshark packet analyzer to monitor ping traffic.
My process is:
Set MTU of the AP very low (500)
Verify AP MTU has taken effect
Start packet analyzer in Wireshark
Use ping www.google.com -f -l 700 to send an oversized packet
Actual Output:
Ping shows Packet needs to be fragmented but DF set., indicating that the MTU has been observed
Wireshark shows no traffic. No ICMP messages or traffic of any king.
Expected Output:
I expect ping to show Packet needs to be fragmented but DF set., indicating that the MTU has been observed
I expect Wireshark to show ICMP traffic where the AP informs Win7 that the packet is too large.
My Question:
How is Windows discovering or remembering the MTU without the AP (seemingly) ever informing it? Is there an MTU discovery mechanism built into Win7 that operates prior to the ping?
IPv4 uses Path MTU Discovery (PMTUD) to figure out the MTU and control the fragmentation. There is a 3-bit flag field in IP header that will determine how fragmentation of a packet should be performed:
bit 0: Reserved; must be zero
bit 1: Don't Fragment (DF)
bit 2: More Fragments (MF)
If the DF bit is set, then any device along the path with MTU smaller than the packet will drop it and send back an ICMP message requesting fragmentation. However, ICMP message might blocked due to security reason. Therefore you cannot see any of it.
How to uniquely identify computer (mainboard) using C#(.Net/Mono, local application)?
Edition. We can identify mainboard in .Net using something like this (see Get Unique System Identifiers in C#):
using System.Management;
...
ManagementObjectSearcher searcher = new ManagementObjectSearcher("select * from Win32_MotherboardDevice");
...
But unfortunately Mono does not support System.Management. How to do it under Mono for Linux? - I don't know :(
Write a function that takes a few unique hardware parameters as input and generates a hash out of them.
For example, Windows activation looks at the following hardware characteristics:
Display Adapter
SCSI Adapter
IDE Adapter (effectively the motherboard)
Network Adapter (NIC) and its MAC Address
RAM Amount Range (i.e., 0-64mb, 64-128mb, etc.)
Processor Type
Processor Serial Number
Hard Drive Device
Hard Drive Volume Serial Number (VSN)
CD-ROM / CD-RW / DVD-ROM
You can pick up a few of them to generate your unique computer identifier.
Please see: Get Unique System Identifiers in C#
You realistically have MotherboardID, CPUID, Disk Serial and MAC address, from experience none of them are 100%.
Our stats show
Disk serial Is missing 0.1 %
MAC Is missing 1.3 %
Motherboard ID Is missing 30 %
CPUID Is missing 99 %
0.04% of machines tested yielded no information, we couldn't even read the computer name. It maybe that these were some kind of virtual PC, HyperV or VMWare instance, or maybe just very locked down? In any case your design has to be able to cope with these cases.
Disk serial is the most reliable, but easy to change, mac can be changed and depending on the filtering applied when reading it can change if device drivers are added (hyperv, wireshark etc).
Motherboard and CPUID sometimes return values that are invalid "NONE", "AAAA..", "XXXX..." etc.
You should also note that these functions can be very slow to call (they may take a few seconds even on a fast PC), so it may be worth kicking them off on a background thread as early as possible, you ideally don't want to be blocking on them.
Try this:
http://carso-owen.blogspot.com/2007/02/how-to-get-my-motherboard-serial-number.html
Personally though, I'd go with hard drive serial number. If a mainboard dies and is replaced, that PC isn't valid any more. If the HDD drive is replaced, it doesn't matter too much because the software was on it.
Of course, on the other hand, if the HDD is just moved elsewhere, the information goes with it, so you might want to look at a combination of serial numbers, depending what you want it for.
How about the MAC address of the network card?
I'm working on a network-related project and I am using DTLS (TLS/UDP) to secure communications.
Reading the specifications for DTLS, I've noted that DTLS requires the DF flag (Don't Fragment) to be set.
On my local network if I try to send a message bigger than 1500 bytes, nothing is sent. That makes perfect sense. On Windows the sendto() reports a success but nothing is sent.
I obviously cannot unset the DF flag manually since it is mandatory for DTLS and i'm not sure whether the 1500 bytes limit (MTU ?) could change in some situations. I guess it can.
So, my question is : "Is there a way to discover this limit ?" using APIs ?
If not, what would be the lowest possible value ?
My software runs under UNIX (Linux/MAC OSX) and Windows OSes so different solutions for each OS are welcome ;)
Many thanks.
There is a minimum MTU that must be supported - 576 bytes, including IP headers. So if you keep your packets below that, you don't have to worry about PMTU-D (that's what DNS does).
you probably need to 'auto tune' it by sending a range of packet sizes to the target, and see which arrive. think binary_search ...