Dual Boot FreeBSD - Linux: conflict with the Ethernet adapter

freezr

freezr

Dear All,

I'd like to say that I fully switched to FreeBSD however still have a big issue that prevents me to use FreeBSD daily.

I have issue with the "Atheros Killer E2400 Ethernet Adapter as formerly described here:
forums.freebsd.org

Solved - Atheros Killer E2400 Does Not Work!

Hi Folks, I am still uncertain if to be sad or upset, but this has been almost shocking for me and my future plans. During the WE, in my very few spare time available, I tested out the hardware compatibility of my laptop with the latest NomadBSD and GhostBSD, especially with the former which...
forums.freebsd.org forums.freebsd.org

During the installation time FreeBSD was unable to use the ethernet and the wifi card, however in a former test I was able to get the ethernet working with NomadBSD, hence I tried to troubleshoot the ethernet card with NomadBSD again to check eventually which special setup allowed NomadBSD to have the ethernet working.

Well after 4 or maybe 5 rebooting with NomadBSD the NIC suddenly started to work and I was able to finish to setup FreeBSD, and everything have beeing doing smooth (for a week) until yesterday that I had to boot into Linux again.

I was worried this would triggered again the same issue and as a matter of fact when later I rebooted again in FreeBSD the NIC was again in that state that cannot get a DHCP address. I left the laptop dischargingg in order to verify if this is able to "reset" the state of the NIC and make it working again with FreeBSD. I am pretty sure when it worked with NomadNSD I forgot the laptop unplugged.

Anyway this is very annoying, is this a common issue when the same hardware is shared between FreeBSD and Linux?

I don't have any clue on how to address this issue, but it is clear that Linux leaves the NIC in a state that makes it unusable for FreeBSD. I can't provide my rc.conf, right now, since I forgot the pendrive where I saved it, but it is pretty standard and it doesn't have anything special:

Code: 
ifconfig_alc0="DHCP"
ifconfig_alc0_ipv6="inet6 accept_rtadv"

Any hint and suggestion to understand what is happening is really appreciated!

Thanks,

D.
 
tgl said:
I'd like to say that I full y switch to FreeBSD [...]
Click to expand...
Nice!

tgl said:
Anyway this is very annoying, is this a common issue when the same hardware is shared between FreeBSD and Linux?
Click to expand...
In general: No.
A known problem is when dualbooting Windows regarding the system time.
Frankly there is also not a lot that can go on here. If there are side-effects between cross-boots I'd argue that it's most likely related to some firmware being written to the piece of hardware in question which for some reason doesn't happen on the next cross-boot. But this is extremely far fetched.
You might want to check dmesg for firmware related messages.

Based off of your first post here I'm also not sure what "not working" means. Does the device show up but it can't get a link? Or does the device not show up at all? Given that this is a PCIe NIC you might want to compare outputs of pciconf to check whether a driver is attached when it's "not working".

Another far fetched thing: If "not working" means that the device does not show up but it does after a couple of reboots maybe there is something preventing the auto-detection from loading the corresponding alc(4) driver. Check the output of kldstat to see whether the driver is actually loaded when the device is "not working".

Even more far-fetching: Maybe there's something regarding MSI not working properly. If you're desperate you might want to try setting hw.alc.msi.disable to 1 and likewise for hw.alc.msix_disable.
There have been some MSI related fixes a few days/weeks ago but I think those were all related to bhyve.

Furthermore, can you provide information regarding the functionality under Linux? Do you get similar flakey behavior there or is it rock-solid working 10-out-of-10 times there?

But please: Provide more information regarding the "not working" situation. What are the exact symptoms?
 
I never heard of this specific problem, so I'd confirm NO, that's NOT a common issue when using the same hardware with different OS.

What I've seen in the past is hardware going to some broken state where only a full power-down helps, unfortunately such things happen. So it's not too surprising (although VERY unlikely to happen) different drivers might do something to a specific piece of hardware that breaks the other driver.

Solution: Always boot the same system ?

But, seriously, depending on what you use this Linux system for, maybe virtualization would be an alternative?
 
Hi, Thanks to all.

The Atheros Killer e2400 is a ethernet card, the wifi is working although I haven't setup it yet, and I would avoid to use it since the wifi space is already congested by tablets, phones and SmartTVs.

I left the Linux partition because there are still stuff that work on Linux only, for instance I have zoom interview this week and I don't want use any workaround to make Zoom working barely acceptable with such delicate stuff.

Maybe might exist some command in the Linux driver that clears up the state of the card and I could run it when I reboot/shutdown Linux...
 
I've edited my post above a minute after posting it so you might have missed the remainder of the content - especially the questions I've added.
 
I just found it on the Arch wiki and I have internet from the cable:

Troubleshooting​


Swapping computers on the cable modem​

Some cable ISPs (Vidéotron for example) have the cable modem configured to recognize only one client PC, by the MAC address of its network interface. Once the cable modem has learned the MAC address of the first PC or equipment that talks to it, it will not respond to another MAC address in any way. Thus if you swap one PC for another (or for a router), the new PC (or router) will not work with the cable modem, because the new PC (or router) has a MAC address different from the old one. To reset the cable modem so that it will recognise the new PC, you must power the cable modem off and on again. Once the cable modem has rebooted and gone fully online again (indicator lights settled down), reboot the newly connected PC so that it makes a DHCP request, or manually make it request a new DHCP lease.

If this method does not work, you will need to clone the MAC address of the original machine. See also MAC address spoofing.
Click to expand...

Can it be the issue related with the Mac Address?

Sometimes we reset the router because the Smart TVs have issues to get a stable signal, maybe this might be another reason why the network used to work...
 
It would really help if you could answer at least some of the questions from my first post. As far as I am concerned we still don't know what "doesn't work" or "unable to use the ethernet card" means.

Whether or not you are able to talk to your ISP shouldn't matter based on "unable to use the ethernet card".
 
Sorry now I got your changes.

jbodenmann said:
You might want to check dmesg for firmware related messages.

Based off of your first post here I'm also not sure what "not working" means. Does the device show up but it can't get a link? Or does the device not show up at all? Given that this is a PCIe NIC you might want to compare outputs of pciconf to check whether a driver is attached when it's "not working".
Click to expand...

It can't get a DHCP address and I get:

Code: 
DHCP lease acquisition failed

jbodenmann said:
Another far fetched thing: If "not working" means that the device does not show up but it does after a couple of reboots maybe there is something preventing the auto-detection from loading the corresponding alc(4) driver. Check the output of kldstat to see whether the driver is actually loaded when the device is "not working".
Click to expand...

The kernel module is properly loaded, sorry for the generalization. The issue is in getting a DHCP address in order to work, however with a static IP doesn't work either.

jbodenmann said:
Even more far-fetching: Maybe there's something regarding MSI not working properly. If you're desperate you might want to try setting hw.alc.msi.disable to 1 and likewise for hw.alc.msix_disable.
There have been some MSI related fixes a few days/weeks ago but I think those were all related to bhyve.

Furthermore, can you provide information regarding the functionality under Linux? Do you get similar flakey behavior there or is it rock-solid working 10-out-of-10 times there?
Click to expand...

I already tried all those changes none of them worked, I started to get the IP address I guess for two reason: 1) laptop battery went down; 2) I restarted the router.

With Linux worked out of the box, this is an ten years old System76 laptop, but still pretty powerful; designed to work with Debian based distros out-of-the-box.

jbodenmann said:
But please: Provide more information regarding the "not working" situation. What are the exact symptoms?
Click to expand...

The DHCP lease doesn't work and therefore I can't get any internet access.

This is the state of my cards (from NomadBSD) when I can't get the DHCP address:

nb1.jpg


I'll post more info later in the evening.
 
so the device itself is always showing up properly when you boot into FreeBSD? As in: You always see alc0 showing up under ifconfig?

tgl said:
[...], however with a static IP doesn't work either.
Click to expand...
Can you show the output of ifconfig alc0 after setting a static IP & netmask?

This is another long shot but it might be fun to check whether ARP itself is working. I'm suggesting this because unless I'm missing something your NIC is active and auto-selected the correct media.
But keep in mind that this is just another long shot. It doesn't make a lot of sense given that if ARP is working the networking stack should be able to send IP packages.

I assume you already tried the "have you turned it off and on again?" approach: ifconfig alc0 down ifconfig alc0 up.
Also what Zirias said earlier: What about proper cold boots? What behavior are you observing then?
 
Hello,

I have this wire Ethernet card

Ethernet controller [0200]: Qualcomm Atheros AR8132 Fast Ethernet [1969:1062] (rev c0)

FreeBSD detect it as alc0. I use it with a static IP address to connect it directly to an other device. I use only wireless in dhcp. So far it have always work.

If you cannot get an ip configuration from the dhcp server, be sure that the dhcp server is not in cause. You can do like me for a test, connect an RJ45 câble between alc0 and an other computer and configure them on the same network and try to login on any side through this wire link. The problem can be the RJ45 cable as well than the connectors on both sides so, make a manual test on FreeBSD to be sure it work without a dhcp server even if you know that it work on Linux.

Have you reset the dhcp server and poweroff FreeBSD before to try to connect? Be sure too that you use the same MAC address for this alc0 card in FreeBSD than in Linux. Servers need to be reset to accept a new MAC address. In my case I rename alc0 to eth0 in rc.conf so, you can try to rename it too:

ifconfig_alc0_name="eth0"
ifconfig_eth0="inet aaa.bbb.ccc.ddd broadcast aaa.bbb.ccc.ddd netmask aaa.bbb.ccc.ddd"

or

ifconfig_alc0_name="eth0"
ifconfig_eth0="SYNCDHCP"

I use dhcpcd as the dhcp client on FreeBSD and Linux more than dhclient. Note that wpa_supplicant can configure wire links as well than wireless ones. So, have only one dhcp client ask the dhcp server for an ip configuration.
 
Unfortunately I can do all those tests in the evening but I will, however I found also this about DHCLIENT[1]:

Code: 
EXPIRE : The DHCP client has failed to renew its lease or acquire a new one, and the lease has expired.  The IP address must be relinquished, and all related parameters should be deleted, as in RENEW and REBIND.

FAIL: The DHCP client has been unable to contact any DHCP servers, and any leases that have been tested have not proved to be valid.  The parameters from the last lease tested should be deconfigured.  This can be handled in the same way as EXPIRE

Maybe you can force the NIC to "reset" internally and get a proper address...
Not sure I am just "brainstorming as noob"...

[1]https://www.unix.com/man-page/FreeBSD/8/dhclient-script/[/code]
 
I don't think that you'll get anything out of messing with DHCP as you stated earlier that networking is not working either if you assign a static IP. And before all of that: If ARP is not working there's no point in trying to mess with the IP layer at all. Check whether ARP is doing the its thing first.
 
jbodenmann said:
so the device itself is always showing up properly when you boot into FreeBSD? As in: You always see alc0 showing up under ifconfig?

I assume you already tried the "have you turned it off and on again?" approach: ifconfig alc0 down ifconfig alc0 up.
Also what Zirias said earlier: What about proper cold boots? What behavior are you observing then?
Click to expand...

During the boot time the interface il properly loaded, the order is Up, Down, Up, then is configured and start the DHCP lease process. It hangs for a while since can't get the DHCP offer.

Doing "down/up" and then "dhclient alc0" doesn't work, even using the "/etc/nestart" helps to fix it. Simply it can't configure the DHCP.

I think I already tried this:

Code: 
ifconfig_alc0_name="eth0"
ifconfig_eth0="SYNCDHCP"

But it didn't work out, but I can try again.

What do you mean with cold boots?

Thanks for all your help!

TGL
 
when it does not work can you see any traffic thats not sent by it with tcpdump ?
also try to force media to 100basetx
 
Reboot can leave the firmware of a card in the state of the precedent operating system and conflict with the one you are using. Cold boot preceeded by poweroff prevent this. Even remove the pile, the battery and the power cable can help to have the desire cold boot with the router reset. If there is a setup who always work in most systems it is to configure a wire network card.

Because it work on other systems it must be a configuration problem on the router and/or FreeBSD. I have upgrade my RJ45 cables from Cat 5 to Cat 6 recently.
 
tgl You keep stating "doesn't work" but we have yet to learn what that actually means. Please provide more verbose information. If the program in question (i.e. dhclient) doesn't yield any useful messages you might want to look into the various log files.

tgl said:
What do you mean with cold boots?
Click to expand...
Turn the computer off completely (removing all power). This is merely to ensure that there is no "foreign" firmware loaded onto the device (i.e. from the Linux driver).
 
Hi guys,

I apology for the improper use of "this doesn't work", this my limitation about how much I understand the networking...

Actually the card works and it is recognized however hangs to get an IP through the DHCP service.

?
 
If the card is up and running (and ethernet cable connected), do you get any output from running this? --> tcpdump -i alc0?
 
jbodenmann

the cold boot worked, but it is not really ideal.

Code: 
tcpdump -i alc0
19:41:25.441866 IP a23-54-149-128.deploy.static.akamaitechnologies.com.https > 10.0.0.113.47100: Flags [.], seq 247387:248835, ack 9182, win 441, options [nop,nop,TS val 3735202666 ecr 3438550869], length 1448
19:41:25.441876 IP a23-54-149-128.deploy.static.akamaitechnologies.com.https > 10.0.0.113.47100: Flags [P.], seq 248835:249127, ack 9182, win 441, options [nop,nop,TS val 3735202666 ecr 3438550869], length 292
19:41:25.441881 IP 10.0.0.113.47100 > a23-54-149-128.deploy.static.akamaitechnologies.com.https: Flags [.], ack 249127, win 7769, options [nop,nop,TS val 3438550914 ecr 3735202666], length 0
 
Next time it doesn't work, check the output of tcpdump -i alc0 again and post it here.
Basically what tcpdump shows you is traffic on that interface. If you get no output at all there it means that something is wrong / not-working on a level where messing with DHCP is not gonna help you at all to track down the problem.
 
Does FreeBSD actually receive DHCP replies?

From alc(4):
All LOMs supported by the alc driver have TCP/UDP/IP checksum offload for
transmit, TCP segmentation offload (TSO), hardware VLAN tag
stripping/insertion features, Wake On Lan (WOL) and an interrupt
moderation mechanism as well as a 64-bit multicast hash filter.
Click to expand...

I've once seen one of those "pseudo-intelligent" gaming NICs filtering out a lot of (sometimes important!) traffic (even ARP!) so the OS/services never received what they were waiting for. If the vendor offers some kind of firmware without any "acceleration"-snakeoil enabled, use that!

Wild guess: The firmware doesn't get reset on 'warm'-reboots and filters DHCP packets (or ARP?) and may prevent the dhclient from acquiring a lease. Run tcpdump and filter for ports 67/68 to see what FreeBSD is sending out and receiving in reply. Depending on what you use as a DHCP server you might also run a quick tcpdump on that to see if it receives and answers the requests.

And just to cancel out those edge cases:
Any chance you are using the ISPs router in pass-through-mode to acquire a globally routable IP? Or have one of those rip-off plans where you are only allowed to use a specific number of end devices?
In both cases the DHCP is handled by your ISP and might block/ignore valid DHCP requests due to arbitrary limitations. (I've seen that with pass-through on Kabel Deutschland / Vodafone Cable lines here in Germany. Can be fixed by nagging them enough, at least on business plans)
 
Hi guys thank you very much for helping me with this...

With the laptop several hours turned off, FreeBSD started properly including the DHCP.

This is what I got with tcpdumb -vi alc0 when it didn't get the DHCP address:

Code: 
08:14:29.284246 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA), bad cksum 0 (->3fa)!)
    0.0.0.0 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.251 to_ex, 0 source(s)]
08:14:29.695928 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::82fa:5bff:fe28:3669 > ff02::1:ff7b:246a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::3a5f:66ff:fe7b:246a
      source link-address option (1), length 8 (1): 80:fa:5b:28:36:69
08:14:30.695264 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::82fa:5bff:fe28:3669 > ff02::1:ff7b:246a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::3a5f:66ff:fe7b:246a
      source link-address option (1), length 8 (1): 80:fa:5b:28:36:69
08:14:31.695271 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::82fa:5bff:fe28:3669 > ff02::1:ff7b:246a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::3a5f:66ff:fe7b:246a
      source link-address option (1), length 8 (1): 80:fa:5b:28:36:69
08:14:33.884502 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::82fa:5bff:fe28:3669 > ff02::1:ff7b:246a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::3a5f:66ff:fe7b:246a
      source link-address option (1), length 8 (1): 80:fa:5b:28:36:69
[...]

It looks like Linux leaves the card in a state that is unusable for FreeBSD but not the contrary. But this is really doesn't surprise me anymore, for the Linux folks computers start with Windows and end with Linux...
 
There is no DHCP discovery/request in those logs. Of course you should (re)start dhclient on that interface after starting the tcpdump if you want to monitor what is going on DHCP-wise... also what is the output of dhclient(8) if started manually on alc0?
 
At least I got the wifi working...

Anyway these are the commands I run when tcpdump was listening:
Code: 
$ doas service netif restart
Stopping dhclient.
Waiting for PIDS: 7529.
Stopping wpa_supplicant.
Waiting for PIDS: 91895.
Stopping Network: lo0 alc0 wlan0.
lo0: flags=8048<LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
alc0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 80:fa:5b:28:36:69
    media: Ethernet autoselect
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    groups: wlan
    ssid "" channel 1 (2412 MHz 11b)
    regdomain FCC country US authmode OPEN privacy OFF txpower 30
    bmiss 10 scanvalid 60 wme bintval 0
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Destroyed wlan(4) interfaces: wlan0.
Created wlan(4) interfaces: wlan0.
Starting wpa_supplicant.
Starting Network: lo0 alc0 wlan0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
alc0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 80:fa:5b:28:36:69
    inet6 fe80::82fa:5bff:fe28:3669%alc0 prefixlen 64 scopeid 0x1
    media: Ethernet autoselect (none)
    status: no carrier
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    groups: wlan
    ssid "" channel 1 (2412 MHz 11b)
    regdomain FCC country US authmode OPEN privacy OFF txpower 30
    bmiss 10 scanvalid 60 wme bintval 0
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
$ doas dhclient alc0
dhclient already running, pid: 62608.
exiting.
$ doas ifconfig alc0 down
doas ifconfig alc0 up
$ doas dhclient alc0
DHCPREQUEST on alc0 to 255.255.255.255 port 67
DHCPREQUEST on alc0 to 255.255.255.255 port 67
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 7
No DHCPOFFERS received.
Trying recorded lease 10.0.0.113
No working leases in persistent database - sleeping.

And this was the tcpdump output:

Code: 
$ doas tcpdump -i alc0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on alc0, link-type EN10MB (Ethernet), capture size 262144 bytes
05:57:05.924627 IP6 :: > ff02::1:ff28:3669: ICMP6, neighbor solicitation, who has fe80::82fa:5bff:fe28:3669, length 32
05:57:05.924631 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
05:57:05.924633 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88
05:57:05.924634 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:11.977078 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:21.985877 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:25.014066 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:28.060274 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:31.073958 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:36.078292 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:44.178095 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:52.209334 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:03.277107 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:30.562620 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:30.562624 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
05:58:30.562625 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
05:58:30.562626 IP6 :: > ff02::1:ff28:3669: ICMP6, neighbor solicitation, who has fe80::82fa:5bff:fe28:3669, length 32
05:58:30.562627 IP6 fe80::82fa:5bff:fe28:3669 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
05:58:30.562628 IP6 fe80::82fa:5bff:fe28:3669 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
05:58:30.562629 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:50.563862 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:58.564939 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:07.633037 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:19.634518 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:35.705091 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:44.728354 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:51.787359 ARP, Request who-has 10.0.0.113 tell 10.0.0.113, length 28
05:59:52.834260 ARP, Request who-has 10.0.0.1 tell 10.0.0.113, length 28
^C
28 packets captured
28 packets received by filter
0 packets dropped by kernel
 
You must log in or register to reply here.
Back
Top