Ping works

Somehow PXE code works, and in nearest future only C and TCP/IP related stuff expected, no assembler and PXE related problems. Last issue (code worked only in one available to me implementation of UNDI API ) was solved by modifying most used function pxe_core_call(). For some reasons, it returns incorrect value in ax register, however code works correctly. So, ax register now ignored till understanding why it’s contents is corrupted.

IP imlementation was made really fast, but checksums of IP and ICMP headers provided some nervous hours: ICMP reply (from PXE client) packets were noticed in tcpdump, but ping itself ignored this packets. Problem was in incorrect icmp checksum (first time tcpdump wasn’t saying me that there is problem with icmp checksum, but after some changes in checksum calculating it began warn. I guess, why it was not warning earlier, when checksum was calculated only for icmp header without transmitted data? May be it was a miracle and this bytes were filled by zeroes, so checksum was independent from transmitted data) .

The second problem that was expected – routing of packets to gateways. For this purpose, some routing related functions were implemented, and now it’s possible perform ping of death from PXE booted workstations :) Routing functions too primitive in my project, I need do something with them. By default, at start (pxe_ip_route_init()) two routes are added: default (it must be got from PXE cached packets, but there are only zeroes in place of gip member, so I set my home gateway 192.168.0.1 as default gateway. After implementation of some DHCP/BOOTP functions, it’ll be possible to get gateway automatically). pxenet0 (this route for hosts in local network, in fact – it’s not gateway. It’s named as interface in original pxeboot). IP related code uses first route, which network is equal to destination network of ip packet.

For testing purposes I’ve added to pxeboot command pxe, which allows to test project subsystems:

1. pxe arp ip.addr – sends ARP prequests for provided ip. Returns MAC address of desired ip, if host is upped.

2. pxe ping ip.addr – sends 5 pings with 32 bytes to provided ip.

3. pxe route – change route table. e.g. ‘pxe route add default 10.0.0.1′ will set 10.0.0.1 as default gateway. As you see there is no mask, it’s calculated from ip address class (no CIDR, so…). ‘pxe route print’ – shows current routing table.

4. pxe await – starts infinite cycle ofchecking received packets. May be used for client pinging purposes or serving client as server. There is no exit from this test module.

Well, in fact I need somebody to test modified pxeboot in PXE environment to be sure code is compatible with most existing PXE implementations (I’ve tested all available to me implementations and it worked, but who knows…). If somebody, may find a time and test – help will be greatly appreciated.

Here is tar.bz2 of modified version of pxeboot. It’s needed to up DHCP server with appropriate  settings  and TFTP service.

2 Responses to “Ping works”

  1. Helio says:

    what kind of testing do you need? so far I’ve tested it on my local lan on this machine:

    compaq evo: intel boot agent 4.1.08
    can:
    pxe arp both gateway and another node on local lan
    pxe ping gateway, another node on local lan, and another node on another network when gateway is set manually with pxe route
    pxe await and reply to pings from both local node and gateway, however first reply is sent twice for both. ex:
    $ ping 192.168.1.8
    PING 192.168.1.8 (192.168.1.8): 56 data bytes
    64 bytes from 192.168.1.8: icmp_seq=1 ttl=64 time=8.023 ms
    64 bytes from 192.168.1.8: icmp_seq=1 ttl=64 time=8.459 ms (DUP!)
    64 bytes from 192.168.1.8: icmp_seq=2 ttl=64 time=5.102 ms

    if there is anything specific you’d like to have tested, just fire me off an email. I’m anxiously awaiting this project and would like to do anything I can to help :)

  2. taleks says:

    Thanks for interest to project and testing.

    This result is enough for this test. Main goal for provided executable – test, if PXE API is called correctly in different implementations. It seems it works, and that’s good. DUP! issue seems result of not very good implementation of ICMP in my code (I’ll check, which is may be origin of this), but it’s unrelated to PXE.

    The next test will be related to DNS resolving after I finish doing of UDP and first version of sockets implementation. I tjhink, it’ ll be done at the end of this week.

    And the most interested test will be simple telnet client. Main purpose to test TCP implementation. It’s birthdate at the end of Juny/start of July.

    And after that – final result.

    I’ll drop you some lines after doing new tests.
    Once more, thanks for interest.

Leave a Reply