問題タブ [tftp]

「TFTP」サーバーと「U-boot」メニューを使用して、「rfsNV.gz」と「uImageNV」をARMボードにダウンロードしようとしています。私はderamCatcherによって開発されたボード、「tftp32.exe」を備えたWindows 7のtftpサーバー、ハイパーターミナル、クロスオーバーイーサネットケーブルおよびUSBシリアルケーブルを使用しています。ハイパーターミナルを使用してボードに接続すると、U-bootメニューが表示されます。サーバーのIPを192.168.0.123に設定し、ターゲットのボードのIPを192.168.0.1に設定しました。次に、「tftp32.exe」を起動してTFTPサーバーをセットアップし、ハイパーターミナルに書き込みます

しかし、ハイパーターミナルは次のように応答します

これは、イーサネット接続が正しく設定されていないことを意味しますか？私のローカルエリア接続は、この図のようなネットワークアクセスはありませんと言っています。ただし、ボード上のイーサネット接続LEDは、ケーブルが接続されていることを示します。私はEmbeddedLinuxにまったく慣れていないので、ボード上のファイルをダウンロードできない理由がわかりません。誰かが何が悪いのか理解できますか？

U-bootが起動するとコンソールが表示されます

'miiinfo'の出力は次のとおりです。

Ruby で TFTP サーバーを作成していますが、いくつかのことがわかりません。

まず、 RFC 全体を読み、パケットの TFTP 部分 (2 バイトのオペコードなど) を理解しましたが、TID がどこにあるのかわかりません。また、バイト レベルで Ruby を使用したことはありません。これを 2 バイト、次にそれを 1 バイト、それから何かという変数を作成する方法がわかりません。

Ruby で読み取り要求パケットを作成する方法の例を誰かが教えてくれたら、それは素晴らしいことです。クライアント側にいて、(ローカル TID 用に) ポート #20000 を選択し/Users/pachun/documents/hello.txt、最初の要求であるため、TID が 69 のサーバーで指定されたファイルを読みたいとします。Rubyでそのパケットをどのように構築しますか?

私はtftpクライアントをプログラミングしていますが、デフォルトのブロックサイズ（512）を使用している限り、問題なく動作します。しかし、それは学校の課題なので、1430と4300のブロックサイズでもテストする必要があります。

サーバーと最初に通信するときは、次の方法を使用します。

読みたいファイル名を設定します。そしてそれはうまく機能します。

しかし、ブロックサイズを定義できるように変更しました。

ここで、BLOCKSIZE = "blksize"（文字列）およびblockSize = 1430（int）; 問題は、それが機能しないことです：-/

誰かがブロックサイズを定義する方法を教えてもらえますか？

君たちありがとう ：-）

tftp を使用してファイルを取得するだけの VxWorks 用のアプリケーションを作成しようとしています。しかし、リンカーは tftpInit() 関数が何であるかを知りません。これらはエラーの例です:

vxcoreipライブラリ (tftpInit を実装する必要がある場所) をインクルードした後、次のリンカー エラーが発生しました。

tftpLib をリンクする方法を提案してください。どのライブラリが必要ですか?

PS プロジェクト タイプ - RTP (VxWorks 6.9)。開発環境 - Workbench 3.3

現在、C で tftp を作成しようとしていますが、送信したパケットを読み取るのが困難です。これが私が持っているものです:私が送信している構造体:

パケットを送信する機能（サーバー側）：

なんらかの理由で s = 0 で、正しいかどうかわかりません。

クライアント側:

および create_data 関数:

残念ながら機能しません。問題は create_data の strcpy にあるようですが、理由はわかりません。

ここにserverSocket作成のコードがあります（サーバー側）

TFTP の C 実装でタイムアウト メカニズムを実装しようとしていますが、一般的なヘルプを探しています。

私が疑問に思っているのは、タイムアウトの状況を管理する方法です。私が使用した早すぎるタイムアウトメカニズムは、シグナル/アラーム機能を使用していますが、どういうわけか、タイムアウトの処理方法に行き詰まっています。つまり、パケット (ack またはデータ) が失われ、タイムアウトが発生した場合、前のパケットを送り返す方法またはサーバーに確認します。

目標: クライアントからサーバーにファイルを転送する。

環境: Linux

問題：

1. サーバーで不完全にコピーされたファイルを開くと、改行の場所に "^M" 文字があるように見えます。

CでUDPの上にTFTPを実装しました。転送が行われるディレクトリの読み取り/書き込み許可を確認する方法を見つけようとしています。ファイルが存在する場合とファイルが存在しない場合は access() で F_OK を使ったのですが、ディレクトリのパーミッションを確認しようとすると W_OK と R_OK が面倒そうで stat() を見てみましたが、しかし、それを正しく実装できませんでした。fileではなくディレクトリの stat() または access() の代替案または正しい実装に関するアイデア。

JavaでTFTP (簡易 FTP)プロトコルを実装しています。クライアントとサーバーがあり、これまでのところ、クライアントはファイルを要求でき、サーバーはそのデータをクライアントに送信します。

ここで問題が発生しました。明らかなテスト上の理由から、マシンでクライアントとサーバーの両方を実行しています。ただし、ファイルを送信するときは、同じポートでリッスンする 2 つのソケットが必要です。

• クライアントは、受信したデータ パッケージをリッスンする必要があります
• サーバーはクライアントの確認応答をリッスンする必要があります

...そして、データと確認応答を送信するための 2 つのそれぞれのソケットも、ポートを共有します。

これは通常、同じポートで発生しますが、別のマシンで発生します。これを回避し、醜いハックなしで、クライアントとサーバーの両方を同じホスト上で平和的に動作させる方法はありますか? そして、醜いハックとは、次のようなことを意味します。

• ACK通信ポートの事前定義されたオフセット（データポートの+15など。これは私が現在使用しているものです。機能しますが、間違っているように感じ、エラーが発生しやすいです）

• ソケットの開閉を繰り返します (データを送信し、データの送信に使用されたソケットを閉じて、クライアントがそのポートを使用して ACK を送信できるようにするなど)。これは現時点でも機能しますが、ハック経由でも機能します。たとえば、送信に使用されるソケットを「再度開く」方法は次のとおりです。

  /li>

これは悪です。私のソケットは、元々、動的に割り当てられた一時的なポート番号を受け取ります。次に、その値を記憶し、それを使用してソケットを古いポートに「復元」します。ただし、そのポートがまだ使用可能であることは保証できません。通常はそうですが、保証はありません。この場合、私は過度に妄想的ですか？

• ハンドシェイクで新しい ACK 通信ポートを生成し、追加の手順で制御ポート (69) 経由でクライアントに送信します。

アップデート：

私は自分の問題を解決することができました。私の問題は、ソケットを再利用しようとしていないことでした。たとえば、ポート X のソケットから何かを送信しましたが、古いソケットを再利用する代わりに、そのポートに新しいソケットを割り当てて ACK をリッスンしようとしました。