Greetings.....
I am working on a driver for generic serial-based radios (e.g, Coyote
Datacomm
DR-915 and Microhard MHX-910, etc..), that basically allows the radio to
be used
as a network interface, much in the spirit of STRIP. Kernel is 2.4.8
(mandrake 8.1).
Given that the radios pose an "unknown", I have gone to a NULL-modem cable
until this issue is resolved. Here's what *is* working across my interface:
1. ARP ... tcpdump shows both the request AND reply.
2. PING ... Getting approx 120ms round trip with the MHX-910s (23ms null
modem)
3. UDP ... Works perfectly with netcat in both directions.
Here's what *is not* working:
4. TCP .... tcpdump shows the SYN packet, but no SYN/ACK ever appears
5. ICMP 3/3 ... If I try a UDP session when there's no-body "listening"
on that
remote port, no "Port Unreachable" message is ever sent back to the
sending host.
The fact that items 1 though 3 work, indicate that 4 and 5 should work
as well,
but they don't. I have added a debug statement to my driver's
"hard_start_xmit"
routine to write to syslog when it's called. The kernel does not even
appear to
be calling the routine to respond to TCP SYN's or UDP packets headed for
an unreachable port.
The worst part of this is that TCP was working fine across this
interface about
a month ago. When I went to pick up where I left off from is when this
behavior
started to exhibit itself. Any ideas?
Please CC me personally on responses as I am not subscribed to the list.
TIA,
Larry
--
Lawrence A. Wimble 414 NE 3rd Street; Suite B
Chief Software Engineer Crystal River, FL 34429
Design On Demand, Inc. Phone 352-563-1225 x112
[email protected] Fax 352-563-2098
On Sun, 2002-10-06 at 00:10, Lawrence A. Wimble wrote:
> 1. ARP ... tcpdump shows both the request AND reply.
> 2. PING ... Getting approx 120ms round trip with the MHX-910s (23ms null
> modem)
> 3. UDP ... Works perfectly with netcat in both directions.
>
> Here's what *is not* working:
>
> 4. TCP .... tcpdump shows the SYN packet, but no SYN/ACK ever appears
> 5. ICMP 3/3 ... If I try a UDP session when there's no-body "listening"
> on that
> remote port, no "Port Unreachable" message is ever sent back to the
> sending host.
I'll take a quick guess. Your faked mac address has bit 0 of the first
byte set.
> Greetings.....
>
> I am working on a driver for generic serial-based radios (e.g, Coyote
> Datacomm
> DR-915 and Microhard MHX-910, etc..), that basically allows the radio to
> be used
> as a network interface, much in the spirit of STRIP. Kernel is 2.4.8
> (mandrake 8.1).
Are you willing share your code? I'd love to see what you have so far since I have a similar project. It is basically using a wireless link that supposed to look like a terminal. I'm hoping that all I'll need to do is make a simple driver to implement hard_start_xmit and let pppd do the rest. Probably like your radio, it has a 0-7 network id which I assume you are including in your MAC addr some how.
Regards,
Mazhar
On Sun, 2002-10-06 at 04:03, Mazhar Memon wrote:
> Are you willing share your code? I'd love to see what you have so far since I have a similar project. It is basically using a wireless link that supposed to look like a terminal. I'm hoping that all I'll need to do is make a simple driver to implement hard_start_xmit and let pppd do the rest. Probably like your radio, it has a 0-7 network id which I assume you are including in your MAC addr some how.
For network protocols you might also want to look at the daemon called
"scarabd" that Robin O'Leary and I did years ago for a low speed radio
modem that needed software to manage things like tx/rx, carrier handling
and so forth
Mazhar Memon wrote:
>
>Are you willing share your code? I'd love to see what you have so far since I have a similar project. It is basically using a wireless link that supposed to look like a terminal. I'm hoping that all I'll need to do is make a simple driver to implement hard_start_xmit and let pppd do the rest. Probably like your radio, it has a 0-7 network id which I assume you are including in your MAC addr some how.
>
>Regards,
>Mazhar
>
Yes, I am quite willing to share the code. In fact, I hope to have
everything wrapped up
by the end of this week, and after a little testing, will make it
available on our website for
download. I'll send an email off-list to anyone interested once it's ready.
Cheers!
Larry
--
Lawrence A. Wimble 414 NE 3rd Street; Suite B
Chief Software Engineer Crystal River, FL 34429
Design On Demand, Inc. Phone 352-563-1225 x112
[email protected] Fax 352-563-2098