libbsd.txt "test runner" realview_pbx_a9_qemu
Chris Johns
chrisj at rtems.org
Thu Jun 18 06:02:50 UTC 2015
On 18/06/2015 2:59 pm, Gene Smith wrote:
> On 06/09/2015 11:53 PM, Chris Johns wrote:
>>
>> I am seeing this with the Zynq without the cadence_gem patch. I am
>> seeing IP header check sum errors. I suggest you check the stats for the
>> receiving end of your ping. My trace is:
>>
>> # tcpdump -i bridge0 -vvvv ip host 10.10.5.15
>>
>>
>> tcpdump: listening on bridge0, link-type EN10MB (Ethernet), capture size
>> 65535 bytes
>> 12:42:23.262116 IP (tos 0x0, ttl 64, id 58748, offset 0, flags [none],
>> proto ICMP (1), length 84, bad cksum 0 (->7708)!)
>> 10.10.5.15 > 10.10.5.2: ICMP echo request, id 256, seq 0, length 64
>>
>
> I saw nothing at all with tcpdump using the vde_switch method.
>
I have the VDE switch up and working and stable. I have the real
ethernet interface and 3 taps connected to a bridge on a FreeBSD
machine. From /etc/rc.conf:
cloned_interfaces="bridge0 tap0 tap1 tap2"
autobridge_interfaces="bridge0"
autobridge_bridge0="re0 tap0 tap1 tap2"
ifconfig_re0="up"
ifconfig_tap0="up"
ifconfig_tap1="up"
ifconfig_tap2="up"
ifconfig_bridge0="inet 10.10.5.2 netmask 255.255.255.0"
defaultrouter="10.10.5.1"
I then connect the vde_switch to the first tap:
$ cat /etc/rc.local
#! /bin/sh
ifconfig bridge0 stp re0 stp tap0 stp tap1 stp tap2
#
# To manage: vdeterm /tmp/mgmt1
#
vde_switch -d -s /tmp/vde1 -M /tmp/mgmt1 -tap tap0 -m 660 --mgmtmode 660
The other taps are for virtual box VMs running Windows and other
operating systems. The important part was assigning the "hosts" IP
address to the bridge. This link gives some details ...
http://virtuallyhyper.com/2013/02/running-vms-on-freebsd-using-qemu-with-vde/
I can connect qemu to the bridge but I am yet to test the realview BSP
with the patch Sebastian posted.
>>
>> I do not see this. That period is weird. I wonder is this is something
>> in the PHY when attempting to create a link. Also could it be in the
>> host side related to opening the tap interface and maybe a DNS type
>> issue.
>
> I still see a long delay (30+ seconds) after it prints this line:
> smc0: <SMSC LAN91C110FD or LAN91C111FD> on nexus0
> but I haven't yet tried to determine why.
>
> After getting back to this I decided to try another method to get the
> ping01 test to run without using vde but using only tun/tap. First I
> tried various methods to "bridge" between tap and the host wireless
> interface, but apparently because it is wireless the bridging method
> wouldn't work. I was about to go ahead and connect an ethernet cable to
> my laptop when I found a way to work-around the wireless problem:
>
> https://shanetomlinson.com/2009/bridging-a-wireless-card-in-kvmqemu/
>
> This is a "slight" modification on another method described here:
>
> http://blog.bodhizazen.net/linux/bridge-wireless-cards/
>
> Based on these links, here are the steps I did to make it work on my LAN
> and laptop running fedora 21:
>
> 1. sudo yum install tunctl # (or install uml-utilites on debian and
> friends)
>
> 2. sudo tunctl -u gene # "gene" is my username
>
> 3. as root, enable arp proxy
> echo 1 > /proc/sys/net/ipv4/ip_forward
> echo 1 > /proc/sys/net/ipv4/conf/wlan0/proxy_arp
> echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp
> (Can set these back to 0 to disable when testing is finished.)
>
> 4. The "slight" modification is that guest and tap are assigned static
> addresses in a new subnet that differs from the LAN subnet:
> My lan: 192.168.1.0/24, wireless router 192.168.1.1 and host (laptop)
> address 192.168.1.134 (assigned via dhcp).
> Tap0 interface will be assigned the address 192.168.2.1 (the guest's
> gateway) and the guest will be assigned address 192.168.2.2. Tap0 must
> be brought up and a route established at the host to the guest:
>
> sudo ip link set tap0 up
> sudo route add -host 192.168.2.2 dev tap0
>
> 5. The tap and guest ip address are set via libbsd's config.inc. Here's
> my config file settings used to build libbsd:
>
> # Mandatory: Select your BSP and installation prefix
> TARGET = arm-rtems4.11
> BSP = realview_pbx_a9_qemu
> #PREFIX = /opt/rtems-4.11
> PREFIX = ${HOME}/rtems/install/4.11/$(BSP)
>
> # Optional: Separate installation base directory
> INSTALL_BASE = $(PREFIX)/$(TARGET)/$(BSP)
>
> # Optional: Network test configuration
> TEST_RUNNER = ${HOME}/rtems/rtems-testing/sim-scripts/$(BSP)
> NET_CFG_SELF_IP = 192.168.2.2 # <-- guest (rtems) addr
> NET_CFG_NETMASK = 255.255.255.0
> NET_CFG_PEER_IP = 192.168.1.24 # <-- ping destination on LAN
> NET_CFG_GATEWAY_IP = 192.168.2.1 # <-- tap0 interface address
> NET_TAP_INTERFACE = tap0
>
> 6. To run the ping test:
> qemu-system-arm -M realview-pbx-a9 -m 256M -no-reboot -monitor none
> -serial stdio -nographic -net nic -net tap,ifname=tap0,script=no -kernel
> ping01.exe
> audio: Could not init `oss' audio driver
> *** LIBBSD PING 1 TEST ***
> nexus0: <RTEMS Nexus device>
> smc0: <SMSC LAN91C110FD or LAN91C111FD> on nexus0
> devctl: !system=IFNET subsystem=smc0 type=ATTACH
> smc0: Ethernet address: 3537304
> devctl: +smc0 at on nexus0
> devctl: +nexus0 at on root0
> devctl: !system=IFNET subsystem=lo0 type=ATTACH
> add host 192.168.2.1: gateway smc0
> add net default: gateway 192.168.2.1
> PING 192.168.1.24 (192.168.1.24): 56 data bytes
> 64 bytes from 192.168.1.24: icmp_seq=3 ttl=63 time=8.876 ms
> 64 bytes from 192.168.1.24: icmp_seq=4 ttl=63 time=5.464 ms
> 64 bytes from 192.168.1.24: icmp_seq=5 ttl=63 time=5.584 ms
> 64 bytes from 192.168.1.24: icmp_seq=6 ttl=63 time=5.240 ms
> 64 bytes from 192.168.1.24: icmp_seq=7 ttl=63 time=5.936 ms
> 64 bytes from 192.168.1.24: icmp_seq=8 ttl=63 time=5.483 ms
> 64 bytes from 192.168.1.24: icmp_seq=9 ttl=63 time=5.443 ms
>
> --- 192.168.1.24 ping statistics ---
> 10 packets transmitted, 7 packets received, 30.0% packet loss
> round-trip min/avg/max/stddev = 5.240/6.004/8.876/1.189 ms
> Stack usage by thread
> ID NAME LOW HIGH CURRENT AVAILABLE USED
> 0x09010001 IDLE 0x003568d0 - 0x003578cf 0x00357790 4080 468
> 0x0a010001 UI1 0x00357b50 - 0x0035fb4f 0x0035f9a8 32752 3312
> 0x0a010002 TIME 0x003602a0 - 0x0036829f 0x003681c8 32752 728
> 0x0a010003 _BSD 0x0037a868 - 0x00382867 0x00382778 32752 1804
> 0x0a010004 _BSD 0x003829c8 - 0x0038a9c7 0x0038a8d8 32752 632
> 0x0a010005 _BSD 0x0038c320 - 0x0039431f 0x00394230 32752 396
> 0x0a010006 _BSD 0x003943f0 - 0x0039c3ef 0x0039c2f0 32752 412
> 0x0a010007 _BSD 0x0039c5a8 - 0x003a45a7 0x003a44b8 32752 396
> 0x0a010008 _BSD 0x003a4678 - 0x003ac677 0x003ac578 32752 412
> 0x0a010009 IRQS 0x003ac6e0 - 0x003b46df 0x003b4600 32752 480
> 0x0a01000a _BSD 0x003b5000 - 0x003bcfff 0x003bcf00 32752 1396
> *** END OF TEST LIBBSD PING 1 ***
> qemu-system-arm: network script /etc/qemu-ifdown failed with status 256
>
> Note: usually the first few pings fail then it is OK. I have increased
> the number of pings sent in the test code from 3 to 10 so I see at least
> 7 consecutive pings succeed.
>
> 7. For pings to work at all, I had to add a route in my wireless router
> to network 192.168.2.0. The ping responses arriving at the router were
> being dropped since the only route to the LAN was to 192.168.1.0. Here's
> the new added route:
>
> ASUSWRT-Merlin RT-AC56U_3.0.0.4 Fri Jan 31 05:30:51 UTC 2014
> gene at RT-AC56U:/tmp/home/root# netstat -rn
> Kernel IP routing table (redacted)
> Destination Gateway Genmask Flags MSS Window irtt Iface
> 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
>
> 8. To run the ping01.exe test again the commands shown in step 4 and 6
> must be repeated.
>
> 9. I also ran the netshell01.exe test and it runs. However, as-is, the
> shell does not seem to be able to do network activities. E.g., ping from
> the rtems command line fails. However, if the ping01 code is combined
> with the netshell01 code such that a ping occurs before the shell
> actually starts, then pings from the rtems command line succeed. (I
> think the network init code is just missing from the netshell01 code.)
> So now selected hosts on my LAN can be pinged and internet hosts can be
> pinged, such as google's ip address. However, pinging by name does not
> work such as "ping google.com".
> I don't know how to setup DNS client functionality in rtems (which I
> think is possible).
I added to the ping01 code the following ...
#include <rtems/netcmds-config.h>
#define CONFIGURE_SHELL_COMMANDS_INIT
#define CONFIGURE_SHELL_COMMANDS_ALL
#define CONFIGURE_SHELL_USER_COMMANDS \
&rtems_shell_HOSTNAME_Command, \
&rtems_shell_PING_Command, \
&rtems_shell_ROUTE_Command, \
&rtems_shell_NETSTAT_Command, \
&rtems_shell_IFCONFIG_Command, \
&rtems_shell_TCPDUMP_Command
#include <rtems/shellconfig.h>
static void shell(void)
{
rtems_shell_env_t env;
memset(&env, 0, sizeof(env));
rtems_shell_main_loop( &env );
exit( 0 );
}
and just call 'shell' after the ping.
Note, currently tcpdump will not exit. I am not sure how to fix that.
Chris
>
> 10. Here's the routing table and ifconfig as seen from rtems shell:
> RTEMS Shell on (null). Use 'help' to list commands.
> [/] # netstat -r
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Netif Expire
> default 192.168.2.1 UGS 0 3 smc0
> 127.0.0.1 link#2 UH 0 4 lo0
> 192.168.2.0 link#1 U 0 0 smc0
> 192.168.2.1 52:54:00:12:34:56 UHS 0 0 smc0
> 192.168.2.2 link#1 UHS 0 0 lo0
>
> Internet6:
> Destination Gateway Flags Netif Expire
> ::1 link#2 UH lo0
> fe80::%smc0 link#1 U smc0
> fe80::5054:ff:fe12 link#1 UHS lo0
> fe80::%lo0 link#2 U lo0
> fe80::1%lo0 link#2 UHS lo0
> ff01::%smc0 fe80::5054:ff:fe12 U smc0
> ff01::%lo0 ::1 U lo0
> ff02::%smc0 fe80::5054:ff:fe12 U smc0
> ff02::%lo0 ::1 U lo0
>
> [/] # ifconfig
> smc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> ether 52:54:00:12:34:56
> inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255
> inet6 fe80::5054:ff:fe12:3456%smc0 prefixlen 64 scopeid 0x1
> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
> inet 127.0.0.1 netmask 0xffffff00
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
>
>
> -gene
>
>
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
More information about the users
mailing list