networking not sending/receiving it seems
126 views
Skip to first unread message
joeb...@gmail.com
Jun 30, 2015, 9:41:09 AM6/30/15
to bareme...@googlegroups.com
I'm attempting to confirm that networking is working successfully under either qemu or virtualbox. I've confirmed that both work with a linux guest, but not BareMetal.
The network device is detected it seems
[cpu: 4 x 2917 MHz] [mem: 256 MiB] [hdd: 128 MiB] [net: 5254DEADBEEF]
But no traffic shows received under ethtool.app or http.app
Under qemu, I've tried both:
Default:
qemu-system-x86_64 -vga std -smp 8 -m 256 -drive id=disk,file=bmfs.image,if=none -device ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0 -name "BareMetal OS" -net nic,model=i82551,vlan=0 -curses
qemu-system-x86_64 -smp 4 -m 256 -device ahci,id=ahci -drive id=disk,file=bmfs.image,if=none -device ide-drive,drive=disk,bus=ahci.0 -name "BareMetal OS" -netdev tap,id=net0 -device e1000,netdev=net0,mac=52:54:de:ad:be:ef,id=nd0 -curses
Attemping http.app:
[cpu: 4 x 2917 MHz] [mem: 256 MiB] [hdd: 128 MiB] [net: 5254DEADBEEF]
BareMetal is ready
> httpd.app 192.168.0.3 255.0.0.0 192.168.0.1
reip started v1.00
4 args: 192.168.0.3 , 255.0.0.0 , 192.168.0.1
reif drv init is OK
MAC: 08:00:27:51:28:16
Interface is UP
Then I do a wget http://192.168.0.3 from the host and nothing is displayed.
I also have tried arp-scan, which finds the linux guest, but BareMetal
vagrant@precise64:~/dev/BareMetal/bin$ sudo arp-scan -T 52:54:de:ad:be:ef 192.168.0.0/24 --interface=tap0
Starting arp-scan 1.8.1 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.3 52:54:de:ad:be:ef (Unknown)
Looking for BareMetal:
Starting arp-scan 1.8.1 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
0 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.8.1: 256 hosts scanned in 1.290 seconds (198.45 hosts/sec). 0 responded
I do not have an X11 environment to try packeth
Under virtualbox, I'm using bridged networking and have experienced the same result.
Can you provide some instructions on how to validate networking under qemu or virtualbox?
Thanks
Joe
joeb...@gmail.com
Jun 30, 2015, 4:18:10 PM6/30/15
to bareme...@googlegroups.com, joeb...@gmail.com
Update: ethtool.app can send packets and I'm able to pick them up via tcpdump on tap0, but I'm still not able to see any packets received by BareMetal. I have downloaded the packeth cli and tried that as well
Does this look correct?
sudo ./packETHcli -i br0 -m 2 -d 10 -f foo
Ian Seyler
Jul 1, 2015, 10:39:15 AM7/1/15
to bareme...@googlegroups.com, joeb...@gmail.com, joeb...@gmail.com
Hi Joe,
I can't comment on QEMU networking but VirtualBox does work.
I ran a quick test with ethtool.app to verify. There is a bug in httpd.app where the MAC is hardcoded in the app.
My Linux VM has two network interfaces. One is bridged and the other is set to "Internal Network". The BareMetal VM is set to use the same internal network.
-Ian
Joe Bogner
Jul 1, 2015, 2:58:00 PM7/1/15
to Ian Seyler, bareme...@googlegroups.com
Thanks for the reply. I was able to get it working under virtualbox as well.
It seems qemu is also functional, but inconsistent. I enabled debugging in e1000.c and have been able to get it to work once out of every 3-8 times I launch it.
These logs are captured on booting (no app running)
Here is a capture of stderr when it's NOT working
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: MMIO unknown write addr=0x00000178,val=0x80008060
e1000: RCTL: 1, mac_reg[RCTL] = 0x4008006
e1000: tx disabled
e1000: set_ics 2, ICR 0, IMR 0
e1000: MMIO unknown write addr=0x00000410,val=0x0060200a
e1000: MMIO unknown write addr=0x00002c00,val=0x00000000
e1000: set_ics 0, ICR 2, IMR 1ffff
e1000: receiving packet 90e1000: set_ics 90, ICR 2, IMR 1ffff
e1000: ICR read: 92
I don't completely understand these commands, but it looks like it's attempting to read more than what's available
This is another trace that looks different though (still not working)
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: MMIO unknown write addr=0x00000178,val=0x80008060
e1000: RCTL: 1, mac_reg[RCTL] = 0x4008006
e1000: tx disabled
e1000: set_ics 2, ICR 0, IMR 0
e1000: MMIO unknown write addr=0x00000410,val=0x0060200a
e1000: MMIO unknown write addr=0x00002c00,val=0x00000000
e1000: set_ics 0, ICR 2, IMR 1ffff
e1000: ICR read: 2
e1000: receiving packet 90e1000: set_ics 90, ICR 0, IMR 1ffff
[stuck here]
When it IS working
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: MMIO unknown write addr=0x00000178,val=0x80008060
e1000: RCTL: 1, mac_reg[RCTL] = 0x4008006
e1000: tx disabled
e1000: set_ics 2, ICR 0, IMR 0
e1000: MMIO unknown write addr=0x00000410,val=0x0060200a
e1000: MMIO unknown write addr=0x00002c00,val=0x00000000
e1000: set_ics 0, ICR 2, IMR 1ffff
e1000: ICR read: 2
e1000: receiving packet 90e1000: set_ics 90, ICR 0, IMR 1ffff
e1000: ICR read: 90
e1000: receiving packet 90e1000: set_ics 90, ICR 0, IMR 1ffff
e1000: ICR read: 90
e1000: receiving packet 78e1000: set_ics 90, ICR 0, IMR 1ffff
e1000: ICR read: 90
e1000: receiving packet 90e1000: set_ics 90, ICR 0, IMR 1ffff
e1000: ICR read: 90
e1000: receiving packet 70e1000: set_ics 90, ICR 0, IMR 1ffff
e1000: ICR read: 90
e1000: receiving packet 90e1000: set_ics 90, ICR 0, IMR 1ffff
e1000: ICR read: 90
e1000: receiving packet 70e1000: set_ics 90, ICR 0, IMR 1ffff
e1000: ICR read: 90
e1000: receiving packet 70e1000: set_ics 90, ICR 0, IMR 1ffff
e1000: ICR read: 90
Ian Seyler
Jul 1, 2015, 5:03:57 PM7/1/15
to bareme...@googlegroups.com, joeb...@gmail.com, joeb...@gmail.com
Odd that it is inconsistent. I would expect it to either work or not.
Those error messages about the MMIO addresses are odd since they are part of the network adapter.
I8254X_REG_TXCW equ 0x0178 ; Transmit Configuration Word
I8254X_REG_TIPG equ 0x0410 ; Transmit Inter Packet Gap
I8254X_REG_RSRPD equ 0x2C00 ; RX Small Packet Detect Interrupt
Perhaps the QEMU e1000 implementation doesn't use those?
I'll assume the ICR messages are in relation to I8254X_REG_ICR (Interrupt Cause Read).
ICR = 2 (00000010b) means that the transmit queue is empty.
ICR = 90 (01011010b) means the following:
Bit 1: Transmit Queue Empty
Bit 3: Receive Sequence Error
Bit 4: Receive Descriptor Minimum Threshold Reached
Bit 6: Receiver Overrun
That sounds like the driver is causing an issue.
-Ian
Reply all
Reply to author
Forward
0 new messages