You got the idea. The static IP on the gumstix is "reserved" by our
dhcp server such that it won't give out 192.168.0.87, .88, or .89. The
gumstix is at .88, and the linux developer server is at .89. There's
nothing else at 192.168.0.89 or .88, and pinging will verify this.
(ping from an outside computer while the uplink to the hub is severed.)
I'll continue to try to debug this problem. It has all the symptoms of
an IP conflict, but it doesn't appear to be an IP conflict. For the
moment I'll just blame our network, which has too many windows servers
to be reliable or deterministic. Furthermore, we just set up a new
subnet in the lab, and that seems to be a good enough solution for the
[mailto:gumstix-users-admin@...] On Behalf Of Craig
Sent: Friday, March 24, 2006 18:22
Subject: Re: [Gumstix-users] TFTP'ing in U-boot
Sorry, I'm not sure I understand, are you saying that this works:
gumstix ----- [hub] ----- TFTP server
but this doesn't work:
gumstix ----- [hub] ---- TFTP server
Is the static IP that the gumstix is using being given out to someone
else by any chance by the DHCP server? If so, then the TFTP server
might be directing its responses to that other host... Check the ARP
table on the tftp server.
On Mar 24, 2006, at 2:08 PM, J.P. Norair wrote:
> Hi again,
> The problem seems to stem from the DHCP network that the static system
> is running alongside. When I sever the uplink from the hub,=20
> everything works fine. But when the uplink is there, no luck. So it=20
> doesn't seem like it's going to be possible to maintain a single TFTP=20
> server that can be used by anyone in the office who needs to flash a=20
> I have done two tcpdumps. One while the uplink is severed and the=20
> other when it is attached. It doesn't seem like the gumstix can even=20
> get through to the server when attached, perhaps because it's impeded=20
> by other computers on the network. I'd like to include the dumpfiles,
> but I'm a bit leery to do so given the public nature of this list, and
> also because I don't think much more than what's already known can be=20
> pulled from them.
> The only solution I can think of is to make a new subnet, which of=20
> course isn't a really good solution since we'd have to re-wire the=20
> office. For now I will just sever the machine from the network. :(
> From: gumstix-users-admin@... [mailto:gumstix-=20
> users-admin@...] On Behalf Of Craig Hughes
> Sent: Friday, March 24, 2006 14:20
> To: gumstix-users@...
> Subject: Re: [Gumstix-users] TFTP'ing in U-boot
> On Mar 24, 2006, at 11:13 AM, J.P. Norair wrote:
>> Alright, I found out that the particular etherstix I was using was=20
>> faulty, so I switched to a different one. The LED is blinking, which
>> is good, and I can ping the server. But tftp still won't
>> work. It's asking me for a "gatewayip" environment variable. =20
>> When I set it to 192.168.0.1 (out actual gateway), it doesn't =20
>> work. This is annoying, since I'm dealing with a static network =20
>> and it shouldn't need a gateway address. What could be screwing this
> u-boot's networking code needs that gateway IP to be set; don't know=20
> why, since as you say, 99% of the time in a u-boot situation, you only
> need LAN access.
> What do you see on the LAN via tcpdump while the gumstix is trying to=20
> make its TFTP requests? Is your TFTP server serving the file=20
> "boot/uImage" which is what I think tftp is configured to ask for by=20
> default (can be over-ridden using the bootfile u-boot var).
>> From: gumstix-users-admin@... [mailto:gumstix-=20
>> users-admin@...] On Behalf Of Craig Hughes
>> Sent: Friday, March 24, 2006 14:00
>> To: gumstix-users@...
>> Subject: Re: [Gumstix-users] TFTP'ing in U-boot
>> On Mar 24, 2006, at 10:41 AM, J.P. Norair wrote:
>>> I've used tftp in u-boot with other embedded platforms fairly=20
>>> easily, but it's not working with the gumstix.
>>> I am using a static ip as follows:
>>> It seems like the problem is that the Etherstix is simply not=20
>>> working. The SMC-91111 seems to be recognized in u-boot, but it=20
>>> can't establish itself on the network. pinging yields nothing, from
>>> either side. Before anyone is tempted to assume: yes, I am plugged=20
>>> into a hub (using a straight cable).
>>> Any light anyone could shed on this problem would be much=20
>> What are the LEDs doing on the etherstix? One LED is programmed to=20
>> show 10/100 status (will be lit solidly when connected to a 10/100 or
>> 100 hub) and the other is programmed to blink on Tx/Rx, so it should=20
>> blink when you try to ping.
>> Also, can you run tcpdump on that network segment, and see if you're=20
>> seeing any packets from the gumstix (like the ICMP echo requests)?
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language that extends applications into web and mobile media. Attend the
live webcast and join the prime developer group breaking into this new
gumstix-users mailing list