I had the weirdest of a problem. Two computers communicating with each other over ping and TFTP works. When I boot one of them into U-boot (a bootloader that supports TFTP boot) it can’t ping not load tftp of the other machine complaining on ARP timeouts.

I swapped with a dumb switch - all works. Everything else (machines, cables) are the same. The managed switch is a Cisco switch and I have a serial console to it, but I’m not familiar with managing those switches - what feature is potentially blocking u-boot’s arp packets?

I’ve double checked with tcpdump - the other machine never seer u-boot’s arp packets, but does when the same board is booted into Linux. I’ve also checked Cisco’s monitor event-trace arp continuous and it didn’t print any packets but it did say link status went from up to down to back up when I rebooted.

Here’s the switch config - I removed exclamation marks because there isn’t much. The u-boot board is on port 1/0/6, the TFPT server is on 1/0/1

version 15.0
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
hostname switch
boot-start-marker
boot-end-marker
no aaa new-model
switch 1 provision ws-c2960s-48td-l
spanning-tree mode pvst
spanning-tree extend system-id
vlan internal allocation policy ascending
interface FastEthernet0
 no ip address
interface GigabitEthernet1/0/1
interface GigabitEthernet1/0/2
interface GigabitEthernet1/0/3
interface GigabitEthernet1/0/4
interface GigabitEthernet1/0/5
interface GigabitEthernet1/0/6
interface GigabitEthernet1/0/7
interface GigabitEthernet1/0/8
interface GigabitEthernet1/0/9
interface GigabitEthernet1/0/10
interface GigabitEthernet1/0/11
interface GigabitEthernet1/0/12
interface GigabitEthernet1/0/13
interface GigabitEthernet1/0/14
interface GigabitEthernet1/0/15
interface GigabitEthernet1/0/16
interface GigabitEthernet1/0/17
interface GigabitEthernet1/0/18
interface GigabitEthernet1/0/19
interface GigabitEthernet1/0/20
interface GigabitEthernet1/0/21
interface GigabitEthernet1/0/22
interface GigabitEthernet1/0/23
interface GigabitEthernet1/0/24
interface GigabitEthernet1/0/25
interface GigabitEthernet1/0/26
interface GigabitEthernet1/0/27
interface GigabitEthernet1/0/28
interface GigabitEthernet1/0/29
interface GigabitEthernet1/0/30
interface GigabitEthernet1/0/31
interface GigabitEthernet1/0/32
interface GigabitEthernet1/0/33
 switchport access vlan 103
 switchport mode access
interface GigabitEthernet1/0/34
 switchport access vlan 103
 switchport mode access
interface GigabitEthernet1/0/35
 switchport access vlan 103
 switchport mode access
interface GigabitEthernet1/0/36
 switchport access vlan 103
 switchport mode access
interface GigabitEthernet1/0/37
 switchport access vlan 102
 switchport mode access
interface GigabitEthernet1/0/38
 switchport access vlan 102
 switchport mode access
interface GigabitEthernet1/0/39
 switchport access vlan 102
 switchport mode access
interface GigabitEthernet1/0/40
 switchport access vlan 102
 switchport mode access
interface GigabitEthernet1/0/41
 switchport access vlan 101
 switchport mode access
interface GigabitEthernet1/0/42
 switchport access vlan 101
 switchport mode access
interface GigabitEthernet1/0/43
 switchport access vlan 101
 switchport mode access
interface GigabitEthernet1/0/44
 switchport access vlan 101
 switchport mode access
interface GigabitEthernet1/0/45
 switchport access vlan 100
 switchport mode access
interface GigabitEthernet1/0/46
 switchport access vlan 100
 switchport mode access
interface GigabitEthernet1/0/47
 switchport access vlan 100
 switchport mode access
interface GigabitEthernet1/0/48
 switchport access vlan 100
 switchport mode access
interface GigabitEthernet1/0/49
interface GigabitEthernet1/0/50
interface TenGigabitEthernet1/0/1
interface TenGigabitEthernet1/0/2
interface Vlan1
 no ip address
ip http server
ip http secure-server
line con 0
line vty 5 15
end
  •  Hexorg   ( @Hexorg@beehaw.org ) OP
    link
    fedilink
    English
    21 year ago

    I think lemmy is messing up. I replied a week ago.

    But we did figure it out. Fastport was disabled and uboot resets the electrical lines which caused the managed switch to rebuild its tree which was still happening by the time uboot started sending arp requests