HECnet

hecnet@lists.dfupdate.se

15556 discussions

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/08/2012 03:13 AM, Johnny Billquist wrote: But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out. If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device. In the case of Linux DECnet, it actually changes the "main" MAC address of the interface, it doesn't add another one. Right. And in that case, you don't need promiscuous mode. We could go on about details, corner cases, other systems, potential network problems, and so on... But I think we both know what we're talking about, and I doubt we need to drag this any further. Contact me directly if you want us to continue. :-) I think what we need to do is convince Chrissie to continue working on her DECnet implementation. =) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 09:07, Dave McGuire wrote: On 06/08/2012 02:00 AM, Johnny Billquist wrote: But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out. If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device. In the case of Linux DECnet, it actually changes the "main" MAC address of the interface, it doesn't add another one. Right. And in that case, you don't need promiscuous mode. We could go on about details, corner cases, other systems, potential network problems, and so on... But I think we both know what we're talking about, and I doubt we need to drag this any further. Contact me directly if you want us to continue. :-) Johnny

12 years, 11 months

Introducing myself... and my little network

by mcguire＠neurotica.com

On 06/08/2012 03:09 AM, Johnny Billquist wrote: The most common problem with the TK50 is that the tape pickup gets off the holding arm. Easy to fix if you are comfortable with a screw driver. I've had one or two TK50 go bad in other ways, but in my experience it's pretty uncommon for them to really break. It's almost always that pickup. Let me know if you need help understanding that. The "tongue"? Been fixing that problem for years. At one point I ordered a box of (I think) ten of those while DEC was still selling them as repair parts, but they're all gone now. Eventually the little grabber end breaks off due to plastic fatigue. The drives whose tongues are intact simply refuse to read and cause device timeouts. I have at least 7 or 8 in that condition, with no obvious mechanical flaws. I haven't dug into them very deeply. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

Introducing myself... and my little network

by bqt＠softjar.se

On 2012-06-08 09:04, Dave McGuire wrote: On 06/08/2012 07:48 AM, Peter Lothberg wrote: I will set it aside if I find it, and make sure to image it. Image all your TK50's with distribution stuff on drop Al K a copy. I definitely will, if I can keep a drive working long enough. I have probably fifteen TK50 drives here...most of which are dead. Although it was the forerunner of the rather marvelous DLT, the first generation really was a crappy design. :-( The most common problem with the TK50 is that the tape pickup gets off the holding arm. Easy to fix if you are comfortable with a screw driver. I've had one or two TK50 go bad in other ways, but in my experience it's pretty uncommon for them to really break. It's almost always that pickup. Let me know if you need help understanding that. Johnny

12 years, 11 months

Reaching SOL::, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/08/2012 07:14 AM, Peter Lothberg wrote: Can you talk to sol:: I can't seem to get to it from my Linux desktop machine, no, but I can SET HOST to it from my Alpha running VMS. (which I'm reaching from the aforementioned Linux machine!) It seems that off-net DECnet routing isn't happening from the Linux machine..? What's up with this, does anyone know? Is it connetivity (routing), or the fact that the linux implementation only speaks VMSnet? That I do not know. Does the linux box talk to stupi:: No, it times out. :-( -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/08/2012 02:00 AM, Johnny Billquist wrote: But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out. If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device. In the case of Linux DECnet, it actually changes the "main" MAC address of the interface, it doesn't add another one. And to make a correction to your text, when not in promiscuous mode, your ethernet controller will filter out packets that do not have your MAC address, and packets that don't have the multicast bit set (possibly you can also get it to filter more specific on multicast ethernet packets, but multicast is a separate story from unicast packets on ethernet controllers anyway). Oh yes, I'm sorry for my omission. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

Introducing myself... and my little network

by mcguire＠neurotica.com

On 06/08/2012 07:48 AM, Peter Lothberg wrote: I will set it aside if I find it, and make sure to image it. Image all your TK50's with distribution stuff on drop Al K a copy. I definitely will, if I can keep a drive working long enough. I have probably fifteen TK50 drives here...most of which are dead. Although it was the forerunner of the rather marvelous DLT, the first generation really was a crappy design. :-( -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

New bridge.c feedback

by bqt＠softjar.se

On 2012-06-08 08:39, Boyanich, Alastair wrote: Hi Johnny, Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite C compilers as they're quite anal and chatty warning wise. Yeah. gcc is stupid. They added -Wall several years ago, but apparently people got upset by it's anal reporting, so they dumbed it down. So -Wall does not turn on all warnings anymore. And I just don't have the enery right now to figure out what more switches I should throw on it to actually make it complain about everything... Sounds good. New code arrives I'll check it out. :) The new code is already accessible. Same place as always... Johnny Al. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Friday, 8 June 2012 4:35 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] New bridge.c feedback On 2012-06-08 01:30, Boyanich, Alastair wrote: Hi Johnny, Yes. It seems to want<strings.h> 6.5.24 and above (or 6.5.29f in my case) was aiming at SUSv3 compliance away from base XPG4 so things were moved to strings.h (http://pubs.opengroup.org/onlinepubs/009695399/functions/index.html) .. it's also in the 3c index man page, you were right. Excellent. Included strings.h as well now. Not a problem on the systems here. We'll see if it hits problems for anyone else. So, compiles on IRIX 6.5.29 if the header is included. Worth gating it in via #ifdef ? I'm also a fan of enum types. Binary emitted is ~298kb. Also, your welcome to an account on the system if you wish to poke/play around, it's accessible over ssh and the general internet (it's my daily shell/hacking on code box). -Wall makes the MIPSpro runtime *extremely* chatty. It's quite anal. See below. Even better. Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 158 The parameter "data" was never referenced. int lookup(struct sockaddr_in *sa, char *data) ^ Yeah. I noticed that one too. I don't remember why data was in there in the first place, since I'm not using it. Might as well drop it. cc-1506 cc: REMARK File = bridge.c, Line = 460 There is an implicit conversion from "unsigned long" to "long"; rounding, sign extension, or loss of accuracy may result. delta = timedelta(bridge[index].lasttime); ^ Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "r" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ That one is because dump_nomatch is a function I wrote for debugging help. The body of the function is normally empty, since it's inside a #if Need to think a little about how/if I'll get rid of that warning... cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "d" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ Same story... cc-1185 cc: WARNING File = bridge.c, Line = 579 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ That one should already have been fixed... cc-1171 cc: WARNING File = bridge.c, Line = 685 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Also alredy fixed... cc-1498 cc: REMARK File = bridge.c, Line = 709 There is no prototype for the call to read_conf. read_conf(); ^ Think I fixed that. However, this is a little messy, since I'm doing things slightly unconventional. read_conf() is called both in the normal main program, and is also the signal handling function for SIGHUP. However, signal functions actually takes one argument. By setting up a prototype, I had to include one argument here, which is unused (I totally don't care about it), so now you might get a warning about an unused parameter. But prototypes are a good thing, so the unused parameter warning is better to have. cc-1209 cc: REMARK File = bridge.c, Line = 715 The controlling expression is constant. while(1) { ^ Yes. That's how you get an infinite loop. :-) Thanks for the feedback. See what happens with the fixed code... Johnny

12 years, 11 months

New bridge.c feedback

by Alastair.Boyanich＠au.fujitsu.com

Hi Johnny, Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite C compilers as they're quite anal and chatty warning wise. Sounds good. New code arrives I'll check it out. :) Al. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Friday, 8 June 2012 4:35 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] New bridge.c feedback On 2012-06-08 01:30, Boyanich, Alastair wrote: Hi Johnny, Yes. It seems to want<strings.h> 6.5.24 and above (or 6.5.29f in my case) was aiming at SUSv3 compliance away from base XPG4 so things were moved to strings.h (http://pubs.opengroup.org/onlinepubs/009695399/functions/index.html) .. it's also in the 3c index man page, you were right. Excellent. Included strings.h as well now. Not a problem on the systems here. We'll see if it hits problems for anyone else. So, compiles on IRIX 6.5.29 if the header is included. Worth gating it in via #ifdef ? I'm also a fan of enum types. Binary emitted is ~298kb. Also, your welcome to an account on the system if you wish to poke/play around, it's accessible over ssh and the general internet (it's my daily shell/hacking on code box). -Wall makes the MIPSpro runtime *extremely* chatty. It's quite anal. See below. Even better. Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 158 The parameter "data" was never referenced. int lookup(struct sockaddr_in *sa, char *data) ^ Yeah. I noticed that one too. I don't remember why data was in there in the first place, since I'm not using it. Might as well drop it. cc-1506 cc: REMARK File = bridge.c, Line = 460 There is an implicit conversion from "unsigned long" to "long"; rounding, sign extension, or loss of accuracy may result. delta = timedelta(bridge[index].lasttime); ^ Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "r" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ That one is because dump_nomatch is a function I wrote for debugging help. The body of the function is normally empty, since it's inside a #if Need to think a little about how/if I'll get rid of that warning... cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "d" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ Same story... cc-1185 cc: WARNING File = bridge.c, Line = 579 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ That one should already have been fixed... cc-1171 cc: WARNING File = bridge.c, Line = 685 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Also alredy fixed... cc-1498 cc: REMARK File = bridge.c, Line = 709 There is no prototype for the call to read_conf. read_conf(); ^ Think I fixed that. However, this is a little messy, since I'm doing things slightly unconventional. read_conf() is called both in the normal main program, and is also the signal handling function for SIGHUP. However, signal functions actually takes one argument. By setting up a prototype, I had to include one argument here, which is unused (I totally don't care about it), so now you might get a warning about an unused parameter. But prototypes are a good thing, so the unused parameter warning is better to have. cc-1209 cc: REMARK File = bridge.c, Line = 715 The controlling expression is constant. while(1) { ^ Yes. That's how you get an infinite loop. :-) Thanks for the feedback. See what happens with the fixed code... Johnny

12 years, 11 months

New bridge.c feedback

by bqt＠softjar.se

On 2012-06-08 01:30, Boyanich, Alastair wrote: Hi Johnny, Yes. It seems to want<strings.h> 6.5.24 and above (or 6.5.29f in my case) was aiming at SUSv3 compliance away from base XPG4 so things were moved to strings.h (http://pubs.opengroup.org/onlinepubs/009695399/functions/index.html) .. it's also in the 3c index man page, you were right. Excellent. Included strings.h as well now. Not a problem on the systems here. We'll see if it hits problems for anyone else. So, compiles on IRIX 6.5.29 if the header is included. Worth gating it in via #ifdef ? I'm also a fan of enum types. Binary emitted is ~298kb. Also, your welcome to an account on the system if you wish to poke/play around, it's accessible over ssh and the general internet (it's my daily shell/hacking on code box). -Wall makes the MIPSpro runtime *extremely* chatty. It's quite anal. See below. Even better. Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 158 The parameter "data" was never referenced. int lookup(struct sockaddr_in *sa, char *data) ^ Yeah. I noticed that one too. I don't remember why data was in there in the first place, since I'm not using it. Might as well drop it. cc-1506 cc: REMARK File = bridge.c, Line = 460 There is an implicit conversion from "unsigned long" to "long"; rounding, sign extension, or loss of accuracy may result. delta = timedelta(bridge[index].lasttime); ^ Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "r" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ That one is because dump_nomatch is a function I wrote for debugging help. The body of the function is normally empty, since it's inside a #if Need to think a little about how/if I'll get rid of that warning... cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "d" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ Same story... cc-1185 cc: WARNING File = bridge.c, Line = 579 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ That one should already have been fixed... cc-1171 cc: WARNING File = bridge.c, Line = 685 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Also alredy fixed... cc-1498 cc: REMARK File = bridge.c, Line = 709 There is no prototype for the call to read_conf. read_conf(); ^ Think I fixed that. However, this is a little messy, since I'm doing things slightly unconventional. read_conf() is called both in the normal main program, and is also the signal handling function for SIGHUP. However, signal functions actually takes one argument. By setting up a prototype, I had to include one argument here, which is unused (I totally don't care about it), so now you might get a warning about an unused parameter. But prototypes are a good thing, so the unused parameter warning is better to have. cc-1209 cc: REMARK File = bridge.c, Line = 715 The controlling expression is constant. while(1) { ^ Yes. That's how you get an infinite loop. :-) Thanks for the feedback. See what happens with the fixed code... Johnny

12 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet